Self-Hosted Doesn’t Always Mean What It Implies

We hear a version of this question a lot: how do Cursor Self-Hosted Cloud Agents compare to Coder Agents, especially since both are described as “self-hosted”?

It’s worth saying up front that this isn’t really a Cursor-versus-Coder story. In fact, plenty of Coder customers use Coder today to safely deploy Cursor’s IDE to their developers in centralized workspaces. We’re not pretending the market has to pick one company across the board.

The more useful point is that, when it comes to coding agents, these solutions address different environments and constraints.

Cursor’s Self-Hosted Cloud Agents architecture might make a lot of sense for teams that don’t have strict data residency requirements and can adopt a SaaS distribution model. Coder Agents is built for a different class of customer: large enterprises, regulated organizations, air-gapped deployments, and environments where teams require the option to keep source code, prompts, model traffic, and orchestration metadata within their network perimeter.

This post breaks down what “self-hosted” means in each case, because the phrase often implies more than it clearly defines.

Where “Self-Hosted” Starts to Split

AI coding agents are usually split into two layers: the execution layer, where code runs and files are edited, and the agent layer, where planning, orchestration, and model inference happen. When most people hear “self-hosted,” they don’t usually think in layers. One might reasonably assume the whole thing, agent loop and environment included, runs on infrastructure they control.

Cursor’s self-hosted cloud agents are a good example of why this distinction matters. With Cursor, the execution layer runs on infrastructure that the customer controls. The agent worker lives in that environment, executes commands locally, and interacts directly with the codebase. That’s a valid design choice for teams that want private execution without taking on the operational burden of running the full agent stack themselves.

But the agent layer still runs in Cursor’s cloud. Planning, orchestration, model routing, and the overall agent loop remain outside the customer’s environment. The worker keeps an outbound connection open to Cursor, receives instructions from Cursor’s cloud, and sends back the context needed for inference. Cursor is transparent about this: only chunks of code are sent, not the full repository. Still, those chunks leave the customer’s network.

That’s the nuance behind the label. Cursor customers self-host the environment where work gets done, but not the full agent system. For many teams, that tradeoff is perfectly reasonable. For others, especially those with strict perimeter, residency, or air-gap requirements, it’s a meaningful architectural difference.

A Side-by-Side View

Looking at the architecture more directly makes the distinction clearer:

Why This Distinction Matters

If your priority is getting up and running quickly with a strong developer experience, Cursor’s design might offer a practical balance. You keep execution on your VMs while offloading the complexity of agent orchestration and model management to Cursor’s hosted cloud service.

But for other organizations, especially in financial services, healthcare, or government, the question isn’t just where code runs. It’s where data flows, how systems are governed, and whether anything leaves the network at all.

If code context is sent externally for inference, it may be acceptable or a non-starter. If your system depends on a vendor’s cloud for orchestration, that may simplify things. Or it may introduce compliance challenges.

For the types of enterprises that come to Coder, there’s often very little flexibility here. Some operate in environments where outbound connectivity is restricted or entirely blocked. Others need guarantees that source code, model interactions, and system behavior never extend beyond their infrastructure boundary. In those cases, “self-hosted” isn’t a partial property.

What Fully Self-Hosted Looks Like

Coder Agents extends Coder’s fully self-hosted architecture to the entire agent system, with everything running on infrastructure you control.

That includes the control plane, agent loop, model routing, and execution environments. If you connect to external model providers, traffic flows directly from your infrastructure to those providers. There’s no intermediary, and if you deploy models on-prem, nothing leaves your network at all.

This makes fully air-gapped deployments possible. No required internet access. No dependency on an external control plane.

Of course, that level of control comes with tradeoffs. You take on more responsibility for managing infrastructure and model configuration. But for teams that need it, that’s not a downside. It’s the point.

Choosing the Right Definition

Which version of “self-hosted” is correct? Both are valid; they just solve for different constraints.

If you want fast adoption with limited infrastructure overhead, a partially self-hosted model like Cursor’s is an option. It’s designed for teams that don’t need strict control over where orchestration and inference happen, and prefer to get up and running quickly.

If you need strict control over data flow, infrastructure, and model behavior, then self-hosted needs to mean something more complete. The real question isn’t just where code runs, but where decisions are made and how much trust you’re placing in infrastructure outside your control.

There’s also a practical consideration for teams already using Coder. If you’re centralizing and governing development environments with Coder today, Coder Agents fits directly into your existing deployment. It runs on the same control plane, uses the same infrastructure, and doesn’t require introducing a new system or vendor into your environment. For those teams, it’s less about evaluating a new tool and more about extending a platform they already trust.

Self-hosted has always been a spectrum. What matters is not the label, but your company’s restrictions and concerns, because those determine how much infrastructure needs to live inside your perimeter.

See how Coder Agents runs on your infrastructure. Explore the docs to get started, or request a demo to see it in your environment.