Atlas

Open-source network discovery and visualization, honestly reviewed. Built for the person who has 12 Docker containers running and no idea what’s talking to what.

TL;DR

• What it is: A containerized tool that scans your Docker host and local subnet, then renders the results as an interactive network map in a React dashboard [README].
• Who it’s for: Homelab operators, self-hosters, and small dev teams who want a visual inventory of their running containers and network neighbors — without setting up a full SNMP-based monitoring stack.
• Cost: Free. MIT license. You run it on infrastructure you already own [README].
• Key strength: Zero-friction single-container deployment with automatic Docker inventory — no agents on each host, no YAML-per-service config, no database server to manage separately [README].
• Key weakness: Single-user only (one admin account), no multi-user RBAC, no alerting, and the project sits at 1,026 GitHub stars with 40 forks — small community, limited third-party documentation [README].

---

What is Atlas

Atlas is a full-stack network infrastructure visualizer built by developer karam-ajaj. You run it as a Docker container on your server. It discovers what’s running on the host (Docker containers) and what’s reachable on your subnets (neighboring hosts), stores that data in SQLite, and serves it through a React frontend as an interactive, explorable network graph [README].

The tool performs three scan types. A fast scan runs on a configurable interval (default: every hour) and checks reachable devices on the subnet. A Docker scan inspects the Docker daemon directly via the socket mount — extracting IPs, MACs, open ports, network names, and OS type from image metadata, with support for containers that have multiple network interfaces. A deep scan runs less frequently (default: every two hours) and retrieves OS fingerprints and more thorough port data [README].

Visualization is the product’s main differentiator. The React frontend renders the network as a graph with multiple layout modes — circular and hierarchical, both desktop and mobile responsive. You can also switch to a tabular hosts view for raw data, and there’s a logs panel for scan history. There’s a live demo at https://atlasdemo.vnerd.nl/ if you want to evaluate the UI before deploying [README].

The stack is Go (scanning backend), FastAPI (REST API), NGINX (serving the frontend), React (frontend), and SQLite (storage). No Postgres, no Redis, no Kafka — the entire thing ships in one Docker image [README].

At the time of writing, the project has 1,026 GitHub stars and 40 forks. Third-party reviews specific to this tool are not available — what follows is based on the README, deployment documentation, and direct analysis of the project’s design.

---

Why people choose it

There’s no shortage of network monitoring tools, but most of them are either massive (Zabbix, Nagios, LibreNMS) or too minimal (plain Nmap output). Atlas occupies a different slot: a small, self-contained visualizer with a specific focus on Docker-heavy homelabs.

The appeal is the combination of automatic Docker introspection and network graph visualization in a single container. You don’t need to install agents on each host, configure SNMP communities, or write a YAML inventory. You mount the Docker socket, point it at your subnets, and it figures the rest out [README].

The flip side is that it’s not a monitoring system in the traditional sense. There are no alerting rules, no Prometheus metrics export, no dashboards for CPU/memory/disk, no service-level health checks. It’s a visualizer and an inventory tool, not an observability platform. Users who need those things will need something else — or will use Atlas alongside something like Netdata or Grafana.

---

Features

Based on the README and deployment documentation:

Scanning:

• Docker container scanning via mounted Docker socket — extracts IPs, MACs, open ports, network names, OS type from image metadata [README]
• Multi-interface support: each network interface per container is tracked separately [README]
• Subnet scanning for neighboring hosts — detects reachable devices, retrieves OS fingerprints, MACs, and open ports [README]
• Three configurable scan schedules: fast (FASTSCAN_INTERVAL), Docker (DOCKERSCAN_INTERVAL), deep (DEEPSCAN_INTERVAL) [README]
• Manual subnet configuration via SCAN_SUBNETS env var, or auto-detection of local subnet if not set [README]

Visualization:

• Interactive React graph with circular and hierarchical layout modes [README]
• Tabular hosts view for data-dense browsing [README]
• Logs panel showing scan history [README]
• Mobile-responsive layout [README]
• Real-time data via FastAPI backend [README]

Storage and API:

• SQLite storage — no external database required [README]
• FastAPI REST API with docs served at /api/docs [README]
• API accessible both via the exposed API port and through NGINX proxy at the UI port [README]

Authentication:

• Single admin user account [README]
• Optional — disabled by default; enabled by setting ATLAS_ADMIN_PASSWORD [README]
• JWT-based sessions with configurable TTL (default 24 hours) [README]
• When enabled, all core API endpoints require token authentication [README]

Deployment:

