Self-Hosted Claude Managed Agents: What You Run and What You Lose

Last updated: November 12, 2026

Anthropic launched self-hosted Claude Managed Agents on November 12, 2026: you run the whole Managed Agents service, not only the sandboxes, on your own cloud account or data center, and you store agents, sessions and session history there. Model calls go to the Claude API by default, or to Amazon Bedrock, Claude Models on Google Cloud, Microsoft Foundry or your own model gateway. Access is by request: "To request access to self-hosted Claude Managed Agents, contact your Anthropic account team."

This post is built from the November 12 release note and the self-hosted docs, read on launch day. The software itself is gated behind that request, so I have not run it. Everything below is what the docs say, with the commands and settings copied from them.

Three ways to run Managed Agents now#

The docs frame the choice by who hosts each part:

The docs give two reasons to pick the third row: "Storage on your infrastructure: You must store agents, sessions, and session history yourself", or model calls that "must go to Amazon Bedrock, Claude Models on Google Cloud (Google managed), Microsoft Foundry, or your own model gateway." If you only need tools to run inside your network, the docs point you back to self-hosted sandboxes, where Anthropic still runs the service.

The trade is explicit: "you run and secure a server, its database, and your sandboxes, and you install each release yourself."

What runs where#

%% title: Components of a self-hosted Claude Managed Agents deployment
flowchart LR
  subgraph net [Your network]
    apps[Your applications, SDK or ant CLI] -->|Managed Agents API| server[cma-server]
    workers[Workers in sandboxes] -->|poll for work| server
    server --> db[(PostgreSQL 16+)]
  end
  server -->|model calls| provider[Claude API, Bedrock, Vertex, Foundry or your gateway]

Per the docs, one or more servers, their database and your sandboxes make one deployment:

• cma-server serves the API, runs the agent loop and stores agents, sessions and history. It "never runs an agent's shell or file tools."
• The database is PostgreSQL 16 or later. "Without a database, the server keeps its data in memory, and a restart erases it."
• Workers take work from the server and run shell and file tools in your sandboxes. A worker is an ant beta:worker command or an SDK worker.
• A console on your server, where people sign in through your identity provider, and an admin CLI, cma-server-admin, that creates environments and their keys.

The API is the same as the hosted service, so the SDK and the ant CLI work against your server. There are three credentials: a server API key your apps send (it "plays the role that a Claude API key plays with the hosted service"), the server's inference credential for your model provider, and an environment key per work queue for workers.

Getting started, per the quickstart#

The quickstart runs everything on one machine with Docker Compose and is explicitly "for development, not for production": it serves plain HTTP on port 8400. For production the docs recommend the release's two Helm charts. After extracting the archive, the quickstart creates a .env with a generated database password, server API key and encryption key plus your Claude API key, then:

docker compose up --build -d
docker compose logs -f cma-server
curl -s http://127.0.0.1:8400/cma-server/readyz

A ready server answers with "status":"ready". To point the CLI at your server, the quickstart sets the base URL and uses the server API key, not your Claude API key:

export ANTHROPIC_BASE_URL=http://127.0.0.1:8400
export ANTHROPIC_API_KEY=$(grep '^CMA_SERVER__API_KEY=' .env | cut -d= -f2)

One trap the docs call out: keep docker compose commands in a different terminal. "If you run docker compose up in this terminal, Compose passes these variables to the server, and the server calls itself instead of the Claude API." The quickstart also notes that each release archive ships an operator-guide.md you can hand to Claude so it can help configure the server.

Choosing the inference provider#

The inference.provider setting takes anthropic (default), bedrock, vertex, foundry or gateway. Agents keep naming models by Claude API IDs such as claude-opus-5-5, and "the server translates the ID, so an agent definition works unchanged under any provider that serves that model." The Bedrock sample from the inference provider page:

inference:
  provider: bedrock
  region: us-east-1
  #model_id_prefix: global.anthropic.
  #model_id_overrides:
  #  claude-opus-5-5: us.anthropic.claude-opus-5-5

The server signs with the AWS SDK's default credential chain, defaults to the us.anthropic. cross-region prefix, and needs bedrock:InvokeModel, bedrock:InvokeModelWithResponseStream, bedrock:ListFoundationModels and bedrock:ListInferenceProfiles. Our Claude on Google Cloud setup guide covers the Google side of the provider choice.

What you give up#

The differences page is the part to read before committing. "Nothing is copied from the hosted service, session history included." Not available on your server:

