Introduction
I love Docker containers. They make it easy to package an application and its dependencies into a portable, reproducible unit that can run anywhere. I use them for almost everything.
So when Cloudflare announced Containers, I was immediately interested. A fully managed container platform running on Cloudflare’s edge network—spinning up instances as close as possible to the user—felt like a compelling evolution of the model.
Around the same time, Cloudflare engineers published a proof of concept featuring OpenClaw, a self-hosted AI agent running inside a Cloudflare Container (or Sandbox—more on the naming confusion later). It’s undeniably cool to see an agent operating at the edge.
However, the demo was single-tenant. It didn’t explore what it would take to build a true multi-tenant SaaS around agents—which, in my opinion, is where things get interesting—especially while the “shovel sellers” of the AI boom continue to thrive.
The Demo Application
To properly explore the idea, I built a Nuxt 4 application around a straightforward concept: a multi-tenant platform where users can sign up, create their own agent (in this case, nanobot), and manage it through a web UI. Users can configure their agent and even chat with it directly—no gateway setup required.
Each user gets a fully sandboxed container instance, eliminating the risk of cross-tenant interference. Instances have full internet access, and their ephemeral filesystems are restored manually as needed.
Architecturally, it looks like this:
- The Nuxt 4 app (with a Nitro server)
- Communicates with a Cloudflare Worker
- Which orchestrates and proxies requests to container instances
- Which run an agent runner (written in Go)
- Which executes the actual agent logic (
nanobot)
Add billing and basic account management, and you have the foundation for an agent-hosting business.
If you’re interested, you can check out the code on GitHub.
Spoiler: I got it working—but not without a few headaches. Here are some of the lessons I learned.
The Good
Deploying updated container versions is seamless with Cloudflare’s built-in image registry and the wrangler CLI. It’s genuinely impressive—you can watch images gradually roll out in real time.
Observability is also well executed. The UI provides access to logs, metrics, and traces for each container instance in a way that feels polished and production-ready.
The @cloudflare/containers SDK largely “just works,” making it straightforward to manage container lifecycle events directly from a Cloudflare Worker.
The Bad
The SDK implementations feel rushed. I make a point of reading the code I import into my projects, and I was surprised by the overall structure and quality in several places. For a platform this ambitious, the internals should inspire more confidence.
During development, I also ran into unexplained wrangler deployment failures that were resolved simply by re-running the command. Intermittent, non-deterministic failures don’t inspire trust in a production platform.
Documentation and examples for multi-tenant or SaaS-style use cases are sparse. For a product this powerful, clearer guidance would go a long way.
The Ugly
Cloudflare’s product naming and positioning in this space is confusing to the point of being counterproductive. The overlap between Sandbox and Containers creates unnecessary cognitive overhead.
They feel like overlapping abstractions built on similar primitives. Consolidating these offerings—bringing Sandbox features directly into Containers and presenting a single, coherent developer experience—would significantly reduce friction and improve adoption.
For example, Sandbox’s “Keep Alive” feature feels like baseline platform functionality. It shouldn’t require digging through the Sandbox SDK implementation and recreating the behavior manually in your own code. For a premium platform, these capabilities should be first-class and unified.
The underlying technology is powerful. The developer ergonomics—once you step outside the dashboard and work directly with the tooling—can be excellent. But the product surface area needs simplification.
And finally, the elephant in the room: pricing.
These containers are expensive. For anyone considering building a SaaS around hosted agents, cost quickly becomes a central constraint. After modeling usage, it’s hard not to compare this approach to running containers on a dedicated bare-metal server with Docker and a simple Nitro-based control plane.
Cloudflare has also built a reputation for opaque billing. It can be difficult to determine exactly what you’re spending until the invoice arrives.
It’s a bit like dining at a restaurant with no prices on the menu—you order, enjoy the experience, and only later discover the total. Greater pricing transparency and clearer cost-forecasting tools would make this platform far easier to recommend with confidence.
Conclusion
If you want to build a business selling “shovels”—erhm, agents—on Cloudflare Containers, it’s absolutely possible. I proved that.
But based on the current pricing, product fragmentation, and rough edges in the developer experience, it’s not the path I would recommend.