Latest in AI
Self-Hosted Claude Managed Agents: What Moves, What Leaves and What Breaks
Hosting the agent service gives you control over session storage and model routing, but it is a migration with missing features, not a hostname change.
Anthropic introduced self-hosted Claude Managed Agents in private beta on November 12. You can operate the agent service, database and execution workers in your own infrastructure, while sending model requests to a chosen provider. This goes further than self-hosted sandboxes, but it does not run Claude's model locally.
The practical question is which boundary your organization needs to control. If the requirement is simply to execute tools near private code, hosting the entire service may add responsibilities without solving an additional problem.
Self-hosted sandboxes versus the whole service
The deployment overview separates the options clearly:
| Deployment | Who runs tools? | Who runs the agent service? | Where does inference run? |
|---|---|---|---|
| Default cloud sandboxes | Anthropic | Anthropic | Anthropic |
| Self-hosted sandboxes | You | Anthropic | Anthropic |
| Self-hosted Managed Agents | You | You | Anthropic or your selected provider |
For the third option, you operate cma-server, a database and workers. PostgreSQL 16 or later provides persistence; without a database, server data lives in memory and disappears on restart. A worker's shell inherits its execution environment's permissions, so the worker itself is not the isolation boundary.
Anthropic's launch announcement says access requires contacting your account team. Treat this as a private-beta architecture decision, not a generally available replacement you can assume every account can download today.
Self-hosting does not mean the conversation stays on-premises
The data and access documentation says each model call sends the conversation, including tool inputs and results, to the inference provider. Worker network access is separate from the server's connections and depends on your container or VM policy.
That distinction changes a security review. A repository can remain in your network while excerpts retrieved from it become model input. Document both where the files live and what selected content leaves during a session. Neither a local database nor a private worker answers the second question.
Keep three credentials separate: the application's server API key, the server's inference credential and the worker's environment key. Giving a tool-execution container the model credential because it is convenient defeats a useful separation in the architecture.
Before a pilot, draw one request from application to server, worker, internal service and inference provider. Mark the data and identity on each connection. This is a proposed review method, not a claim that this deployment has been tested here.
Check these migration failures before moving a workflow
The hosted-service differences are substantial. Existing agents and session history are not copied automatically. Recreate the resources the new deployment needs rather than expecting a changed SDK base URL to reveal the old account's objects.
| Symptom | Documented difference |
|---|---|
/v1/messages returns 404 | This server exposes Managed Agents, not the full Claude API |
| A cloud environment request returns 400 | Only self-hosted environments are supported |
| The session stops at its first tool call | Check that a worker is polling that environment |
| A webhook-triggered worker never starts | This service does not emit webhooks |
| A prebuilt document skill is rejected | Upload the skill sources as a custom skill |
Scheduled deployments and dreams are also unavailable. Dynamic workflows do not transfer unchanged: supported orchestration uses predefined agents rather than agent-created subagents. Review the full differences reference for the exact request forms your application uses.
API similarity is not feature parity. Build a checklist from your application's actual calls before deciding that the migration is small. A workflow that relies on a webhook to launch its worker has a different operational design once that webhook disappears.
Pilot one complete workflow, including its failure path
A useful first candidate is an internal build-triage agent that reads a failed job and prepares a proposed fix. Give it a disposable checkout and narrow network access, with no production deployment credential. The acceptance test should cover the entire path from job submission to human review, not merely a successful model response.
Include a server restart, a disconnected worker and an unavailable inference provider in the test plan. Verify that your application can distinguish a waiting tool call from completed work, recover stored session history and report a failure without silently routing sensitive content elsewhere. These are suggested checks, not observed results or guarantees.
Then assign an owner for database backups, updates, identity configuration and worker isolation. If those duties have no owner, the apparent control is mostly a diagram. Self-hosting is valuable when it satisfies a concrete storage or routing constraint and the team is willing to operate the system that enforces it.
I'm Paras. I work at the intersection of AI, engineering and distribution.
I help teams explain enterprise AI architecture and deployment trade-offs clearly to developers and decision-makers.