Archestra: an open source AI platform with an MCP gateway and LLM proxy behind one URL

The problem Archestra targets: too many AI clients, no single control point

A team that adopts AI tooling usually ends up with the same mess. Claude Code has one API key, Cursor has another, an internal chatbot has a third, and each MCP server is wired into each client separately. Nobody can say which user spent what, which tool call ran as which identity, or what happens when someone pastes a customer record into a prompt. Archestra's answer is to make the platform the thing every client points at. The README describes the pitch as "Point your users, or your agents, or Claude / Codex / Cursor, at one URL." That single URL then fronts an LLM gateway, an MCP gateway, a private MCP registry, an agent runtime and a chat front-end for non-technical staff. The intended audience is a platform or infrastructure team inside a company, not an individual developer, because the features that matter here (SSO, RBAC with role mapping, per-team cost tracking, per-environment egress policies) only pay off at organisational scale. The README also names a second audience explicitly: teams already running single-tenant agents such as Claude Cowork, OpenClaw or Hermes, for whom a migration-kit directory exists at the repository root.

How the pieces fit: gateway, registry, orchestrator, runtime

The architecture is a set of gateways in front of resources you already have. The LLM gateway sits between clients and providers (Anthropic, OpenAI, Azure, Bedrock, DeepSeek and others per the docs), and adds virtual API keys, cost limits and dynamic model routing. The MCP gateway sits between clients and MCP servers, and the README states it supports OAuth plus On-Behalf-Of so tools run as the user rather than a shared service account. That distinction is the interesting design choice: most MCP deployments hand every tool call the same credentials, which makes per-user audit meaningless. The private registry is where teams publish their own MCP servers. The orchestrator deploys MCP servers onto Kubernetes through a Kubernetes operator, with self-serve promotion between environments. The agent runtime handles scheduled, email and webhook triggers, sub-agent delegation and reusable skills, and the README says code execution is sandboxed with a Kubernetes-native filesystem. Observability is part of the same flow: OpenTelemetry traces, Prometheus metrics and logs, with cost tracking broken down per team. Everything listed is TypeScript, and the top-level layout separates platform/, docs/, mcp-catalog/, migration-kit/ and ai-labs/, which suggests the catalog of MCP servers is maintained as data rather than code.

Installing Archestra with Docker and reaching the first screen

The README's quickstart is a single docker run against the archestra/platform image. It publishes two ports on localhost only, sets ARCHESTRA_QUICKSTART=true, mounts the Docker socket, and creates two named volumes for Postgres data and application data. Note the 127.0.0.1 prefix: the ports are not exposed on all interfaces by default.

docker pull archestra/platform:latest

docker run \
  -p 127.0.0.1:9000:9000 -p 127.0.0.1:3000:3000 \
  -e ARCHESTRA_QUICKSTART=true \
  -v /var/run/docker.sock:/var/run/docker.sock \
  -v archestra-postgres-data:/var/lib/postgresql/data \
  -v archestra-app-data:/app/data \
  archestra/platform:latest

After the container starts, the README says to open http://localhost:3000. That is the chat and admin interface; port 9000 is also published, and the README does not label it in the quickstart block. For anything beyond a local trial, the README points to the quickstart docs for full Docker, Helm and Kubernetes instructions, and the deployment docs describe a Helm chart the README calls recommended for production, plus a separate Terraform provider repository. The release-channels section is worth reading before you pick a tag: the README states that latest points at the most recent stable release, that new work lands on main and ships in rolling betas first, and that production deployments should pin an exact version tag or Helm chart version rather than tracking latest. The most recent releases listed are platform-v1.3.55 and platform-v1.4.0-beta.3, both dated 2026-09-09.

Guardrails, identity and the limits the README does not cover

