Forem: Benjamin Touchard

Your Docker Stack Is Running. But Is Anyone Actually Watching It?

Benjamin Touchard — Sat, 02 May 2026 12:23:20 +0000

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:

What you need to monitor	Tool	Additional containers
Container metrics (CPU/RAM)	Prometheus + cAdvisor + Grafana	3
HTTP endpoint uptime	Uptime Kuma	1
Cron job monitoring	Healthchecks.io (or self-hosted)	1
SSL certificates	A bash script, or... another tool	0-1
Image updates	Manual `docker pull`, or Watchtower	0-1
Status page for users	Cachet, Statusnook, or another tool	1
Total		6-8 containers

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?

You deploy Uptime Kuma for the HTTP checks because it's easy
You tell yourself you'll add proper metrics "later"
"Later" never comes
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.

I built two open-source tools faster by letting AI write most of the code

Benjamin Touchard — Sat, 20 Dec 2025 11:20:40 +0000

Over the past weeks, I built two open-source projects:

one in a few weeks,
the other in a few days.

Not because I rushed.
Not because they are toy projects.

But because I changed who types the code.

What actually changed (and what didn’t)

I didn’t “let AI build a product”.

I still:

define the architecture,
decide what exists and what doesn’t,
control data models,
review every line,
say no very often.

What changed is simple:
I don’t type most of the code anymore.

The AI does.

This is not about prompts or magic

This has nothing to do with:

clever prompts,
autonomous agents,
“vibe coding” without thinking.

It works because:

I know exactly what I want,
I know when something is wrong,
I know how the system should behave.

The AI is fast.
I am precise.

That combination matters more than prompts.

How I actually use AI to code

My workflow is closer to this:

I describe very precisely what needs to be implemented
The AI writes the code
I read it like a strict reviewer
I ask for corrections, refactors, deletions
I integrate or reject

The AI writes faster than I ever could.
I think slower, but better.

It feels very similar to:

the first smart autocompletion,
then IDE refactoring tools,
then real-time linting.

Same shift. Bigger scale.

Two different projects, same approach

Ackify

Ackify is an open-source tool to handle internal document acknowledgements:
proof that people actually read internal policies, procedures, or mandatory documents.

It required:

a clear domain model,
strong constraints,
no feature creep.

AI helped write:

handlers,
storage layers,
repetitive logic.

I stayed in control of:

scope,
semantics,
guarantees.

SHM

SHM (Self-Hosted Metrics) is much smaller.
It answers one question:
“Is this self-hosted app actually used?”

It was built in days because:

the scope was tiny,
the rules were strict,
the AI handled most of the boilerplate.

Different scale.
Same method.

AI as a force multiplier, not a decision maker

The biggest misunderstanding about AI-assisted coding is thinking it replaces thinking.

It doesn’t.

It replaces:

typing speed,
mechanical repetition,
obvious glue code.

The moment you stop knowing what you want,
the output degrades immediately.

AI is not creative in architecture.
It is efficient in execution.

Why this matters for solo developers and open-source

For solo developers, time is the real constraint.

AI doesn’t give you ideas.
It gives you throughput.

That makes it possible to:

explore ideas faster,
kill bad ones earlier,
finish small useful tools instead of polishing one forever.

That’s exactly how many open-source needs are met:
small tools, precise scope, fast iteration.

Closing thoughts

I don’t feel replaced by AI.
I feel amplified.

I still design.
I still decide.
I still review.

I just don’t type as much anymore.

And that’s fine.

Proving people actually read internal documents is still a mess

Benjamin Touchard — Sat, 20 Dec 2025 11:15:33 +0000

I’ve worked on internal tools, compliance processes, and regulated environments for years.

And there is one recurring problem that almost everyone underestimates:

How do you prove that people actually read internal documents?

Not signed contracts.

Not legal agreements.

Just things like:

internal procedures
security policies
onboarding documents
mandatory trainings

The answers are usually disappointing.

How this is usually handled

In most teams, it looks like this:

a PDF sent by email
a shared folder or intranet page
a checkbox in a form
sometimes a signature on paper

