An application container is a unit of software that typically runs a single process. It’s a stateless, service-centric or microservice-centric form factor that encourages immutable, ephemeral infrastructure. When you need to update what the container runs, you don’t patch the live container — you build a new container from a new image and replace the running instance.
How they differ from system containers
System containers behave like lightweight VMs: they’re stateful, they boot a full userland, and they run any number of processes inside. Application containers do the opposite — they’re stripped down to one process and they treat the filesystem as read-only at runtime.
The trade-off:
- System containers fit traditional applications that expect a familiar Unix environment with multiple cooperating processes.
- Application containers fit horizontally scaled services where each instance does one job and any persistent state lives somewhere else.
State and persistence
Application containers don’t keep state. Anything that needs to survive a restart — uploaded files, session data, application config, logs, database content — has to live on external storage. The platform supplies several patterns for this:
- Persistent volumes mounted from local filesystem, dedicated data containers, layer master containers, or external NFS servers.
- Managed database tiers that other application containers connect to over the internal network.
- Object-style shared storage for file uploads and binary blobs.
- Centralized log shipping to keep logs out of the container’s filesystem.
This separation of code and state is what makes ephemeral infrastructure work — you can rebuild any container at any time without losing what users care about.
Why early adoption was slow
In the early days of application containers, the model had real friction. Isolation between containers was weaker than it is today, some technologies (notably Java runtimes and database engines) didn’t behave well as single-process containers, and developers had to make significant changes to fit existing applications into the model.
Most of that friction is gone. Container runtimes are mature, isolation has improved, and the ecosystem of supporting tools — schedulers, service meshes, observability, secret managers — makes large-scale operation practical.
Implementations and the platform’s choice
Several application-container runtimes are in active development: Docker, CRI-O, containerd, and others. Stack Harbor PaaS uses Docker, which is the most widely adopted of the set. The platform layers on top of Docker the things that aren’t part of Docker itself: deployment automation, fast container provisioning, snapshot and backup support, log and config managers, and a place to put the state your containers shouldn’t keep.
When system containers are still the better choice
Some workloads still don’t migrate well to application containers. Watch for:
- Apps that expect multiple cooperating processes (
systemd-style services, supervisord trees, cron daemons running alongside the main process). - Apps that need root or kernel-level changes at runtime.
- Stateful databases or message queues where the storage-and-replication story isn’t a solved problem in a single-process model.
- Heavy isolation requirements that exceed what application containers provide.
For these, the platform’s system containers — or its certified managed stacks built on them — are usually the better fit. For everything else, application containers (Docker or Kubernetes) give you faster scale-out and a cleaner deployment story.