- In short
- Self-hosting an agent gives full control over data residency, networking, and custom infrastructure at the cost of operating the runtime yourself. A managed, Anthropic-hosted deployment reduces operational burden but constrains where and how the agent runs. The choice is driven by compliance, latency, and operational-capacity requirements, not by the model capability, which is the same either way.
Two ways to deploy the same agent
Once you have defined an agent with the Claude Agent SDK, you have to decide where it runs. The Claude Certified Developer - Foundations (CCDV-F) exam frames this as a choice between two deployment models: running the agent in your own infrastructure, or using a managed, Anthropic-hosted deployment. Crucially, this is an operational decision, not a capability one. The same agent, with the same model behind it, can run either way.
Self-hosting means you operate the runtime. The agent executes on infrastructure you control, which gives you full control over data residency, networking, and any custom infrastructure the agent needs. The price of that control is that you own the operations: provisioning, scaling, monitoring, and maintenance are yours. A managed, Anthropic-hosted deployment inverts the trade. It reduces the operational burden because the hosting is handled for you, but in exchange it constrains where and how the agent runs, because you are operating inside the managed environment's boundaries rather than your own.
- Self-hosted vs Anthropic-hosted deployment
- Self-hosting runs the agent on infrastructure you control, giving full control over data residency, networking, and custom setup at the cost of operating the runtime. A managed, Anthropic-hosted deployment reduces operational burden but constrains where and how the agent runs. The model capability is identical either way.
What self-hosting buys and costs
The reason a team chooses to self-host is control. When you run the agent yourself, you decide where the data lives, how the network is configured, and what custom infrastructure sits around the agent. For an organisation with strict data-residency rules, a requirement to keep traffic inside a private network, or bespoke infrastructure the agent must integrate with, that control is the whole point. Self-hosting lets you satisfy those constraints directly because nothing about the runtime is outside your reach.
The cost is equally direct: you operate the runtime. That means the reliability, scaling, patching, and observability of the deployment are your responsibility. Self-hosting only makes sense when the control is worth that operational load and you have the capacity to carry it. If you do not, you are taking on the burden without a requirement that justifies it.
What drives the decision
The exam is explicit that the choice is driven by compliance, latency, and operational-capacity requirements, not by model capability. Read a scenario for those three signals. Compliance and data-residency rules can force self-hosting when data is not allowed to leave a particular environment. Latency requirements can favour running the agent close to the systems it integrates with. Operational capacity, whether the team can actually run and maintain a self-hosted runtime, is what makes managed hosting attractive when that capacity is thin.
What must never drive the decision is a belief that one deployment model makes the agent smarter or more capable than the other. It does not. The model behind the agent is the same regardless of where the agent executes, so capability is a constant, and the whole decision lives in the operational and compliance columns.
What the CCDV-F exam trips candidates on
The exam tests two traps at this knowledge point, and both are about attaching the decision to the wrong thing.
The first is assuming self-hosting changes the model's capabilities rather than only where the agent executes. A distractor will suggest self-hosting to get a better or more powerful model, or claim managed hosting limits what the agent can do. The credited answer holds the line that capability is identical across deployment models; the only thing that changes is where and how the agent runs.
The second is ignoring data-residency and compliance requirements when selecting a deployment model. A scenario will describe an organisation with clear rules about where data may live, then offer a managed deployment that would violate them because it is operationally easier. The correct reading is that compliance and residency requirements are exactly the kind of constraint that can force self-hosting, and choosing the lower-ops option while ignoring them is the mistake the exam is testing.
Worked example
A healthcare company must build an agent that reads patient records. Regulation requires that patient data never leave the company's own private network. An engineer proposes the Anthropic-hosted, managed deployment because it is far less work to operate.
Start with the constraint that actually governs the choice. The regulation is a hard data-residency and compliance requirement: patient data cannot leave the private network. That is precisely the kind of constraint that decides the deployment model, and it points toward self-hosting, where the company controls data residency and networking directly.
The engineer's proposal optimises the wrong variable. A managed deployment reduces operational burden, which is a real benefit, but it constrains where and how the agent runs, and here that constraint collides with the residency rule. Choosing it because it is easier to operate ignores the compliance requirement, which is exactly the second exam trap.
It is also worth naming what does not enter the decision. Neither option changes the model's capability; the agent would read records equally well either way. So the analysis is purely about control versus operational burden under a binding compliance rule. Because the rule requires the data to stay inside the company's network, self-hosting is the correct deployment model, and the company takes on the operational load as the cost of meeting the requirement.
Common misreadings to avoid
Misconception
Self-hosting an agent gives you a more capable or more powerful model than the managed option.
What's actually true
Misconception
You should always pick the deployment model that is easiest to operate.
What's actually true
How this shows up on the exam
Domain 1 questions on this knowledge point present an organisation with constraints and ask which deployment model fits. The reliable method is to read for compliance, latency, and operational-capacity signals and choose on those, while refusing any answer that ties the decision to model capability. A binding data-residency or compliance rule tends to force self-hosting; thin operational capacity with no such rule tends to favour managed, Anthropic-hosted hosting.
This knowledge point closes out the construction task statement alongside the Agent SDK fundamentals and custom loops and deterministic hooks. Together they cover how you build an agent and where you run it, which only becomes relevant once the workflow versus agent decision has already told you an agent is warranted. Keeping deployment separate from capability in your head is what makes these scenarios quick to answer.
A bank must deploy a Claude agent under a rule that all customer data remain within its own controlled infrastructure. Which deployment model fits, and on what basis?
People also ask
What is the difference between self-hosted and Anthropic-hosted agents?
Does self-hosting change what the model can do?
When should I self-host an agent?
Watch and learn
Official Anthropic Academy lessons first, then hand-picked walkthroughs. Videos load only when you press play.
No videos curated for this concept yet
We are still curating the best official and community videos for this topic.
References & primary sources
Master this concept with Archie
Practice it inside an adaptive study session. Archie, your Socratic AI tutor, tracks your mastery with Bayesian Knowledge Tracing and schedules the perfect next review.