You deployed your app. It runs. The containers are green. Job done, right?

Except here's what's probably happening right now on your production server and you don't know about it:

• That Postgres container is listening on 0.0.0.0:5432 because you forgot to scope the port binding
• Your MariaDB image has a critical update (11.4 → 12.2.2) that's been sitting there for weeks
• One of your SSL certificates expires in 6 days
• That "temporary test container" you spun up on Friday afternoon is still running, exposed to the internet, and it's now Monday
• Your nightly backup cron job silently stopped working 3 days ago

Nobody's watching. Because setting up proper monitoring for a Docker stack is a pain, so most of us just... don't.

Let's talk about why that's a problem, what the existing solutions look like, and why I ended up building my own.

The numbers are worse than you think

SSL certificates: the ticking time bomb

72% of organizations experienced at least one certificate-related outage in the past year. 34% had multiple. The average outage takes 2.6 hours to identify and 2.7 more to fix.

And it's about to get much worse. As of March 2026, the CA/Browser Forum is phasing certificate validity down from 398 days to 200 days — and eventually to 47 days by 2029. That means you'll go from renewing certs once a year to roughly 8 times a year. Manual tracking with a calendar reminder? Good luck.

Microsoft Teams went down for hours because of an expired certificate. Spotify had an outage on their podcast platform for the same reason. The US government had 80 certificates expire at once, taking multiple government websites offline. These aren't small companies with junior sysadmins — these are organizations with entire security teams.

If it happens to them, it's happening to your production servers too.

Container security: what you can't see can hurt you

37% of organizations reported container or Kubernetes security incidents in 2024. The most common attack vectors? Vulnerable base images (32%), containers running as root (28%), and exposed Docker sockets (18%).

In November 2025, researchers found over 10,000 Docker Hub images leaking live production credentials — API keys, cloud tokens, database passwords — from more than 100 organizations, including a Fortune 500 company. A national bank's architect had hundreds of public images on a personal Docker Hub account, several leaking internal infrastructure credentials.

And that's just the stuff that makes the news. What about your Redis container that's been running in privileged mode since that debugging session last month? Or the MongoDB port you exposed for "quick testing" that's still binding to 0.0.0.0?

The container you forgot about

We've all done it. You spin up a container for a quick test on a staging or production server — a database, a cache, a random API service. Someone pings you on Slack, you context-switch to something urgent, and the container sits there. If it's Friday afternoon, it sits there all weekend. With an open port. On a public-facing server.

No alert. No notification. No dashboard telling you "hey, this thing is exposed and probably shouldn't be."

The attack surface of your infrastructure is not what you think it is. It's what you deployed plus what you forgot you deployed. And when you manage multiple servers or client environments, the problem multiplies.

What about monitoring tools? Yes, they exist. About 15 of them.

The monitoring landscape in 2026 is not a lack of options — it's an excess. About 75% of Kubernetes environments use Prometheus. Most serious setups pair it with Grafana, cAdvisor, and AlertManager. That's already 4 containers just to watch your other containers.

Here's what a "proper" monitoring stack looks like for a typical production Docker setup on a dedicated server:

And that doesn't even cover network security analysis (exposed ports, privileged containers) or CVE detection on your running images. For that you'd need to add something like Trivy or Grype, plus custom scripting to scan your running containers.

Let's look at what this actually means in docker-compose terms.

Prometheus + Grafana + cAdvisor (container metrics)

services:
  prometheus:
    image: prom/prometheus:latest
    volumes:
      - ./prometheus.yml:/etc/prometheus/prometheus.yml
      - prometheus_data:/prometheus
    ports:
      - "9090:9090"

  grafana:
    image: grafana/grafana:latest
    volumes:
      - grafana_data:/var/lib/grafana
    ports:
      - "3000:3000"
    depends_on:
      - prometheus

  cadvisor:
    image: gcr.io/cadvisor/cadvisor:latest
    volumes:
      - /var/run/docker.sock:/var/run/docker.sock:ro
      - /sys:/sys:ro
      - /var/lib/docker/:/var/lib/docker:ro
    ports:
      - "8080:8080"

  alertmanager:
    image: prom/alertmanager:latest
    volumes:
      - ./alertmanager.yml:/etc/alertmanager/alertmanager.yml
    ports:
      - "9093:9093"

volumes:
  prometheus_data:
  grafana_data:

That's 4 containers, 3 config files to maintain, and you still need to write PromQL queries and build Grafana dashboards before you see anything useful.

Uptime Kuma (HTTP/TCP checks)

services:
  uptime-kuma:
    image: louislam/uptime-kuma:latest
    volumes:
      - uptime-kuma_data:/app/data
    ports:
      - "3001:3001"

volumes:
  uptime-kuma_data:

Simple, clean, but it only does endpoint checks. It doesn't know about your containers, their resource usage, their images, or their network exposure.

Healthchecks.io (cron monitoring)

services:
  healthchecks:
    image: healthchecks/healthchecks:latest
    environment:
      - SITE_ROOT=https://checks.example.com
      - SECRET_KEY=your-secret-key
      - DB=sqlite
    volumes:
      - healthchecks_data:/data
    ports:
      - "8000:8000"