When someone asks:

“Can you prove that employees read this document?”

The answer is often:

“Well… we sent it.”

That’s not proof.

And in audits, that difference matters.

Why existing tools don’t really fit

There are many tools for:

e-signatures
contract management
document workflows

They are usually:

heavy
expensive
SaaS-only
designed for legal or sales use cases

They solve problems like:

signing contracts
closing deals
external compliance

But internal acknowledgements are different.

They are:

frequent
low-risk
internal
boring but mandatory

Using a full contract-signing platform for that feels excessive.

What I actually needed

From a technical and operational point of view, I needed something simple:

prove that a document was presented
prove that it was acknowledged
keep a verifiable record
without managing contracts or identities manually

No document storage SaaS.

No legal framing.

No complexity.

Just proof of read, done properly.

A pragmatic response: Ackify

So I built Ackify, an open-source tool focused on one thing:

Internal document acknowledgements.

Ackify:

generates acknowledgement requests
records confirmations
produces verifiable proof
stays simple by design

It’s not a replacement for legal signature platforms.

It’s a tool for internal compliance and operational needs.

👉 Repository: https://github.com/btouchard/ackify-ce
👉 Website: https://ackify.eu

Why this problem is mostly ignored

Internal compliance is not shiny.

It doesn’t:

generate revenue directly
impress investors
fit growth dashboards

But it costs time, energy, and stress when done badly.

Big platforms optimize for contracts and transactions.

Small teams just need clarity and traceability.

This gap is where many open-source tools live.

Closing thoughts

Not every problem needs an enterprise platform.

Some problems just need:

a clear scope
a simple workflow
and reliable evidence

Internal acknowledgements are one of them.

Why I refuse to ship Google Analytics in open-source projects

Benjamin Touchard — Sat, 20 Dec 2025 11:03:15 +0000

I build open-source applications, most of them self-hosted.

Like many developers, I need metrics. Not marketing metrics. Just basic signals:

Is the application actually used?
How many instances are alive?
Which features are used at all?
And for a long time, the default answer was obvious: Google Analytics.

But at some point, I decided to stop shipping it entirely.

Google Analytics is a poor fit for open-source and self-hosted apps

Google Analytics is not a bad tool. It’s just built for a completely different purpose.

It assumes:

a centralized SaaS product,
tracked end-users,
marketing funnels,
cookies, consent banners, and external dependencies.

None of that aligns well with self-hosted open-source software.

Embedding GA in an open-source app means:

sending usage data outside the user’s infrastructure,
introducing legal and privacy concerns you don’t control,
tracking individuals when you only want aggregate usage.

At that point, the cost (technical, ethical, cognitive) is higher than the value.

Existing alternatives didn’t really solve my problem

I looked at many “privacy-friendly” or “self-hosted” analytics tools, like Countly, PostHog, ...

Most of them still assume:

websites, not distributed instances,
user tracking (even anonymized),
dashboards designed for marketing teams,
heavy setups for very simple questions.

What I needed was much simpler.

What I actually need as a developer / CTO

For open-source and self-hosted software, my questions are boring but essential:

Is this instance still running?
Is anyone using this feature?
Is adoption growing or stagnating?
Did this release break usage patterns?

I don’t need:

page views,
funnels,
session replay,
user identity.

I just need signals, not surveillance.

A pragmatic response: build something smaller

So I built a small open-source service called SHM (Self-Hosted Metrics).

It’s intentionally minimal:

it accepts simple JSON events,
it doesn’t track users,
it’s agnostic to the application,
it works well with self-hosted deployments.

The goal is not analytics.
The goal is observability of usage, without violating the principles of open-source or self-hosting.

Repository:
👉 https://github.com/btouchard/shm

What this says about the open-source ecosystem

A lot of real needs sit between:

“no metrics at all”
and “full SaaS analytics stacks”

Big tools don’t care about these needs.
They’re not scalable, not monetizable, and not flashy.

But for maintainers, indie developers, and small teams, they matter.

Not everything needs to be measured like a growth funnel.
Sometimes, knowing that your software is simply used is enough.