Use Containers in a real application path
Containers let a Worker hand requests to stateful code running from a container image.
A compact Containers recipe with config and worker usage in one application path.
Use this as the copyable starter before threading the feature into a larger application.
- Config focus
- containers
- Runtime shape
- Container class config plus a Durable Object container binding
- Best use
- routing requests to a stateful container instance that runs code outside the Workers runtime
Start by wiring the binding clearly in config
Smallest Containers config
Build the application flow around the binding
Treat this as the app-level Containers path: the route, event handler, or service module receives a real request and uses the binding to do useful work.
Keep product limits, remote ownership, and fallback behavior visible in the code around the binding instead of hiding everything behind a vague utility too early.
- Keep the first example short enough to paste into a new Worker.
- Cloudflare owns deployed container rollout, managed registry availability, SSH, scaling, and hosted platform behavior; Devflare owns the Docker/Podman local loop.
Proxy one application route to a container instance
Keep production boundaries visible
- Config focus: containers.
- Runtime shape: Container class config plus a Durable Object container binding.
- Best use: routing requests to a stateful container instance that runs code outside the Workers runtime.
Thread this into the next recipe
Once this smallest path works, add routing, generated types, and feature-specific abstraction in that order.
Previous
Testing Containers
Test Containers by choosing the local harness that matches the product boundary instead of reaching for Cloudflare by default.