Containers are frequently discussed as a scaling technology. On a single cloud account their real value is different and more immediate: the thing you tested is byte-for-byte the thing that runs.
What genuinely improves
- Reproducibility. The image includes the runtime, the libraries and the system packages. “Works on my machine” stops being a category of bug.
- Rollback. The previous image still exists. Reverting is starting the old tag, not undoing a deployment.
- Isolation between services on one host, without one application’s dependency upgrade breaking another.
- A deployment artefact. The build produces one object that can be signed, scanned and promoted between environments.
What does not change
Containers do not reduce the resources your software needs. A process using two gigabytes of memory uses two gigabytes in a container. Sizing the server is the same exercise as before — see how much RAM a cloud server needs.
They also do not make an application horizontally scalable. If it stores state locally, containerising it produces a container that stores state locally.
What gets harder
- Persistent data. Containers are disposable, your database is not. Volumes must be mapped deliberately, and a container recreated without its volume is data loss.
- Logging. Logs go to stdout and are collected by the runtime. Log rotation and disk usage move from your control to the daemon’s configuration, which has its own defaults worth checking.
- Networking. There is now a virtual network between your services, and published ports interact with the host firewall in ways that surprise people. Verify from outside — see firewall rules for a new cloud server.
- Image size and pull traffic. A large image pulled on every deploy is real bandwidth. Multi-stage builds and a small base image matter more than they look.
The smallest setup worth running
- A single cloud server with the container runtime installed.
- A compose file in version control describing the services.
- A registry — the provider’s, or a public one with a private repository — so images are built once in CI and pulled, never built on the production host.
- Named volumes for anything that must survive a container being replaced.
- A reverse proxy terminating TLS in front of the application containers.
- Restart policies set, so a reboot brings everything back.
That handles a surprising proportion of production workloads and needs no orchestrator. Kubernetes becomes worth its complexity at a specific and recognisable point, and that point is further away than most teams assume.
Do not build on the production host
Building images on the server that serves traffic consumes the CPU and disk that the application needs, and leaves build caches accumulating until the disk fills. Build in CI, push to a registry, pull on the host. This is the single change that makes container deployment feel calm.
Where to go next
- Kubernetes: when the complexity pays for itself
- Serverless vs virtual machines
- Monitoring a cloud server
Questions
Frequently asked
Do containers use fewer server resources?
No. A containerised process needs the same CPU and memory as the same process outside a container. The overhead of the runtime itself is small but not negative.
Can I run a database in a container?
Yes, with a named volume for its data directory and a clear backup process. The risk is operational: recreating the container without its volume destroys the data.
Do I need Kubernetes to use containers?
No. A single host running compose with a registry and a reverse proxy covers a large share of production workloads without any orchestrator.