Skip to content

Container Fundamentals

Last updated View as MarkdownAgent setup

A Cloudflare Container runs your container image in a full Linux environment on Cloudflare's network, alongside a Worker. The Worker handles incoming HTTP requests, while the Container provides the runtime, binaries, and languages your application needs. Together, they let you run Linux workloads without managing the underlying infrastructure.

The Container runtime

Run Linux workloads alongside your Worker.

A Worker runs code in an isolated JavaScript environment. A Container runs your image in a full Linux environment, so you can bring custom runtimes and binaries when your application needs them. Each Container instance runs inside its own virtual machine, which isolates it from other workloads. The Worker receives inbound HTTP requests and routes them to the Container, so the Container is not exposed directly to end users.

For more information, refer to Lifecycle of a Container.

How requests reach a Container

Route every request through your Worker.

The request begins at your Worker, which uses the Durable Object layer to identify and reach a Container. This layer coordinates routing and lifecycle behavior, allowing the Container to continue serving requests while it runs. A Container can start when it receives its first request, so the first request may take longer to complete.

Choose an instance identity to send a request

For more information, refer to Lifecycle of a Container.

Container lifecycle

Start on demand, then stop when idle.

A Container starts when your application needs it, so the first request can take longer while its environment starts. Once running, it serves requests until it becomes inactive; after an inactivity period, it can stop and release its running resources. When another request arrives, the Container can start again.

For more information, refer to Lifecycle of a Container and Pricing.

Sizing

Choose resources for your workload.

Container instance sizes let you match resources to your workload. You can choose a predefined size or configure a custom one, with larger sizes providing more CPU, memory, and disk. When choosing a size, consider the resources your application needs and refer to Limits and instance types for the available options and constraints.

For more information, refer to Pricing.

Placement

Place instances near users or within constraints.

Cloudflare places Container instances across its network, helping applications serve users from suitable locations. You can constrain placement by region or jurisdiction when your workload has location or data residency requirements. You can also run multiple instances when your application needs more capacity.

Choose a location
to send a request

For more information, refer to Placement.

Storage and connectivity

Keep durable data outside the local disk.

Treat a Container's local disk as temporary working space, because data on it can be lost when the Container stops or restarts. For data that must persist, use Durable Object storage or Cloudflare storage bindings such as KV, R2, and D1. Configured outbound handlers let the Container access these bindings and external services without requiring an SDK inside the Container.

Idle — click Next to step through the request

For more information, refer to Connect to Workers and bindings and Outbound traffic.

Start building

When you are ready to build, start with a deployed Container or explore the available guides.

Guides

Task-focused walkthroughs for common container workloads.

Was this helpful?