Container management covers everything that happens after an image has been built, such as: storing it, deploying it, keeping it healthy, scaling it, updating it, and eventually removing it. Docker Compose, Kubernetes, Amazon ECS, and Cloud Run all handle parts of that lifecycle, but at very different levels of abstraction.

This guide follows a container from a local build into production and compares how those platforms manage the same workload covering registries, scheduling, networking, state, security, observability, releases, and the operational work each option leaves with the application team.

We'll also look at how Encore handles the compute, networking, permissions, and managed resources around a backend application, and when that can reduce the container-management work your team owns.

The container lifecycle

Container management follows the image from source to retirement, with deployment sitting in the middle of the process rather than at the end.

Keeping the image immutable connects the stages because the exact digest that passed testing can move into staging and production instead of being rebuilt for each environment. Configuration and secrets arrive at runtime, while database migrations and other stateful changes are coordinated with the rollout.

Because the registry sits in the delivery path rather than acting as a passive file store, it needs retention rules, pre-deployment scanning, and signing or provenance checks that let the runtime reject artifacts created outside the expected build process.

What the runtime needs around a container

Packaging the process and its filesystem does not create a production service, since the runtime still has to decide where the process runs, how much CPU and memory it receives, how traffic reaches it, when it is healthy, which credentials it can use, and what happens when it fails.

Whether the decisions are written in an ECS task definition, Kubernetes workload, Cloud Run service, or Compose file, they answer much the same questions:

• Which image digest and command should run?
• Which port accepts traffic, and which callers may reach it?
• What should happen when readiness or liveness checks fail?
• Which identity can the process assume, and which secrets may it read?
• How many copies should run, and what signal changes that number?
• How does a new version replace the old one, and how is a failed release rolled back?

Networking and identity deserve particular attention because they define the effect of a compromised process. Private placement does not remove the need for egress controls, and a workload role should grant access to the bucket or queue the application uses rather than broad access to the cloud account. Secrets belong in a managed store and should reach the workload at runtime instead of being copied into the image.

Container output only becomes useful operationally when centralized logs carry request or job identifiers, metrics show saturation and error rates, traces cross service boundaries, and deployment events remain visible beside application telemetry. Otherwise a rollout failure often looks like an unexplained traffic spike or timeout.

Deployments, scaling, and state

Because any healthy stateless replica can take another copy's traffic, a scheduler can replace them through rolling deployments that start new instances, wait for readiness, and drain the old revision. Blue-green and canary strategies add control when the risk or traffic volume justifies it.

Autoscaling only helps when its signal matches the workload, such as CPU for a compute-bound API, request count behind a load balancer, or queue depth for asynchronous workers. Minimum capacity, startup time, database connection limits, and downstream rate limits determine whether the scaled service can actually absorb the traffic.

State changes the model. Databases and durable queues are usually managed outside the application container, while persistent volumes require a clear ownership and recovery plan. Schema migrations should remain compatible with both the old and new application during a rolling deployment, and background jobs need idempotency when a retry can cause the same item to run twice.

These operational details matter more than the number of features in the orchestrator. A simple managed runtime with a clear rollback and ownership model is often safer than a flexible cluster whose policies, controllers, and upgrades nobody has time to maintain.

Choosing a container management approach

The workload and the people operating it narrow the choice quickly. Kubernetes earns its larger surface when a platform team can turn it into a consistent internal product. ECS fits naturally when the organization is already built around AWS. Cloud Run removes much of the scheduler configuration for workloads that fit its execution model, while Compose remains valuable locally even when production uses something else.

For a closer comparison of Kubernetes, ECS, Nomad, Swarm, and Cloud Run, see the best container orchestration tools.

Managing the application instead of the containers

A containerized API may also need a database, queue, or storage bucket. With Encore, you declare those resources in the application code, and they are provisioned together when you deploy.

Services can run on ECS Fargate on AWS or Cloud Run on GCP, depending on the environment settings. The deployment includes the networking and IAM configuration needed to access the declared resources.

SQLDatabaseTopicSubscriptionBucketSecretCacheCluster

todo/db.ts

import { SQLDatabase } from "encore.dev/storage/sqldb";

const db = new SQLDatabase("todo", {
  migrations: "./migrations",
});

Amazon RDS

Cloud SQL

Managed PostgreSQL with migrations, pooling and IAM auth

Workloads that need privileged containers, custom scheduling, host agents, or direct control of a shared cluster require a container platform that exposes those controls.

Related guides

• What is Amazon ECS?
• Docker and Kubernetes: how they work together
• The best container orchestration tools
• What is AWS Fargate?
• Do you need Kubernetes?
• Deploy to AWS without Kubernetes