• Single Docker image [README]
• Fully configured via environment variables [README]
• Requires --network=host and NET_RAW/NET_ADMIN Linux capabilities for subnet scanning [README]

Notable absences: no alerting, no multi-user accounts, no RBAC, no metrics export (Prometheus/InfluxDB), no notification integrations, no scheduled reports.

---

Pricing: SaaS vs self-hosted math

Atlas has no SaaS version. It’s MIT-licensed open-source software that runs on your hardware [README].

Atlas:

• Software cost: $0
• VPS to run it: whatever you’re already paying, or $4–6/mo on a small Hetzner or Contabo instance
• Persistent data storage: SQLite file, no database server cost

Commercial alternatives with similar scope:

• ntopng community edition: free, but the features worth having (historical flows, security alerts, extended protocols) are behind a commercial license that starts around $99/year for small deployments
• SolarWinds Network Topology Mapper: quoted from $1,115/year for commercial use — a tool in an entirely different cost bracket aimed at enterprise network admins
• PRTG Network Monitor: free up to 100 sensors, then $1,899+ for the commercial version

For a homelab or small self-hosted environment with fewer than 50 devices, the math is obvious. Atlas costs nothing beyond the hardware you already own. The comparison isn’t really about pricing — it’s about whether Atlas’s capabilities are sufficient for what you need.

---

Deployment reality check

Deployment is a single docker run command with the right flags [README]. The critical requirements are:

docker run -d \
  --name atlas \
  --network=host \
  --cap-add=NET_RAW \
  --cap-add=NET_ADMIN \
  -v /var/run/docker.sock:/var/run/docker.sock \
  keinstien/atlas:{tag}

What to know before you deploy:

--network=host is non-negotiable for subnet scanning. Atlas needs to see your actual network interfaces to scan neighboring hosts. This means the container runs in the host’s network namespace — a security trade-off worth understanding. If you’re running this in a hardened environment, the host network mode will likely be a blocker.

NET_RAW and NET_ADMIN capabilities are required for raw socket access used by the scanner. Same consideration — these are elevated privileges.

The Docker socket mount (/var/run/docker.sock) gives Atlas full Docker API access on the host. Standard practice for container introspection, but it effectively grants root-equivalent access to the Docker daemon.

For subnet scanning, Atlas needs SCAN_SUBNETS set or it auto-detects. Auto-detection works if you’re on a single flat network. If you have multiple VLANs or subnets you want scanned, you’ll need to specify them explicitly [README].

What you do not need: a separate database server (SQLite is bundled), a Redis instance, an SMTP server, or a reverse proxy for basic use (though you’ll want one if you’re exposing the UI over HTTPS).

Realistic setup time for someone comfortable with Docker: 10–15 minutes for a running instance. For a non-technical user following documentation: 30–60 minutes including network config. The main friction points are understanding the capability requirements and subnet configuration, not the Docker setup itself.

Authentication is disabled by default — you’ll want to set ATLAS_ADMIN_PASSWORD before exposing this to any network beyond localhost.

---

Pros and cons

Pros

• Zero external dependencies. One image, one container. SQLite is bundled. No Postgres, no Redis, no separate monitoring agent. For a homelab tool, this matters — you don’t want to run five containers just to inventory five containers [README].
• MIT license. Use it, fork it, embed it, deploy it for clients. No commercial use restrictions [README].
• Docker-native inventory. Automatic discovery of containers including multi-interface support is genuinely useful. Nmap doesn’t know your container names or which Docker networks they’re on [README].
• Functional REST API. FastAPI auto-generates docs at /api/docs. You can query the host data programmatically or integrate it with other tools [README].
• Multiple visualization layouts. Circular and hierarchical graph modes, plus tabular view — practical for different use cases (showing to someone vs. debugging [README]).
• Live demo available. You can evaluate the actual UI at https://atlasdemo.vnerd.nl/ before committing to deployment [README].
• Free, genuinely. No “free tier with limits,” no phone-home, no feature gating. MIT means MIT [README].

Cons

• Single user only. One admin account. No teams, no viewer-only roles, no per-user access controls. Fine for solo homelabs, unusable for any shared environment [README].
• No alerting. Atlas tells you what’s on your network right now. It doesn’t tell you when something new appears, when a container goes down, or when a port closes. That’s a monitoring tool; Atlas is an inventory tool.
• Requires elevated container privileges. --network=host, NET_RAW, NET_ADMIN, and the Docker socket mount are security-relevant requirements that will be blockers in stricter environments.
• Small project, limited community. 1,026 stars and 40 forks means limited third-party documentation, no ecosystem of plugins, and a bus factor concentrated on one maintainer [README].
• No metrics export. No Prometheus endpoint, no InfluxDB integration, no way to feed Atlas data into your existing observability stack.
• SQLite ceiling. Fine for hundreds of hosts. As an architectural choice it limits any future multi-node or high-frequency scanning scenarios, though that’s probably not the target use case here.
• No scan history trending. The logs panel shows scan events, but there’s no historical diff view — you can’t see “this container appeared on day 3 and that port opened on day 7.”

