Features · Discovery & Mapping · Server Auto-Discovery
Discovery & Mapping · Server Auto-Discovery

Install the agent.
We'll do the inventory.

One command on a host, and HostAtlas has the services, the containers, the certs, the cron jobs, the listening ports and the package manifest — without an Ansible inventory, an asset CMDB, or a spreadsheet that two people pretend to maintain. The list stays right because nothing about it depends on a human remembering.

install · root@web-prod-04
# curl -sSL https://install.hostatlas.app/install.sh | sudo bash -s -- --key=HOSTATLAS_SERVER_KEY
→ resolving package manager · apt
→ installing hostatlas-agent
→ enrolling host · token ha_tk_3c91…
→ first scan
●
· 47 systemd units · 12 containers · 23 domains · 8 certificates
· 14 cron jobs · 19 listening ports · 894 packages
✓ hostatlas-agent v1.8.4 · healthy · 28 s
— Why this matters

A fleet you can't list is a fleet you can't secure.

The reason every team eventually has a stale CMDB, a half-finished Ansible inventory, and a Notion page titled “servers (current)” is the same: keeping a list accurate is somebody's 9th-most-important task. Auto-discovery moves the list off the human entirely.

01

The list goes stale within a sprint.

Somebody spins up a worker box for a one-off and never tells the doc. Three months later it's in production traffic and nobody knows what runs on it.

02

Your security tools only see what you tell them about.

The CVE scanner ran clean — on the 18 hosts in the inventory. The 22 hosts that aren't in the inventory still have log4j.

03

“Inventory week” never finishes.

You schedule it every quarter. It runs for two days. Half the team SSHs into a box, runs ps, copies a few lines, and goes back to real work.

04

The incident pager doesn't care about your spreadsheet.

At 03:42 you need to know everything that talks to the database that just crashed — not the version of it from last quarter's audit.

— What the agent finds

Twelve categories, on first scan.

Everything below appears in the host detail page within seconds of the agent reporting in. Counts are typical for a 4-vCPU production box.

Services
systemd units + state, journal hints, restart history
47 units · 5 failed
Containers
Docker + Podman. Image, ports, mounts, env (redacted).
12 running · 3 stopped
Domains
Pulled from nginx · apache · caddy · traefik vhosts.
23 hostnames
Certificates
Chain, issuer, SAN list, expiry. Filesystem + listening.
8 certs · 1 < 14 d
Cron jobs
System crontab, per-user, /etc/cron.d, systemd timers.
14 schedules
Listening ports
IPv4 + IPv6. PID-resolved. Internal vs. exposed.
19 sockets · 6 public
OS packages
dpkg · rpm · apk. Feeds the vuln scan SBOM.
894 packages
Hardware & OS
CPU model, RAM, mountpoints, kernel, init, virt platform.
4 vCPU · 8 GiB · 2 disks
Network
Interfaces, tunnels, bridges, bonds, default route.
5 interfaces
Users & SSH
Login users, sudoers, authorized_keys, last login.
4 users · 11 keys
Firewall
UFW · iptables · nftables · firewalld. Rules, not just chains.
17 rules
Log paths
Web-server access + error logs, journald, app stdout.
12 sources
— How it works

No protocol to learn. No cron to write.

The agent is a single binary. It runs as its own user, reads what it's allowed to read, and pushes diffs to the platform over mTLS. No SSH back to the box. No inbound port.

1

Install

One curl | bash on a fresh host. Detects the package manager, installs the agent, prompts for the enrolment token from the UI. About 8 seconds end to end on a fast box.

curl -sSL https://install.hostatlas.app/install.sh | sudo bash -s -- --key=HOSTATLAS_SERVER_KEY
2

First scan

Within 30 seconds the agent has cataloged everything in the list above. The host shows up in your fleet with a stable UUID — derived from machine-id + first MAC, not from hostname, so renames don't fragment the timeline.

3

Stay synced

Diffs every 60 seconds. Container events and systemd state changes pushed within seconds via subscription. A full re-scan every 5 minutes catches anything an event missed. Bandwidth is small — empty diffs are ~400 bytes.

— Stays current

Things you don't have to remember to tell us.

The first scan is the small one. The harder problem is the second day — when somebody deploys a new container at 16:30 and you find out about it at 04:00 because it broke. Live re-discovery is the part you forget about because it just works.

— Compared to

Where Auto-Discovery is and isn't the right tool.

Inventory is a crowded category. Auto-Discovery is opinionated: continuous, agent-based, opinionated about what counts as “an asset.” Here's where it's the right answer and where it isn't.

HostAtlas
Manual CMDB
Datadog auto-detect
Ansible inventory
Time to first inventory
< 30 s after install
days, often weeks
minutes
next inventory run
Stays accurate
continuous · push + 60 s pull
until a human edits
agent-side polling
until config drifts
Cross-host dependencies
built in (Atlas Graph)
manual
partial (APM-only)
none
Discovers what you forgot
yes — that is the point
no — only what you log
only what its checks know
only what the role declares
Air-gapped option
self-host the platform
yes
no
yes

Where it's the wrong tool

  • You need an authoritative asset register for finance / hardware lifecycle. Auto-Discovery describes what's running, not what your company bought. Pair it with a real CMDB.
  • You ship pre-baked images and want a manifest at build time, not at run time. Bake an SBOM into the image instead — Auto-Discovery is for live state, not artefact provenance.
  • Air-gapped fleet with no platform reachability. The agent still discovers, but it needs somewhere to send the diff. Self-host the platform on the same network or skip Auto-Discovery.
— Works with

Discovery is the floor. These build on it.

Once everything is in the inventory, the other capabilities have something to attach to. Most of HostAtlas is downstream of this one feature.

— FAQ

Honest answers to the questions we actually get.

How much does the agent cost my server? +
Negligible at idle — the inventory pass schedules and lets go. The first pass is the only one with noticeable I/O; everything after is event-driven and incremental. Current numbers live in the agent README, not the marketing page.
Does discovery need root? +
Read-only metadata (services, packages, ports, certs on standard paths) runs as the dedicated hostatlas user. Container introspection needs Docker group membership. Service control — required only for Auto-Recovery — needs systemctl rights, granted via a narrow polkit policy that ships with the package.
How quickly does a new service show up? +
Containers within ~2 seconds (Docker event API). systemd units within the next 60 s sync. A full inventory pass runs every 5 minutes and reconciles anything that slipped through. You can force a refresh from the host detail page.
Can I tell it to ignore things? +
Per-host file at /etc/hostatlas/exclude.yml with glob patterns for services, mountpoints, container names, or path roots. Globally exclude by tag from the platform. Excluded items still appear in the audit log so nothing disappears silently.
Does it phone home with sensitive data? +
TLS 1.3 + mTLS to the platform. Env vars and command lines are redacted by a configurable allow-list before they leave the host. No file contents are read for inventory — only metadata. Full data residency on the EU instance; self-host the platform for air-gapped fleets.
What if I already run Datadog / node_exporter / Netdata? +
The agent does not collide with any of them — it reads different things, on different intervals, into a different store. People run HostAtlas next to a metrics-only stack all the time. The overlap is small; the unique value is the inventory itself.

Stop maintaining an inventory. Start running one.

Free tier includes the agent on unlimited hosts. The inventory is the same on every plan.

Get early access About the agent