Running containers on a single server

Containers are strongly associated with Kubernetes, which leads people to assume they only pay off at a scale where orchestration is warranted. That is backwards. Most of the benefit arrives on a single server, and most of the cost arrives with the orchestrator.

What you get on one machine

Dependency isolation. Two applications needing different runtime versions coexist without conflict, and neither one’s requirements dictate what is installed on the host.

Reproducible environments. The image built on your laptop is the image running in production. The class of problem where something works locally and fails on the server, because of an undocumented package installed eighteen months ago, mostly disappears.

A host that stays clean. The server needs a container runtime and very little else. It stops accumulating hand-installed packages and drifting away from any documented state.

Deployments that are a single operation. Pull a new image, restart the container. Rollback is running the previous tag.

Disposability. If the machine dies, a new one plus your compose file plus a data restore reproduces the environment in minutes rather than from memory.

That last point is the important one. Hand-built servers become artefacts nobody dares rebuild. Containerised ones stay replaceable.

A shape that works well

For a single server hosting one or several applications, a workable arrangement is:

• A reverse proxy container handling TLS and routing by hostname to the other containers. Several proxies exist that obtain and renew certificates automatically and discover backends from container labels, which removes most of the configuration work.
• One container per application, on an internal container network, with no ports published to the host.
• A database, either as a container with a persistent volume or, preferably, as a managed service outside the machine.
• A compose file describing all of it, kept in version control.

Only the proxy publishes ports. Everything else is reachable only from within the container network, which is a meaningful security property achieved almost for free.

Persistence, which is where people get hurt

Container filesystems are ephemeral. Anything written inside a container and not in a volume is gone when the container is replaced, which happens on every deployment.

Three rules prevent the common disasters.

Named volumes for anything that must survive. Database data directories, uploaded files, certificates.

Understand which volumes exist. A stray anonymous volume, created because a path was declared in the image but not mapped in your compose file, holds data you will not think to back up.

Back up volumes, not just images. Rebuilding the application from an image is trivial. Rebuilding the data is not.

The failure mode is specific and common: a database running in a container with no volume declared, which works perfectly until the first redeploy, at which point the data is gone.

Keeping the machine healthy

Set restart policies so containers come back after a crash and after a host reboot. A container that does not survive a reboot is not deployed.

Set resource limits on each container. Without them, one runaway process takes down everything on the host. Memory limits in particular convert a total outage into one restarted container.

Add health checks so the runtime knows whether a container is actually working rather than merely running.

Prune regularly. Old images, stopped containers and dangling volumes accumulate and fill the disk. A scheduled prune plus a disk alert prevents the single most common failure on a busy container host. Be careful to exclude volumes from automatic pruning unless you are certain.

Centralise logs or at least configure log rotation, because container logs grow without bound by default.

Deployment without an orchestrator

You do not need a platform to deploy safely.

Build images in CI and tag them with the commit, never relying on a mutable latest tag, so you always know exactly what is running and can roll back precisely.

Deploy by pulling the new tag and recreating the container. With a proxy that health-checks backends, you can start the new container before stopping the old one and get a genuinely seamless swap.

Keep the compose file in the repository so that infrastructure changes go through the same review as code changes.

When you have outgrown it

The honest signals that a single machine is no longer enough:

• You need more capacity than one machine can provide.
• Downtime during a host reboot has become unacceptable.
• You are running enough services that placement and dependencies have become genuinely hard to reason about.
• Several teams deploy independently and are colliding.

Until those are true, the operational overhead of an orchestrator is a cost without a corresponding benefit. Two servers with a load balancer and identical compose files handles a surprising amount of growth before anything more elaborate is warranted.

What to avoid

Running the database in a container with no volume. Stated twice deliberately.

Building images on the production server. Build in CI, pull artefacts. Building on the host mixes concerns and fills the disk.

Baking secrets into images. Image layers persist and are readable. Inject secrets at runtime.

Running everything as root inside containers. Specify a non-root user; it is a one-line change that meaningfully limits what a compromise achieves.

For a view of how the providers differ on the points above, the cloud account catalogue lays out their respective strengths and configurations.

For the vendor’s own reference on the services involved here, see the Kamatera support library.

Independent sizing is easier to understand once you have set it yourself. Our Kamatera accounts come in two configurations, and the cloud account catalogue compares the other nine providers.

Questions people ask