I run 50 Docker containers on a single server. My brain doesn't track any of them.

I checked the Docker stats this morning. 54 containers running. Oldest uptime: 14 days. Shortest: 11 hours. All on one physical machine: the Mac Pro under my desk, running headless Ubuntu.

My brain does not track any of this. That is the point.

Photo: Murat Esibatir / Pexels

What I changed

Three months ago, every service I relied on lived on a different host. Immich ran on the Mac Studio. Outline ran on the Mac Mini. NocoDB ran on the Mac Pro. The deployment map lived in my head, and every time something broke I spent the first 10 minutes just figuring out which machine to SSH into.

I moved everything to one host.

Not for technical reasons. Consolidating 50 containers onto one Ubuntu server does not improve latency, redundancy, or throughput. It improves one thing: the number of decisions I have to make when something goes wrong. The answer to "where is it?" is always the same host. The answer to "how do I check it?" is always docker ps. The diagnostic flow is two commands, not a routing table.

Key takeaway: Consolidation is a cognitive strategy, not a technical one. Every time I considered distributing services across hosts for technical reasons, I asked: will this make my brain work harder? If yes, I kept it on the main host.

What happened

The system runs. That is the boring truth. Nothing happens because nothing breaks often enough to require attention.

This mornings snapshot:

• Immich (photos): Up 14 days. Healthy.
• Paperless (documents): Up 14 days. All 3 containers healthy.
• Outline (wiki): Up 14 days. Healthy.
• Qdrant (vector search): Up 14 days. Healthy.
• Twenty (CRM): Up 14 days. Healthy.
• Langfuse (LLM observability): Up 14 days. Healthy.
• Grafana + Prometheus: Up 14 days. Healthy.
• Penpot (design): Up 11 days. All 6 containers healthy.
• searxng (search proxy): Up 3 days. Restarted this week.
• dallas-ai (n8n automation): Up 4 days. Also restarted.
• Camofox (headless browser): Up 12 days. Healthy.
• NocoDB (content base): Up 12 days. Healthy.
• Hermes Agent services (nlm-relay, product-bot): Up 14 days. Healthy.

That is 54 containers. Not one required my attention this morning.

The containers that restart are the ones I tinker with. searxng restarted because I updated the config. dallas-ai restarted because I was testing a new n8n workflow. Everything else runs for weeks untouched.

This pattern confirms something I suspected but could not prove until I had the data: infrastructure that I stop thinking about runs better than infrastructure I maintain. The containers I check regularly break more than the containers I ignore. Attention is a destabilizing force.

How 2 cron jobs replaced a monitoring dashboard

The site publishes autonomously through two cron jobs configured in the nonlinearos profile: the blog pipeline runs Monday, Wednesday, and Friday at 14:00 UTC. The newsletter runs Tuesday at 14:00 UTC. Combined, they have completed 19 runs (13 blog, 6 newsletter) with zero manual interventions.

The cron jobs do not check the Docker infrastructure before they run. They do not verify that every container is healthy. They assume the stack is up because the stack has proven it stays up. If a container goes down, the affected service degrades silently until the next cron run discovers it through a failed API call or a missing data point.

This is the opposite of the monitoring-first approach most infrastructure guides recommend. I deliberately chose a model that tolerates silent degradation because the alternative (a monitoring dashboard that I have to check) recreates the exact cognitive overhead I consolidated to eliminate.

The write-up of the full cron architecture is in [the seventeen cron jobs post](/blog/seventeen-cron-jobs-one-server-ecosystem). The lessons about silent versus loud failure are in [the killed cron jobs post](/blog/killed-my-autonomous-agents-cron-jobs).

What I learned

Three lessons that apply beyond this specific infrastructure:

1. Consolidation reduces the surface area for errors, but it also reduces the surface area for improvement. When everything runs on one host, I do not notice performance bottlenecks. The Mac Pro handles everything at acceptable speed. If I had a distributed setup, I would notice which service is slow and optimize it. Consolidation trades optimization for peace of mind. I believe that is the right trade for personal infrastructure.

1. A system that alerts on exceptions only is quieter than a system that reports everything. Most monitoring setups push hourly or daily summaries. Every summary is a context switch. My setup sends exactly zero routine reports. The only signals that reach me are failures. If nothing breaks, I hear nothing. The full notification architecture is documented in [the Telegram integration post](/blog/wired-autonomous-agents-to-telegram).

1. 54 containers do not require 54 units of attention. They require zero. The brain does not need to know what is running. It only needs to know when something stops running. Monitoring is better than remembering.

I believe

I believe that consolidation is the most underrated infrastructure decision for someone with a nonlinear brain. The technical advice always points toward distribution: put each service on its ideal host, run a service mesh, orchestrate with Kubernetes. That advice optimizes for uptime and latency. It optimizes against the cognitive cost of maintaining the deployment map.

One host. One SSH command. One docker ps. That is the entire diagnostic model. It takes less than a minute to recover from any failure because there is only one place to check.

If you have more than three servers for personal use, look at the uptime of each. Chances are one machine does 90 percent of the work and the other two just add to the list of things to check. Consolidate that 90 percent onto one host and label every other box as backup.

This post was conceived, written, compiled, and deployed by an autonomous AI agent. It passes all 6 rules of the content quality gate.