Cloudflare brings containers alongside Workers (public beta)

Anyone who builds web applications knows two worlds that, until now, have been awkward to keep together. On one side there are “serverless” functions: small, lightweight programs that start instantly and handle plenty of traffic, but with little memory and tight execution times. On the other there are the “real” applications, the ones that need a full environment - an operating system, system libraries, a specific runtime - and that are usually packaged into a container. On 24 June 2025, Cloudflare, one of the world’s largest network and CDN operators, opened the public beta of a service that tries to bring these two worlds closer: Containers, which run alongside Workers and are driven by the same code.

First, a refresher: Workers and containers

It’s worth being clear about the two terms, because that’s where the news lives.

A Worker is a small program that runs on Cloudflare’s servers spread around the world. It’s “serverless”: there’s no server to administer, the code runs close to whoever makes the request, it starts in a fraction of a second, and it scales effortlessly. In return it’s deliberately limited: little memory, little CPU time, a narrow environment built for JavaScript or WebAssembly. Perfect for routing requests, applying rules, composing responses; poorly suited to heavy, sustained work.

A container, on the other hand, is a way of packaging an application together with everything it needs to run: its runtime, its libraries, its system files. The upside is that it runs the same everywhere, regardless of the underlying machine. It’s the format most software ships in today, from backends to command-line tools.

The historical limitation was that Workers, on their own, couldn’t host a container: that required a separate piece of infrastructure, with its own complexity. That’s exactly what changes here: the two now live on the same platform.

What Cloudflare announced

In short: you can now run containers alongside Workers, on Cloudflare’s global network, without having to deal with orchestrators, clusters, or regions. The service is available in public beta for anyone on a paid plan.

Cloudflare frames the core idea neatly: use a Worker when you need to be lightweight and scalable; use a container when you need more power and freedom. The two aren’t competitors, they work together. The Worker stays the front door - it receives the request and decides what to do with it - and when there’s a demanding job to run, it hands it off to a container.

How Workers and containers fit together

The interesting part is that you don’t manage the container from a separate panel: you drive it from the Worker’s code. A container is described in the project’s configuration file (wrangler.jsonc) by pointing at the image to use, and from there the Worker can start it, reach it, and shut it down.

Under the hood the architecture builds on Durable Objects, another Cloudflare building block used to coordinate state and instances in an orderly way. The mechanism is easy to grasp: each distinct identifier passed to a container maps to its own isolated, dedicated instance. Need one container per user, or per job? Just use a different identifier and the platform spins up a separate one. Cloudflare chooses where on the network to start the instances, with startup times on the order of a few seconds.

The workflow is meant to be short too. Locally you develop with wrangler dev, which builds the container image automatically; to publish you run wrangler deploy, with no need to manage a separate image registry by hand.

// wrangler.jsonc, simplified
{
  "containers": [
    {
      "class_name": "MyContainer",
      "image": "./Dockerfile",
      "instance_type": "basic"
    }
  ]
}

What it’s for

The typical uses are the ones where a Worker alone isn’t enough and, until now, you’d have had to stand up a dedicated server:

Command-line tools and “batch” jobs. Existing programs, perhaps written in any language, that process something and return a result.
Media and data processing. Converting a video or an image, transforming files, running pipelines that need CPU, memory, and a real disk: tasks that would blow past a Worker’s limits, not unlike what happens when an application needs a GPU for AI inference and a lightweight function no longer cuts it.
Backends in any language. An application already packaged as a container can run as-is, with a Worker in front acting as a router.
Isolated environments for untrusted code. Giving each user a separate container, for example to run code generated or submitted by third parties without letting them interfere with one another. It’s a scenario mentioned for AI agents and the MCP servers they connect to as well, which often need an isolated space to operate in.

Why it lowers the barrier

This is the practical point. Running containers in many parts of the world today usually means dealing with a fair amount of infrastructure, the same kind usually described and versioned with Infrastructure as Code tools: choosing regions, standing up an orchestrator (often Kubernetes), configuring load balancing, handling scaling and updates. That’s work that takes specific skills and constant maintenance time.

The proposed approach shifts that weight onto the platform. You don’t pick regions: the network decides where to run. You don’t configure a cluster: you declare a container and drive it from code. For a workload that doesn’t fit inside a serverless function today but doesn’t justify running a whole cluster either, this is a way to sit in the middle with less friction.

To be honest about it, “less infrastructure to manage” also means less fine-grained control and a tighter tie to a single platform, the same trade-off worth weighing when you choose a cloud provider. It’s a trade-off, not a free lunch: it’s worth weighing case by case.

How you pay, and what the limits are

The cost model is usage-based and fine-grained: you pay only while the container is actually running, measured in very short intervals (on the order of 10 milliseconds), with CPU, memory, and disk metered separately. After a period of inactivity the container puts itself to sleep, so you don’t pay for idle time. The paid plan includes a monthly allowance; the exact figures are on the pricing page.

At launch there are three instance sizes - roughly from 256 MiB up to a few GiB of memory, with growing CPU and disk quotas - and, this being a beta, there are account-wide caps. These are limits meant for the trial phase and set to grow: Cloudflare has listed larger instances, higher numbers, and automatic, latency-aware scaling among the future work, along with tighter integration with the platform’s other services (storage, databases, key-value).

Where it stands

The usual caution applies. This is a public beta: open to anyone on a paid plan, but still a trial phase, with tight limits and features still evolving. Some things you’d expect from a mature platform - automatic scaling, larger instances, certain integrations - are stated as coming, not as already here.

The underlying idea, though, is concrete and already testable: bring containers to where Workers already run, and drive them with the same code, instead of keeping two separate infrastructures. For anyone who struggles today to fit heavy workloads into a serverless environment, it’s worth trying on a small project - bearing in mind it’s still a beta and that the bill is worth watching closely while you experiment.

# Cloudflare brings containers alongside Workers (public beta)