When the Infrastructure Layer Owns Your AI
Cloudflare's Moltworker markets itself as 'self-hosted AI' — but it runs on Cloudflare's edge. Here's what real AI data sovereignty actually requires.
The AI platform you build on owns more of your AI stack than the marketing implies — and the difference between a “tool” and a “service” determines whether you control your own work. When 288 Hacker News users cancelled their Claude Design subscriptions and immediately lost access to projects they had built, the engineers in the thread weren’t surprised: “You didn’t build that in a tool. You built it in a service.” That distinction is about to get harder to see, because major infrastructure companies are now marketing vendor-controlled products as “self-hosted AI.”
What this article covers:
- What Cloudflare and similar vendors mean when they say “self-hosted” — and what they’re omitting
- The two fundamentally different kinds of “self-hosted AI” and what each actually protects
- Why the category is getting harder to navigate as infrastructure vendors blur the line
- What real AI sovereignty requires and what it looks like in practice
What does Cloudflare mean by ‘self-hosted AI’?
In January 2026, Cloudflare released Moltworker — an implementation that lets you run Moltbot, an open-source personal AI agent platform, on Cloudflare’s Developer Platform. The marketing positioned it squarely in the “self-hosted AI agent” category. No dedicated hardware required. Just deploy to Cloudflare.
Here’s the problem with that framing.
Moltworker runs on Cloudflare Workers — Cloudflare’s global edge compute network. Your agent runtime, conversation persistence (stored in Cloudflare’s R2 object storage), and configuration all live inside Cloudflare’s infrastructure. You don’t need your own hardware because the hardware is Cloudflare’s. The “self-hosted” in this context means you configured it, not you run it.
That distinction matters for a few concrete reasons:
Your data routes through Cloudflare. Every agent interaction, every conversation, every tool call — it transits Cloudflare’s network. The fact that you wrote the code doesn’t change where it runs.
Cloudflare controls your runtime. If Cloudflare changes Workers pricing, deprecates an API, enforces an acceptable use policy, or simply has an outage, your agent infrastructure is affected. You don’t control the platform.
Exit is genuinely hard. Your agent state, conversation history, and configuration are wrapped in Cloudflare primitives. Migrating to a different runtime means rebuilding around a different set of abstractions — not just changing a config file.
None of this is a criticism of Cloudflare. Workers is a well-built platform and Moltworker is a thoughtful project. The point is that “self-hosted” has become a marketing term, not an architectural description. When your team deploys business workflows onto infrastructure you don’t actually control, the distinction isn’t academic.
What are the two fundamentally different kinds of ‘self-hosted AI’?
When engineers and CTOs say they want self-hosted AI, they’re usually thinking about one of two things:
Type 1: Configured-by-you, hosted by them. You write the configuration, build the agents, set the prompts — but it all runs on a vendor’s infrastructure. The vendor controls compute, storage, runtime, and networking. Your data lives on their servers. Examples: Cloudflare Moltworker, most SaaS agent builders, and the majority of products marketed as “enterprise AI platforms.”
Type 2: Runs on your hardware. The runtime, the governance layer, the data storage — all of it lives on servers you control. The only thing that leaves your infrastructure is the inference call to a model provider (OpenAI, Anthropic, a local model), which goes direct — not through a third-party intermediary. This is what most compliance-constrained teams actually need.
The Claude Design incident illustrates what happens when you build on Type 1 infrastructure without fully understanding it. The affected users thought they had a tool. They had a service. When the service relationship ended — in this case, because they cancelled a subscription — their access ended with it. Their data stayed in Anthropic’s platform.
Why is it getting harder to tell genuine self-hosted AI from vendor-controlled platforms?
Cloudflare entering the self-hosted agent market is significant not because Moltworker is a bad product, but because it signals something broader: major infrastructure players are now claiming “self-hosted AI” as their positioning territory.
Cloudflare has genuine credibility with developers. When they call something “self-hosted,” most people won’t examine what that word means architecturally. The brand does the work.
Microsoft’s open-source agent framework — which has been gaining traction consistently in developer discussions since its GA release — is doing something similar. The code is open source, which is real. But the natural deployment target is Azure. The framework abstractions are designed to fit Azure’s runtime model. “Open source” and “self-hosted” are not the same thing as “you control where this runs.”
As more major platforms make moves in this space — and they will, because the self-hosted narrative is winning with enterprise buyers — the terminology is going to get muddier. Buyers who came to self-hosted AI specifically to avoid vendor dependency will face a market full of products that use the right words but not the right architecture.
What does real AI sovereignty actually require?
If you’re a technical lead evaluating AI platforms — especially in healthcare, finance, legal, or any regulated industry — here’s what “self-hosted” needs to mean to actually protect you.
1. The governance layer runs on your infrastructure. Routing, access control, audit logging, agent orchestration — this layer needs to run on servers you own or control. Not “deployed by you to a vendor’s edge network.” Actually running on your hardware (on-prem, or a VPC you control).
2. Inference calls go direct to the model provider. When your agent calls Claude or GPT-4o, that request should go directly from your server to the provider’s API — not through a third-party gateway that logs, rates, or routes the call on your behalf. If a vendor sits in the middle of your inference calls, they have visibility into your prompts and outputs.
3. Your data doesn’t live on vendor infrastructure. Conversation history, agent state, context files, documents your agents reference — all of this should live in storage you control. Not in a managed database owned by your AI platform vendor, and not in object storage you can’t directly export from.
4. You can exit without rebuilding. If you decide to swap models, change providers, or migrate off the platform entirely, you should be able to do it without rewriting agent logic. This means your agents aren’t built on proprietary abstractions that don’t port. Model flexibility at the routing layer — not the agent layer — is what makes this possible.
5. Audit logs belong to you. Who accessed what agent. What the agent did. What model it called, when, and at what cost. This data needs to be in storage you control, available for compliance review without going through the platform vendor.
The Claude Design users who lost access to their projects yesterday failed the last two tests. They couldn’t exit cleanly, and their work lived in Anthropic’s infrastructure. Neither problem was visible until the moment it mattered — which is exactly when you need to not be discovering it.
What does genuine AI infrastructure ownership look like in practice?
For a 50-person healthcare company, a law firm, or a financial services team, the practical version of this architecture looks like:
- The AI gateway runs on your own server (on-prem or a VPC you control)
- Employees access agents through that gateway — not through individual SaaS accounts
- The gateway handles routing (which agent uses which model), access control (who can use what), and audit logging
- Model calls go direct from your server to the provider’s API — you’re just a customer with an API key
- Context files (your procedures, pricing documents, client data) live on your file system
- If you need to swap from Claude to GPT-4o for a particular agent, you change a routing config — not rebuild the agent
This architecture isn’t complicated. But it requires the gateway to actually run on hardware you control, which is exactly what products like Cloudflare Moltworker optimize away in exchange for a simpler setup experience.
The tradeoff is worth naming explicitly: they make it easier to start, but harder to know where your data actually goes.
What is the practical lesson from Claude Design’s cancellation policy?
The Claude Design incident will circulate through IT and legal teams for months. Not because Anthropic did something unusual — subscription enforcement on cancellation is contractually normal — but because it revealed how many technical people were operating on the wrong mental model of what they were using.
When you build on AI-native SaaS, you’re renting access to a service. That’s appropriate for many use cases. But if you’re building workflows that touch patient records, client documents, financial data, or any information you’re responsible for under GDPR, HIPAA, or SOC 2 — you need to be certain about where that data lives, who can access it, and what happens when a subscription lapses or a vendor changes its terms.
“Self-hosted” should mean your infrastructure, your rules, your exit path. The next time you’re evaluating an AI platform — including ones that use that language prominently — ask the five questions above. The architecture will tell you what the marketing won’t.
Auxot is a self-hosted AI gateway you deploy on your own infrastructure. The governance layer — routing, agents, access control, audit logs — runs on your servers. Model calls go direct to the provider. Your data never passes through us.