The security story is the part Archestra leans on hardest. The README advertises deterministic guardrails for tool calls, Dual-LLM verification and Lethal Trifecta protections, alongside SSO through OIDC, SAML, Okta and Entra, RBAC with role mapping and team sync, and secrets management. Deterministic is doing real work in that sentence: a rule that inspects a tool call before execution behaves differently from a second model asked to judge the first, and Archestra ships both. The Dual-LLM agent is documented as a built-in subagent, so it is a component you configure rather than a policy you write. Where the documentation is thin is operational failure handling. The README does not document rollback, does not describe what happens to in-flight agent runs when the orchestrator promotes an environment, and does not state backup or restore procedures for the Postgres volume beyond the fact that it exists. The mounted Docker socket is another constraint worth naming plainly: the quickstart gives the container control over the host Docker daemon, which is convenient for spawning MCP servers locally and is not a posture most security teams accept in production. Kubernetes deployments avoid that, but then you are running the operator, which is a larger commitment than a single container.

When Archestra is the wrong tool

If your requirement is a stateless proxy that forwards OpenAI-shaped requests to one provider and logs tokens, Archestra is far more than you asked for. You would be operating Postgres, a web application, a registry and possibly a Kubernetes operator to replace a few lines of reverse-proxy configuration. The same applies if your team is small enough that per-team cost tracking and RBAC role mapping have nothing to map: the README's own pricing model says the open core is free for teams under 30 users, which is a fair hint about the scale where the rest of the platform starts to earn its keep. There is also a licence question you have to resolve before adopting, not after. The repository root contains both LICENSE_AGPL and LICENSE_ENTERPRISE alongside LICENSE.md, and the README badge reads "AGPL 3.0 / Enterprise". The repository's licence field is reported as NOASSERTION, meaning GitHub could not classify it automatically. Which file governs your deployment depends on the component and your usage, and the README does not settle it in the text available here. Read LICENSE.md and both licence files before you build anything on top.

How Archestra differs from a plain MCP host or a standalone proxy

The obvious comparison is a desktop MCP host such as Claude Desktop or Cursor's built-in MCP support. Those run tools on the developer's machine under the developer's own credentials, with no central registry and no per-user identity. Archestra inverts that: MCP servers are registered once in a private registry, deployed by the orchestrator, and reached through a gateway that the README says uses OAuth with On-Behalf-Of so the tool acts as the requesting user. The cost of that inversion is that every tool now depends on the platform being up. A second comparison is a standalone LLM proxy or gateway. Those solve routing and spend; they do not run agents, do not hold a tool registry, and do not execute code in a sandbox. Archestra's wager is that these concerns belong in one system because the guardrail decisions need to see the tool call, the identity and the model response together. That is a coherent argument, but it also means you cannot adopt the guardrails without adopting the surrounding platform. The README's migration kit for single-tenant agents like Claude Cowork, OpenClaw and Hermes is the clearest statement of where the project thinks it wins: replacing per-user agent installs with one governed deployment.

Maintenance, release cadence and upgrade cost

The repository is not archived, and the last push was on 2026-09-10, so this is a project under current development. The release list shows platform-v1.3.54 and platform-v1.3.55 published on 2026-09-09 within hours of each other, plus a v1.4.0 beta line, which tells you the cadence is fast and that stable patches arrive frequently. The README describes the maintenance model directly: one active stable release line at a time, receiving security patches and bug fixes, with fixes backported selectively from main. Two consequences follow. First, you should pin a version tag or Helm chart version, as the README instructs, because latest moves. Second, you are tracking a single supported stable line, so staying on an older minor means accepting that backports are selective rather than guaranteed. Beta releases are built from main and are the only place new capabilities appear before they land in stable, which makes them useful for evaluation and unsuitable for production. On licensing, the split between AGPL and Enterprise files means the upgrade path may also be a licensing conversation depending on what you deploy and how you use it; that is a question for your legal team, and the README text available here does not answer it.

Editorial conclusion

Adopt Archestra if you already run several AI clients and MCP servers and want a single URL, one token and one audit trail for all of them, and if you can run Postgres and the Docker socket alongside it. Do not adopt it if you only need a thin proxy in front of one provider, or if you cannot pin a version tag, since the README warns against tracking latest in production. Before rollout, verify three things yourself: which licence file actually applies to the components you deploy, whether the MCP orchestrator's Kubernetes operator is required for your topology, and what the quickstart container does with the mounted Docker socket.

Frequently asked questions

Official sources

1. archestra-ai/archestra on GitHub
2. Issues
3. Project website
4. README
5. Releases