volumes:
  healthchecks_data:

Another container, another UI, another set of credentials.

The total cost

At this point you're running 6+ monitoring containers to watch 20 containers. That's a 30% overhead ratio just for observability. Each tool has its own UI, its own alerting config, its own data store. None of them talk to each other. None of them give you a single view of "is my stack healthy?"

And you still don't have SSL monitoring, image update detection, or network security analysis.

This is over-engineering for a fundamentally simple need: knowing if your stuff is running, safe, and up to date.

Why most people don't monitor properly

It's not laziness. It's friction.

The Prometheus+Grafana stack is incredibly powerful — it's what runs Google-scale infrastructure. But for a team running 10-50 containers on a dedicated server or a small cluster, it's like using a Formula 1 pit crew to check the tire pressure on your daily driver. The setup time alone kills the motivation, and then you have to maintain it.

So what actually happens?

1. You deploy Uptime Kuma for the HTTP checks because it's easy
2. You tell yourself you'll add proper metrics "later"
3. "Later" never comes
4. You find out about problems when users complain or when you SSH in and something is red

Sound familiar? Yeah, me too.

So I built the thing I wanted

After running this exact fragmented setup for way too long, I decided to build what I actually needed: one container that does all of it.

Maintenant is a single Docker container that monitors your entire stack. You mount the Docker socket (read-only — it never touches your containers) and in 30 seconds you have:

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

volumes:
  maintenant-data:

That's it. No config file. No PromQL. No Grafana dashboards to build. It auto-discovers everything on first start.

What it covers

Container monitoring: every container is tracked the moment it starts. State changes, health checks, restart loops, CPU/RAM/network/disk per container. Grouped by Compose project automatically. Top consumers view to spot the greedy ones.

HTTP/TCP endpoint monitoring: define probes via Docker labels — no config files, no UI clicks. Maintenant picks them up when the container starts:

labels:
  maintenant.endpoint.http: "https://api:3000/health"
  maintenant.endpoint.interval: "15s"
  maintenant.endpoint.failure-threshold: "3"

Heartbeat/cron monitoring: create a monitor, get a URL, add one curl to your cron job. Maintenant tracks start/finish times, durations, and alerts when a job goes missing.

curl -fsS -o /dev/null https://your-instance.com/ping/{uuid}/$?

SSL/TLS certificate tracking: auto-detected from your HTTPS endpoints, plus standalone monitors for any domain. Alerts at 30, 14, 7, 3, and 1 day before expiry. With certificates moving to 200-day validity this year and 47 days by 2029, this isn't optional anymore.

Update detection: scans OCI registries (Docker Hub, GHCR, etc.), compares digests and semver tags. Flags critical version jumps — like that MariaDB 11.4 → 12.2.2 that you might have missed. No more running docker pull manually and hoping for the best.

Network security analysis: automatically scans your containers' network configuration and flags risky patterns — database ports exposed on 0.0.0.0, containers in privileged mode, host-network mode, and for Kubernetes, NodePort/LoadBalancer without NetworkPolicy. This is the "test container you forgot about on Friday" detector.

Public status page: built-in, customizable, auto-reflects your monitor states. No manual update needed — if something goes down, your status page shows it.

The stack

Single Go binary. Less than 20 MB of RAM at idle. SQLite in WAL mode — no Postgres, no Redis, no external anything. The Vue 3 frontend is embedded in the binary via Go's embed.FS. Real-time updates via SSE.

One container instead of six. Same coverage, fraction of the resources.

It's also a MCP server

Maintenant has a built-in Model Context Protocol server. You can query your infrastructure health, read container logs, and check alert status from Claude or any MCP-compatible AI assistant. Because in 2026, your monitoring tool should be queryable by your AI tools too.

The business model (I'll be upfront)

Maintenant is open-core under AGPL-3.0. The full codebase — including Pro features — is visible on GitHub. Nothing is in a private repo.

The Community Edition is the real product: containers, endpoints, heartbeats, SSL certificates, update detection, network security insights, status page, Kubernetes support, Webhook + Discord alerts. Monitors defined via Docker labels are unlimited. Manually added monitors have soft caps (10 endpoints, 10 heartbeats, 5 standalone TLS certificates) — generous enough for most setups, and label-driven config is the recommended approach anyway.

The Pro Edition (29€/month or 290€/year) lifts all limits and adds Slack/Teams/Email (SMTP) alerts, alert escalation and routing, CVE detection via OSV.dev, security posture dashboard, incident management, maintenance windows, and subscriber notifications.

I'm a solo developer. This is how I sustain the project. If the free edition covers your needs, that's the intended experience.

Try it

docker compose up -d
# open http://localhost:8080
# your containers are already there

• GitHub: github.com/kOlapsis/maintenant
• Website: maintenant.dev
• Documentation: docs.maintenant.dev

If you've been running the "5 tabs and a prayer" monitoring setup on your production servers, give it a try. It takes 30 seconds and replaces a lot of duct tape.

Whether you manage a single dedicated server or multiple environments for your clients, Maintenant gives you the full picture from one container.