---

Who should use this / who shouldn’t

Use Atlas if:

• You run a homelab or small self-hosted server with Docker containers and want a visual map of what’s running.
• You manage a small number of servers (1–5) and want to quickly see network topology without setting up Zabbix or LibreNMS.
• You’re comfortable with Docker and understand the security trade-offs of --network=host and Docker socket mounts.
• You need a lightweight inventory tool, not a full monitoring platform.

Skip it if:

• You need alerting. If you want to be paged when a container dies or a new device appears on your network, Atlas won’t do it.
• You need multi-user access. Any team environment with more than one person who needs access will hit the single-account limitation immediately.
• Your security policy restricts --network=host or NET_RAW/NET_ADMIN capabilities. These are hard requirements, not optional flags.
• You need persistent trend data or historical diffs. Atlas shows current state, not change over time.
• You’re running more than 50–100 hosts. There’s no documented scale testing, and SQLite starts showing friction at high concurrency and volume.

Consider something else if:

• You want network monitoring with alerting → Netdata, Zabbix, or Checkmk
• You want container-focused observability → Portainer (management) + Prometheus + cAdvisor (metrics)
• You want CLI-based network scanning without a UI → Nmap, Angry IP Scanner
• You want a full-featured open-source NMS → LibreNMS or OpenNMS (more complex, more powerful)

---

Alternatives worth considering

• Netdata — real-time performance monitoring with auto-discovery of Docker containers. Stronger on metrics and alerting, weaker on network topology visualization. Free tier available; paid cloud tier for retention and alerts.
• LibreNMS — full-featured open-source NMS with SNMP support, alerting, and network maps. Significantly more complex to deploy and configure. Suited to networks with managed switches and routers, not just Docker hosts.
• Portainer — container management UI with a built-in network and container inventory view. Closer to a Docker admin panel than a network visualizer, but many homelabbers use it for the same “what’s running” use case.
• Nmap + Zenmap — the classic combination. Nmap does the scanning (with more options than Atlas), Zenmap provides a GUI and topology map. No persistent storage, no automatic scheduled scans, no Docker awareness.
• ntopng — network traffic analysis with topology views. More powerful but the useful features are commercial. Community edition is limited.
• Netdisco — open-source network management tool built around SNMP and MAC address tables. Good for real network gear (switches, routers), not Docker-centric.

For a Docker-focused homelab that wants automated discovery and a visual map without SNMP configuration, Atlas is in a reasonably unique slot. The closest comparable tool is probably Nmap + Zenmap with a cron job — but Atlas wins on Docker integration and the persistent React dashboard.

---

Bottom line

Atlas is a focused tool that does a specific thing: scan your Docker host and local subnet, store the results, and render them as an interactive network graph. It does this in one container with no external dependencies and an MIT license. For a homelab operator who wants to answer “what’s actually running on my network and how is it connected,” it’s a genuinely useful tool that you can have running in fifteen minutes.

The limitations are real. No alerting, no multi-user support, elevated container privileges required, small community. This is not a replacement for a monitoring stack — it’s an inventory and visualization tool, and the gap matters. If you deploy it expecting Zabbix, you’ll be disappointed. If you deploy it expecting a visual Docker inventory that also shows your network neighbors, you’ll find it fits the bill.

The project is early-stage by community scale (1,026 stars), but the live demo suggests functional, maintained software. At zero cost and one docker run, the evaluation cost is minimal.

---

Sources

1. karam-ajaj/atlas — GitHub README (primary source). https://github.com/karam-ajaj/atlas
2. karam-ajaj/atlas — Deployment documentation and environment variable reference (from README). https://github.com/karam-ajaj/atlas#deployment-docker
3. karam-ajaj/atlas — Live demo environment. https://atlasdemo.vnerd.nl/

Note: No third-party reviews of karam-ajaj/atlas (the network visualizer) were available at the time of writing. The five external source URLs provided during research resolved to articles about unrelated products sharing the Atlas name (WP Engine’s headless WordPress platform, Atlas VPN, MongoDB Atlas, and Search Atlas SEO tool). This review is based on the project’s own documentation and source repository.