# AdGuardian-Term: Real-Time DNS Monitoring in the Terminal > AdGuardian-Term is a Rust terminal interface for observing DNS traffic, query outcomes, filter activity, and top domains on an AdGuard Home instance. It suits operators who want a lightweight local dashboard, but it depends on a reachable AdGuard Home API and does not replace AdGuard Home itself. **lissy93/AdGuardian-Term** — 🛡️ Terminal-based, real-time traffic monitoring and statistics for your AdGuard Home instance - Repository: https://github.com/lissy93/AdGuardian-Term - Website: https://adguardian.as93.net - Stars: 1,678 · Forks: 89 - Language: Rust - License: MIT - Published: 2026-10-16 · Updated: 2026-10-16 · Language: en - Canonical page: https://hysenlabs.com/projects/lissy93-adguardian-term ## What AdGuardian-Term Adds to AdGuard Home AdGuardian-Term solves a narrow operational problem: showing what an AdGuard Home instance is doing at the moment, from inside a terminal. Its audience is the person administering a self-hosted or managed AdGuard Home deployment, especially an operator who already works in command-line environments and wants a local view without opening a browser. The application is explicitly described as an unofficial companion to AdGuard Home. It does not replace AdGuard Home's DNS filtering, configuration, or network-wide request handling. Instead, it presents information exposed by that instance. The README lists real-time DNS query monitoring, allowed, filtered, and blocked counts, historical query counts, active filter lists, and top-domain statistics. That combination is more useful than a single pass or fail counter because it gives context to the counts: a large blocked total may be associated with a particular client, filter list, or domain pattern. The project targets users who want observability rather than another layer of filtering. It is written in Rust, packaged as a terminal application, and described as running locally without external requests. The project is not archived, and the repository's last push was on 2026-10-06. Release 1.8.0 was published on 2026-10-06, following 1.7.0 on 2026-05-31. These dates indicate recent repository activity, but the README does not describe a compatibility policy for AdGuard Home API changes. ## How the Terminal Dashboard Receives AdGuard Data The project is a Rust application built around terminal input and rendering rather than a browser page. The dependency list in `Cargo.toml` shows the relevant implementation choices: `reqwest` provides HTTP and JSON communication with `rustls` and `webpki-roots`, `tokio` supplies asynchronous execution, `serde` and `serde_json` deserialize responses, and `crossterm` handles keyboard and mouse events. The `tui` package is an alias for `ratatui`, the terminal UI library. That architecture implies a request and event loop. The application must connect to an AdGuard Home instance, obtain query and statistics data through its API, deserialize the JSON, and render the resulting values in terminal panels. The README specifically says that AdGuardian-Term fetches and displays all DNS queries in real time. It also presents historical counts and aggregate data, so the dashboard is not limited to a static configuration view. Connection details are supplied through command-line flags or environment variables. The documented required fields are `ADGUARD_IP`, `ADGUARD_PORT`, `ADGUARD_USERNAME`, and `ADGUARD_PASSWORD`, with corresponding flags such as `--adguard-ip` and `--adguard-port`. An optional `ADGUARD_PROTOCOL` variable controls the protocol used when connecting, although the README does not describe its accepted values. If required fields are missing or incomplete, the application prompts for them at startup. The app is therefore dependent on a functioning AdGuard Home API and on credentials accepted by that instance. The repository layout does not show a local database or an independent collector. Historical statistics therefore belong to AdGuard Home's available data and the endpoints used by the client. The README does not specify retention limits, polling intervals, API rate limits, or the exact mapping between dashboard widgets and API routes. ## Docker, Executable, Cargo, and Source Installation The simplest documented first use is the published Docker image. The command opens an interactive terminal and leaves the application to request any missing connection values. The README also documents a GHCR image under `ghcr.io/lissy93/adguardian` if Docker Hub is unavailable. ```bash docker run -it lissy93/adguardian ``` The expected result is the AdGuardian-Term interface after the application starts and receives the required AdGuard Home connection information. If Docker Hub is unavailable, the README says the same image is also available through GHCR and instructs users to replace the image name. For systems where a standalone executable suits the workflow, the README gives a Linux download example. It downloads the latest Linux binary, marks it executable, and starts it. The URL includes `adguardian-linux`, so the README specifically tells users to adjust the URL for their operating system. ```bash curl -L -o adguardian https://github.com/Lissy93/AdGuardian-Term/releases/latest/download/adguardian-linux && \ chmod +x adguardian && \ ./adguardian ``` Rust users can install the published crate with Cargo and then start the binary: ```bash cargo install adguardian adguardian ``` For development or an unsupported architecture, the source path requires `git`, `cargo`, and `make`: ```bash git clone git@github.com:Lissy93/AdGuardian-Term.git && \ cd AdGuardian-Term && \ make ``` The Makefile's default `all` target runs `clean`, `build`, `test`, `doc`, and `run`. That target is a development workflow rather than a minimal installation. The README also documents a one-line Bash installer, but it warns users to read and understand `quick-start.sh` first. The choice is straightforward: Docker has the smallest host installation requirement, while an executable avoids a runtime dependency but requires selecting the correct release asset. ## Configuration Boundaries and Startup Failure Modes AdGuardian-Term does not discover every AdGuard Home setting for the operator. The documented configuration is intentionally small: address, port, username, and password are the core fields, while protocol is optional. This keeps the startup interface direct, but it also means that an inaccessible address, incorrect port, rejected credentials, or an unsupported network path will prevent useful data from appearing. The prompt on startup is a fallback for missing or incomplete values. It does not replace a valid API session. A user should therefore distinguish between a configuration prompt, which can be answered interactively, and a connection failure, which requires checking AdGuard Home availability and credentials. The README does not document a configuration file, secret store, credential rotation procedure, retry policy, or offline cache. It also does not state whether credentials persist after entry. Because the application is intended to run locally, operators should still decide how the process is launched and whether shell history, Docker configuration, or environment files could expose the password. There is another practical limitation: a terminal UI depends on terminal capabilities and a usable interactive display. The Docker example uses `-it` specifically to allocate an interactive terminal. Remote sessions without terminal input, or environments with incompatible terminal behavior, are not addressed in the README. These are deployment constraints rather than AdGuard Home filtering limitations. ## Where the Terminal View Differs from Browser-Based Management The repository does not name a competing monitoring project, so the practical alternative is the browser-based management experience associated with AdGuard Home itself. The difference is approach. AdGuardian-Term is a separate Rust client that connects to an existing AdGuard Home instance and turns its API data into a terminal dashboard. A browser management interface keeps its controls and status information in a web UI. For an operator already working over SSH or inside a container, the terminal client can reduce context switching and avoid requiring a graphical browser. The README positions Docker and the standalone executable as lightweight deployment options. Its local operation also fits a workstation or server console where a web dashboard is inconvenient. The trade-off is scope. The documentation does not describe browser access, multi-user collaboration, alert delivery, report export, or a standalone data store in AdGuardian-Term. It should not be treated as a replacement for AdGuard Home's configuration surface or for an external observability platform. It is the better fit when the question is “what is this AdGuard Home instance doing right now?” and the answer needs to be visible in a terminal. ## Maintenance, Licensing, and Upgrade Work The repository is not archived, and its last push was on 2026-10-06. The recent release history includes 1.8.0 on 2026-10-06, 1.7.0 on 2026-05-31, and an earlier 1.6.0 release on 2023-06-10. The project therefore has current development activity, although the README does not publish a formal support window or a compatibility matrix for AdGuard Home versions. The package is licensed under MIT. The repository includes an `MIT` `LICENSE` file, and the Docker image labels the project with the same license identifier. This indicates the project's stated licensing model, but it does not answer operational questions about AdGuard Home itself, third-party dependencies, or the administrator's deployment obligations. Upgrades are straightforward at the installation layer because the project offers release binaries, Docker, Cargo, and source builds. That variety creates a maintenance choice: container users must decide when to pull a newer image, Cargo users can update through the crate workflow, and source users must review changes and rebuild. The `Cargo.lock` file is present for source builds, while the Dockerfile builds a release binary from the checked-in project context. The README does not document an automated upgrade command or a migration procedure for terminal settings. It also does not specify whether older releases remain compatible with current AdGuard Home responses. The first upgrade check should therefore focus on connection success and whether live queries, statistics, and filter data still appear after updating. ## Conclusion AdGuardian-Term is appropriate for operators who want a local, terminal-based view of AdGuard Home DNS activity and are comfortable supplying instance credentials and choosing a distribution method. It is less suitable for teams that need a documented team dashboard, remote access, or a monitoring system independent of AdGuard Home. Verify first that your AdGuard Home endpoint, port, credentials, protocol, and terminal support work with the selected binary or image, because the application requires those connection details before it can display data. ## FAQ ### How do I install AdGuardian-Term and connect it to AdGuard Home? You can run `docker run -it lissy93/adguardian`, install the published crate with `cargo install adguardian`, download a release executable, or build from source. The application needs `ADGUARD_IP`, `ADGUARD_PORT`, `ADGUARD_USERNAME`, and `ADGUARD_PASSWORD`, or their documented flag equivalents, and prompts for missing values at startup. ### Does AdGuardian-Term block DNS traffic on its own? No. The README describes it as an unofficial terminal companion for an AdGuard Home instance. Its documented functions are monitoring, statistics, filter-list visibility, and top-domain reporting; AdGuard Home remains the DNS filtering service. ### Can AdGuardian-Term run without Docker? Yes. The README provides a standalone executable download example for Linux, a Crates.io installation path, a source-build path, and Windows installation through Scoop. The executable URL must be changed for another operating system, and source builds require `git`, `cargo`, and `make`. ## Sources - [License: MIT](https://github.com/lissy93/AdGuardian-Term/blob/main/LICENSE) - [lissy93/AdGuardian-Term on GitHub](https://github.com/lissy93/AdGuardian-Term) - [Project website](https://adguardian.as93.net) - [README](https://github.com/lissy93/AdGuardian-Term/blob/main/README.md) - [Releases](https://github.com/lissy93/AdGuardian-Term/releases) --- Hysen Labs editorial analysis, written from the project's own repository and release notes. Cite the canonical page: https://hysenlabs.com/projects/lissy93-adguardian-term