Features Pricing Guides Alternatives Blog Docs My account Français Buy a license GitHub
self-hostedmonitoringsingle-binaryarchitecturedocker2026

Self-Hosted Monitoring in 2026: The Single Binary Approach

· 5 min read ·Benjamin Touchard

The monitoring industry has a complexity addiction. Prometheus needs cAdvisor, Grafana, node_exporter and Alertmanager. Datadog needs an agent plus a SaaS account. Even “simple” tools like Uptime Kuma need Node.js and a separate database.

That stopped being the only option. The landscape in 2026 looks very different from five years ago: SaaS monitoring costs have climbed to where Datadog bills regularly exceed hosting costs for small teams, and self-hosted tools have matured to the point where a single Go binary replaces a five-container stack.

What “single binary” actually means

A single-binary monitoring tool ships as one executable file. No runtime dependencies, no external database, no separate frontend server. The monitoring engine, the web interface, the database and the alert system are compiled into one artifact.

In Docker terms: one image, one container, one volume.

services:
  maintenant:
    image: ghcr.io/kolapsis/maintenant:latest
    ports:
      - "8080:8080"
    volumes:
      - /var/run/docker.sock:/var/run/docker.sock:ro
      - /proc:/host/proc:ro
      - maintenant-data:/data
    restart: unless-stopped
volumes:
  maintenant-data:

No Postgres container. No Redis container. No nginx in front of it. No separate worker processes.

What changed

Three trends converged:

  1. Go’s embed.FS made it trivial to ship a full web UI inside a single binary. No separate frontend server needed.
  2. SQLite’s WAL mode proved that an embedded database handles real-time monitoring workloads without PostgreSQL or InfluxDB.
  3. Docker’s dominance in self-hosting meant tools could assume a container runtime and skip the “works on bare metal, VMs, containers and Kubernetes” complexity.

The result is a generation of monitoring tools radically simpler than their predecessors.

Old way (2020)New way (2026)
ArchitecturePrometheus + Grafana + cAdvisor + AlertmanagerSingle binary
DatabaseInfluxDB or Prometheus TSDBEmbedded SQLite
FrontendSeparate React/Angular appEmbedded via embed.FS
Configprometheus.yml + grafana.ini + alertmanager.ymlZero (auto-discovery)
RAM500+ MB combined20 MB
Setup time1-2 hours30 seconds

Why self-hosted matters more than ever

Data sovereignty

Data residency regulations have only got stricter. GDPR, DORA, NIS2 — the acronyms keep multiplying. Sending infrastructure data to a US-based SaaS provider is a compliance headache even for small companies.

A self-hosted tool keeps everything on your server. No data leaves your network.

Cost

Per-host, per-GB, per-custom-metric pricing means costs scale faster than your infrastructure. A startup running 30 containers can easily spend $20,000+/year on monitoring alone. A self-hosted single binary costs the compute it runs on: effectively zero marginal cost.

Independence

SaaS monitoring creates a dependency on someone else’s infrastructure. When the provider has an outage, your monitoring goes down while your actual services keep running. The irony is thick. Self-hosted monitoring fails only when your own infrastructure fails, which is exactly when you need it most — with one caveat covered below.

Why one binary, specifically

Fewer failure modes

Every additional component is a potential failure point. Prometheus can crash independently of Grafana. An Alertmanager config can desync from its Prometheus rules. cAdvisor can OOM while Grafana keeps showing stale data.

With a single binary, either the whole thing works or it does not. There is no partial failure state to debug.

Resource efficiency

ComponentRAM (idle)
Prometheus150-300 MB
Grafana100-200 MB
cAdvisor100-200 MB
node_exporter20-50 MB
Alertmanager30-50 MB
Total400-800 MB
Maintenant20 MB

On a 2 GB VPS, that is the difference between having room for your actual services and fighting for memory.

System resources: CPU, memory, disk, network

Zero configuration

A single binary ships with sane defaults for everything because it controls the entire stack. There is no prometheus.yml to write, no Grafana datasource to configure, no Alertmanager routing tree to design. Maintenant connects to the Docker socket, discovers your containers, and starts monitoring.

Container auto-discovery: states, resources, Compose projects

The only configuration is Docker labels on your own services:

labels:
  maintenant.endpoint.http: "http://api:3000/health"
  maintenant.endpoint.interval: "30s"

Monitoring configuration lives with your code. Versioned, reproducible, and it does not require a separate UI.

Simpler backups and updates

One SQLite file in one volume. Back it up the way you back up your other volumes — no pg_dump, no TSDB snapshots, no dashboard exports. Updating is docker compose pull && docker compose up -d: one image, one container, no version compatibility matrix between Prometheus, Grafana and their plugins.

Unified coverage

One tool covers containers, HTTP/TCP endpoints, SSL certificates, cron jobs, system resources and update detection. Alerts and a public status page are included rather than bolted on as separate services.

Unified dashboard: everything in one view

Public status page: all systems operational

The Go advantage

Most single-binary monitoring tools are written in Go, for good reasons:

  • Static compilation: no runtime dependencies, no shared libraries.
  • Low memory footprint: goroutines are cheap, garbage collection is efficient.
  • Cross-compilation: one build produces linux/amd64, linux/arm64 and macOS binaries.
  • Embedded assets: embed.FS ships the entire frontend inside the binary.

Maintenant embeds its web UI, its SQLite engine and all monitoring logic in a single ~20 MB binary.

The trade-offs

Single-binary tools are opinionated by nature. You trade flexibility for simplicity:

  • No distributed tracing. If you need OpenTelemetry-level observability, this is the wrong class of tool.
  • No infinite retention. Embedded SQLite is not a time-series database tuned for years of data.
  • No custom dashboards and no query language. The views are pre-built; there is no PromQL equivalent and no plugin ecosystem.
  • Scaling limits. One binary per host or cluster, not a distributed system. Multi-region aggregation remains the domain of distributed stacks.
  • One host to lose. If the machine running it dies, monitoring dies with it. Run it somewhere separate from the infrastructure it watches.

When to choose one

Choose a single-binary monitoring tool if you self-host on one to five servers, run Docker Compose or single-node Kubernetes, want monitoring that works without configuration, value simplicity over customisability, or have limited RAM on a small VPS.

If you manage hundreds of servers across multiple cloud providers and need custom dashboards with ad-hoc queries, a distributed stack is the right tool for the job. For everyone else, one binary is enough.

Install Maintenant: self-hosted monitoring for Docker and Kubernetes → · Compare editions →

← Why I Built Maintenant Lightweight Docker Monitoring for Homelab →

Ready to try Maintenant ?

One container, zero config. Full monitoring in 30 seconds.