Article 11
Why production uses containers and how to operate them securely
Learn images, containers, registries and orchestration, then see how consistency, isolation, scaling and deployment help production and where security still matters.
The problem containers solve
Start with the people using the system
It works on my machine is usually an environment mismatch
Software depends on runtimes, libraries, packages, configuration and startup commands. Differences across development, test and production cause inconsistent behavior. A container image packages the application and dependencies into a repeatable artifact, but it does not automatically provide security or resilience; networks, secrets, storage, limits and updates still need design.
Terms before you begin
Technical language, explained by what each part does
You do not need to memorize every term. Use this section as a map while reading the detailed explanation.
- Image
- A read-only package containing the application, runtime, dependencies and startup metadata.
- Container
- A process started from an image with defined filesystem, network and resource boundaries.
- Registry
- A versioned image repository such as Amazon ECR with access controls.
- Orchestrator
- A platform such as ECS or Kubernetes that schedules, replaces and scales containers.
- Immutable
- The practice of replacing a release with a new versioned image instead of editing it in place.
- Volume
- Storage whose lifecycle is independent from a container.
- Health Check
- A probe confirming an instance is ready to serve, not merely that its process exists.
- Resource Limit
- CPU and memory ceilings that contain noisy or failing workloads.
Summary for business and everyday users
Why production uses containers and how to operate them securely
An image is an immutable template; a container is a running instance.
Build once and promote the same artifact from test to production to reduce environment drift.
Containers share the host kernel, making them lighter than VMs but not a perfect security boundary.
Production needs registry controls, scanning, non-root execution, limits, health checks, secrets and suitable orchestration.
Interactive explanation
See how the stages connect before reading the detail
Select a stage to understand what happens, what evidence to inspect and how one decision affects the next stage.
Step 01 / 05
01 / Understand the unit
A container is an isolated process, not simply a tiny virtual machine
A VM includes a guest operating system. A container shares the host kernel and uses namespaces and control groups for isolation and resources, so it starts faster and packs more densely. Kernel risk and excessive privileges still matter; high-isolation workloads may require VMs or stronger sandboxes based on threat model.
In-depth explanation
Work through each issue in real operating context
Each section connects business impact with what a Tech Lead needs to inspect, including examples, evidence and constraints.
01 / Understand the unit
01A container is an isolated process, not simply a tiny virtual machine
A VM includes a guest operating system. A container shares the host kernel and uses namespaces and control groups for isolation and resources, so it starts faster and packs more densely. Kernel risk and excessive privileges still matter; high-isolation workloads may require VMs or stronger sandboxes based on threat model.
02 / One artifact
02Build once, test the same image, then promote it
A pipeline should build from a known commit, test, scan, produce an SBOM, sign and store the image. Deploy immutable digests instead of floating latest tags and promote the same digest through environments. Rebuilding for production can silently change dependencies.
- Use maintained minimal base images
- Lock dependency versions
- Keep an SBOM
- Scan at build and for newly disclosed CVEs
- Expire obsolete images
03 / Reduce privilege
03A clean image is not enough when runtime privilege and network access are broad
Run as non-root, prefer read-only filesystems, drop unused capabilities, forbid privileged mode, restrict egress and inject secrets from a dedicated manager. Set CPU and memory requests and limits, and patch the host/runtime because containers do not remove platform maintenance.
Enforce policy as code in CI/CD or admission control so human review is not the only defense.
04 / Separate state
04Containers should be replaceable, so durable data lives outside them
Do not store durable user data in the writable container layer. Use managed databases, object storage or backed-up volumes. Restrict service-to-service network paths, expose only intended entry points and use stable service discovery as instances change.
05 / Choose the right level
05Docker Compose, ECS and Kubernetes address different operating scales
Compose suits local, test and simple single-host operation. ECS/Fargate provides managed orchestration on AWS. Kubernetes offers broad flexibility and ecosystem at a real cost in expertise, security, upgrades and incident response. Choose the simplest platform that satisfies availability, scale and governance needs.
Checklist before action
Use maintained minimal images
Run as non-root
Pin image digests
Scan CVEs and create an SBOM
Keep secrets out of images
Set CPU/memory limits
Define readiness and liveness
Keep durable state external
Restrict ingress and egress
Test rolling deployment and rollback
References
Figures and examples create a discussion framework. Validate them against the real system and its constraints before deciding.
- Reviewed by
- SIS Platform Engineering
- Last reviewed
- 2026-07-17
Not sure where to start the review?
Use a preliminary tool or share the system context with SIS so the highest-priority work can be identified.