Under the hood Bindings

How Devflare wires Containers from config to runtime

Containers let a Worker hand requests to stateful code running from a container image.

Containers compiles from to Wrangler , with local/test behavior called out explicitly.

Use this page when you need emitted config, preview behavior, or Cloudflare-specific limits. The overview and example pages stay focused on everyday app code.

Normalization: Devflare normalizes before emitting Wrangler
Compile target: Wrangler
Preview note: Cloudflare owns deployed container rollout, managed registry availability, SSH, scaling, and hosted platform behavior; Devflare owns the Docker/Podman local loop.

How authored config becomes Wrangler config

The authored config stays camelCase and project-oriented. The compiler translates that into the Wrangler keys Cloudflare expects.

The emitted output is shown here so the usage pages do not have to explain compiler details.

Containers config and emitted Wrangler output

Use this when you need to check how the Devflare config becomes Wrangler-compatible config.

import { defineConfig } from 'devflare/config'

export default defineConfig({

name: 'container-worker',

files: {

fetch: 'src/container.api.ts',

durableObjects: 'src/container.api.ts'

bindings: {

durableObjects: {

API_CONTAINER: {

className: 'ApiContainer'

}

containers: [

{

className: 'ApiContainer',

image: 'localhost/devflare-api:latest',

imageBuildContext: './containers/api',

maxInstances: 1

}

migrations: [

{

tag: 'v1',

new_sqlite_classes: ['ApiContainer']

}

]

})

What local runtime support covers

Offline-native only when an explicit Docker/Podman engine is available and the image can run without pulling
The default docs recipe uses containers helpers guarded by .
Pure unit tests can use / / when the test only needs deterministic application behavior.

Compile, preview, and cleanup behavior

Devflare emits Wrangler from the native config surface.
Preview and deployment lifecycle stay feature-specific; do not assume all Cloudflare products can be created, cloned, or cleaned up the same way.
Cloudflare owns deployed container rollout, managed registry availability, SSH, scaling, and hosted platform behavior; Devflare owns the Docker/Podman local loop.

Cloudflare docs vs the Devflare layer

Cloudflare Containers docs is the platform reference. Use this internals page when you need to compare Cloudflare's product docs with Devflare config, generated env types, local support, and preview behavior for .

Reference

Cloudflare Containers docs

Cloudflare Docs

Platform reference for the Container class, container instances, and Worker interaction helpers.

Question	Cloudflare docs	This Devflare page
Primary focus	Platform reference for the Container class, container instances, and Worker interaction helpers.	How to author , what the runtime surface looks like, and how Containers fits a Devflare project.
Testing and runtime lens	Cloudflare’s docs focus on the raw binding API, product semantics, and platform limits for the binding itself.	Offline-native only when an explicit Docker/Podman engine is available and the image can run without pulling. Use the Devflare guidance when you need the honest local harness or the right remote gate instead of only the product API shape.
When to open it	When you need the platform contract, limits, APIs, or account-level product details.	When you are wiring, testing, previewing, or reviewing the binding inside a Devflare app.

Containers

Add the Containers config, call Container class config plus a Durable Object container binding from worker code, and start with the local test path Devflare supports.

Testing Containers

Test Containers by choosing the local harness that matches the product boundary instead of reaching for Cloudflare by default.