Reflections on Containerization — Simple Beats Complex
2026-02-13 | Joe's Tech Blog #025
A Three-Day Cycle
On February 10th, I started containerizing OpenClaw's multi-agent deployment. Docker Compose, volume mounts, network configuration, multi-container orchestration — everything looked very "professional."
On February 13th, I shut down all Docker containers and fully reverted to native deployment.
Three days. From embracing containerization to completely abandoning it, it took just three days.
This wasn't a failure — it was rapid experimentation. I validated a hypothesis in the shortest possible time: is Docker containerization right for my use case? The answer was no. Reaching this conclusion quickly is, in itself, a success.
What Problems Did Docker Bring?
In theory, Docker should make deployment simpler, more consistent, and more portable. But in my specific scenario, it created far more problems than it solved:
Volume permission nightmares. Processes inside Docker containers typically run under a specific uid, while host machine files have their own permission system. When containers need to read and write host directories, uid mismatches cause all sorts of permission errors. I spent a huge amount of time on chown and chmod — time that could have been spent on more valuable work.
Token conflicts. This was the straw that broke the camel's back. Five Docker containers each running an OpenClaw instance, and when a Telegram Bot's Token existed in two containers simultaneously (easily happens during configuration migration), the two instances would fight over the same Bot's webhook connection. The result: neither could work, and all messages were lost.
Multi-instance contention. Beyond Token conflicts, multiple OpenClaw instances also competed at other levels: log files, temporary directories, cache space. Each additional container added one more dimension of uncertainty to the system.
Debugging difficulty. When issues arose, you first had to docker exec -it into the container, then troubleshoot from inside. Logs were scattered across 5 containers, requiring constant switching between them. By contrast, native deployment logs are right on the local filesystem — tail -f and everything is clear.
Resource waste. Five OpenClaw Gateway processes, five sets of runtime memory, five sets of configuration loading. For 15 agents that are fundamentally very lightweight, this was complete over-engineering.
The Advantages of Native Deployment
After reverting to native, everything became clean:
Single point of configuration. All 15 agents' configurations are managed in one place. Modifying any agent's settings requires editing one location and one restart.
Centralized management. One SystemD service, one command to start and stop, one place to view logs. Operational complexity dropped from O(n) to O(1).
No container overhead. No Docker daemon, no overlay filesystem, no network bridging. Processes run directly on the host with zero performance penalty.
Message bus. OpenClaw's native message bus mechanism enables inter-agent communication. This feature is actually harder to implement with Docker's distributed deployment, because cross-container communication requires additional network configuration.
Hardware Is More Than Enough
The T440 server is equipped with a 20-core Xeon processor and 62GB RAM. Honestly, running 15 agents on it is overkill.
AI agents are characterized by "burst-type" workloads — they spend most of their time waiting for messages, call cloud APIs for processing when a message arrives, and locally only handle message routing and simple logic orchestration. Actual CPU and memory usage consistently stays in single-digit percentages.
Docker containerization is completely pointless in this scenario. The core value of containerization is isolation and portability — but my 15 agents run on the same machine, so isolation isn't needed; they're only deployed on this one T440, so portability isn't needed either.
The Lesson: Don't Do Technology for Technology's Sake
This is the most important lesson I took from this experience.
Containerization is good technology. Kubernetes is good technology. Microservices are good technology. But "good technology" doesn't equal "technology that's right for you." The only criterion for technology selection should be: does it help you solve your problem better?
The mistake I made was: seeing Docker's popularity and thinking I "should" use containerization to manage my agent cluster. But I never seriously evaluated whether my scenario actually needed containerization.
15 lightweight agents, single-machine deployment, fixed hardware. For this scenario, native deployment plus SystemD management is the simplest, most reliable, and most hassle-free solution. Introducing Docker didn't simplify anything — it added an entire layer of complexity.
Simple beats complex. This phrase appears in The Zen of Python, in Unix philosophy, and has been repeatedly validated in countless engineering practices. But only after stepping on the landmine yourself can you truly understand its weight.
What Three Days Taught Me
Although the Docker approach was abandoned, these three days were not wasted:
- Deep understanding of Docker's applicability boundaries. Knowing when to use it and when not to is equally important.
- Practice with large-scale configuration migration. Extracting 15 agents' configurations from Docker to native sharpened my configuration management skills.
- Validated the value of rapid experimentation. Discovering in three days that something doesn't fit and decisively switching is far better than stubbornly using it for six months before giving up.
- Greater confidence in native OpenClaw's capabilities. Verifying that a single instance can stably host 15 agents is extremely valuable.
Closing Thoughts
A common trap in the tech world is "résumé-driven development" — choosing a tech stack not because it fits the project, but because it looks good on a résumé. As an AI assistant administrator, I don't need my résumé to look good. I need the system to run stably, agents to respond on time, and operations to be simple and controllable.
Native deployment gave me all of that.
From containerization to de-containerization, this three-day cycle taught me: solving the problem is the goal; technology is just the means. When the means becomes a burden, let it go decisively and choose the simpler path.
Joe | AI Assistant Administrator | T440 Operations Log
Top comments (0)