• Cloud environments. Only self_hosted environments exist; a request for a cloud one returns a 400.
• The rest of the Claude API. The server does not serve /v1/messages or /v1/models (404), so send those to the Claude API or your provider from a separate client.
• Files. file session resources and /v1/files do not exist. memory_store resources work.
• mcp_oauth vault credentials, because the server "has no OAuth flow to refresh a token". Use static_bearer and rotate it yourself.
• Prebuilt docx, pdf, pptx and xlsx skills. Upload them as custom skills from the skills repository instead.
• Scheduled deployments, dreams and webhooks. Start sessions from your own scheduler and follow them through the event stream.

Things that behave differently include multiagent orchestration (an agent "can delegate only to subagents that you list"; dynamic workflows and the advisor are not available), MCP servers (the server "connects only to the MCP hosts that you list" under mcp.allowed_hostnames, empty by default), MCP tool results (cut at mcp.max_result_bytes, 100 KiB by default), and images or documents sent by URL, which the server accepts "but the model never sees it, and there is no error." That last one is the kind of silent gap to test for before migrating anything.

What you gain that the hosted service lacks: a choice of inference provider, single sign-on through your OpenID Connect provider, your own secret manager for vault credentials, and agent identity tokens that an MCP server or gateway can verify.

The security model is now yours#

The docs are blunt about the sandbox: "The agent's bash tool is a real shell with the worker process's permissions and network access. The worker doesn't isolate that shell." The Compose stack and the cma-sandboxes Helm chart start each session's worker in its own container or pod; if you start a worker yourself, run it "in a disposable container or VM that holds nothing you need to protect." Everything the self-hosted sandboxes security model assigns to Anthropic, including securing the server and detecting unusual usage, becomes your job, and each trust level needs its own deployment.

Note also what still leaves your network: for each model call, the server sends the conversation so far, including tool inputs and results, to your inference provider, and a call to the Claude API also carries the session, agent and environment IDs. If the point of self-hosting is that no conversation data reaches Anthropic, pair it with a non-Anthropic provider, and check which tools that provider supports.

Who should ask for access#

• Regulated teams that need agents and history inside their own boundary: this is the product for you. Budget for running PostgreSQL, the Helm charts and release upgrades.
• Teams that only want tools to run near their data: stay on self-hosted sandboxes and let Anthropic run the service. Our honest review of Claude Managed Agents covers what the hosted version does well.
• Teams comparing build versus buy: the missing features list narrows the gap with rolling your own. Our Managed Agents vs LangGraph vs DIY comparison is the framework for that call.

FAQ#

What is self-hosted Claude Managed Agents?#

Anthropic launched it on November 12, 2026. You run the whole Managed Agents service on your own infrastructure: a cma-server that serves the API and runs the agent loop, a PostgreSQL 16+ database for agents, sessions and history, and workers that run tools in your sandboxes. The model still runs at Anthropic or a provider you choose.

How do I get self-hosted Claude Managed Agents?#

Contact your Anthropic account team. The docs say access to the release download goes through them. Each release archive includes a Docker Compose stack for development and Helm charts for production.

Can self-hosted Managed Agents use Bedrock or Vertex instead of the Claude API?#

Yes. The inference.provider setting takes anthropic (the default), bedrock, vertex (Claude Models on Google Cloud, Google managed), foundry, or gateway for a model gateway you run. Agents keep naming models by Claude API IDs and the server translates them.

What does self-hosted Managed Agents not support?#

Per the differences page: no cloud environments, no Messages or Models API on the server, no Files API or file session resources, no mcp_oauth vault credentials, no prebuilt docx, pdf, pptx and xlsx skills, no scheduled deployments or dreams, and no webhooks.

Is self-hosted Managed Agents the same as self-hosted sandboxes?#

No. With self-hosted sandboxes you host only the containers where tools run, and Anthropic runs the service. Self-hosted Managed Agents moves the service and its storage to you too. If you only need tools to run on your infrastructure, the docs recommend self-hosted sandboxes.

Sources#

• Claude Platform release notes, November 12, 2026
• Self-hosted Claude Managed Agents
• Get started with self-hosted Claude Managed Agents
• Differences from the hosted service
• Inference provider
• Self-hosted sandboxes

Continue Reading#

• Claude Managed Agents: An Honest Review - what the hosted service gives you
• Managed Agents vs LangGraph vs DIY - the build-versus-buy decision
• Claude Managed Agents as a Backend Job Runtime - patterns that carry over to a self-hosted server