Archestra: an MCP gateway, agent runtime and guardrail layer in one TypeScript platform
Enterprise AI Platform with guardrails, MCP registry, gateway & orchestrator
At a glance
- What is it?
- Archestra bundles an LLM gateway, a private MCP registry, a Kubernetes-backed MCP orchestrator and deterministic tool-call guardrails behind a single URL. It is aimed at platform teams that need per-user tool credentials and audit trails, and the licence and release model are the parts to check before you commit.
- Who is it for?
- Adopt Archestra if you are a platform team standardising many teams onto one MCP and LLM entry point, and you want OAuth On-Behalf-Of so tools execute as the calling user rather than a shared service account. Do not adopt it if you need a small, single-purpose MCP proxy, or if you cannot accept an AGPL 3.0 core with an enterprise tier and a NOASSERTION licence field.
- Can I use it commercially?
- Check first. The repository uses a licence we do not classify automatically, so read its LICENSE file before any commercial use.
- Is it still maintained?
- Yes. The repository received new commits within the last day.
- What is it written in?
- Mainly TypeScript, according to GitHub's language statistics.
Answers come from the project's GitHub data, last synced on September 15, 2026, and from our analysis. They are not legal advice.
DEEP OPEN-SOURCE ANALYSIS
The problem Archestra targets: many agents, many credentials, no shared control point
The README frames the product around one instruction: point your users, your agents, or Claude, Codex and Cursor at one URL. That single sentence describes the problem more precisely than the feature list does. A team that adopts MCP servers ad hoc ends up with each developer's client holding its own provider keys, each MCP server running under one shared service account, and no per-team view of what was called or what it cost. Archestra's answer is to put a gateway in the path so the client stops being the place where credentials and policy live. The intended audience is visible in the feature set rather than stated outright: SSO through OIDC, SAML, Okta and Entra, RBAC with role mapping and team sync, per-environment egress policies, per-team cost tracking, and a migration kit aimed at organisations already running what the README calls dangerous single-tenant agents. That is a platform-engineering audience, not an individual developer. The chat front-ends (Slack, MS Teams, email) and the mini app builder point at a second audience inside the same install: non-technical staff who need an internal assistant without touching a config file.
One URL in front of four separate gateways
The architecture the README describes is a set of gateways sharing one identity and observability layer. The LLM gateway fronts Anthropic, OpenAI, Azure, Bedrock, DeepSeek and others, and adds cost limits, virtual API keys and dynamic model routing on top. The MCP gateway is the more distinctive piece: it handles OAuth with On-Behalf-Of so a tool call runs as the authenticated user instead of a shared service account. That distinction matters operationally. If an MCP server reads from an internal system, On-Behalf-Of means the server sees the calling user's permissions, so an agent cannot exceed what its owner can already reach. The A2A gateway handles agent-to-agent triggers over webhook. The private MCP registry is where teams publish their own tools, and the orchestrator, backed by a Kubernetes operator, handles deployment and what the README calls self-serve promotion between environments. Data flows through the proxy layer, which is also where the guardrails sit: tool-call guardrails, Dual-LLM verification and Lethal Trifecta protections are described as deterministic rather than model-judged, and OpenTelemetry traces plus Prometheus metrics are emitted from the same path. The design choice worth noting is that guardrails live at the gateway rather than in each agent. That centralises policy, and it also means the gateway becomes a hard dependency for every agent call.
Running it: the quickstart command and what it mounts
The README gives a single Docker invocation. Pull archestra/platform:latest, then run it with ports 9000 and 3000 bound to localhost, ARCHESTRA_QUICKSTART=true, and three mounts: /var/run/docker.sock, a named volume at /var/lib/postgresql/data, and a named volume at /app/data. The UI is then at http://localhost:3000. Two details in that command deserve attention before you copy it. Mounting the Docker socket gives the container control over the host daemon, which the README does not discuss; treat it as a local evaluation convenience and not a production posture. The ARCHESTRA_QUICKSTART flag is named as such, which implies a different configuration path for real deployments. The README states that full Docker, Helm and Kubernetes instructions live in the quickstart and deployment docs, and that Helm is the recommended production route. It also points to a Terraform provider repository. Environment variables are documented in the deployment page rather than the README, so the README alone is not enough to stand the platform up in a cluster. For anything beyond a laptop, the Helm chart is the documented starting point.
The release model is a rolling beta with selective backports
Archestra maintains two tracks. Stable releases, exemplified by 1.3.51 in the README, are described as qualified and tested, with one active stable line at a time receiving security patches and bug fixes. Beta releases, such as 1.4.0-beta.1, are built from main and exist so users can test upcoming features. The README states the flow plainly: new features and fixes land on main first and ship in rolling beta releases, then fixes are selectively backported to the supported stable branch. The recent release list reflects that cadence, with platform-v1.3.55 and platform-v1.3.54 landing on the same day as platform-v1.4.0-beta.3. The practical consequence is that the feature you want may exist only on the beta track for some time, and the backport is described as selective, not exhaustive. The README's own guidance is to pin an exact version tag or Helm chart version in production rather than tracking latest, even though the latest Docker tag points at the most recent stable release. That is a maintenance cost you should price in: someone has to watch the release guide and decide when a backported fix reaches the line you run.
Where Archestra is the wrong tool
The first limitation is the licence. The repository's licence field reads NOASSERTION, while the README badge says AGPL 3.0 / Enterprise and links to LICENSE.md. Those two signals do not agree, and the pricing model page is described as Open Core with a free tier for teams under 30 users and enterprise licensing above that. If your organisation cannot accept AGPL 3.0 terms for the core, or needs the enterprise tier, the decision is a procurement decision before it is a technical one, and the README does not resolve it. The second limitation is scope. Archestra is a platform, not a component. If you need a single MCP proxy to sit in front of two servers, the orchestrator, the Kubernetes operator, the registry, the RAG knowledge base and the mini app builder are weight you would carry without using. The third is the deployment shape. The MCP orchestrator is tied to a Kubernetes operator, and the quickstart relies on the host Docker socket, so the two documented paths assume container orchestration on one end and a privileged local daemon on the other. Teams without Kubernetes, or with a policy against socket mounts, are outside both. Fourth, the README's production claims (funding, named Fortune-50 deployments, a 31 ms p95 figure) are marketing statements that link to a benchmarks page; they are not reproducible from the README and should not be treated as evidence of fit for your workload.
How it differs from a plain MCP proxy or a hosted gateway
The closest comparison in kind is a minimal MCP proxy: a small process that forwards tool calls from a client to one or more MCP servers, with static credentials and no notion of who the caller is. Archestra's MCP gateway differs on the identity axis. OAuth with On-Behalf-Of means the gateway carries the user's identity through to the tool, and the surrounding RBAC, team sync and per-environment egress policies decide what that identity may reach. A minimal proxy cannot express that because it has no user model. The second comparison is a hosted LLM gateway that meters spend and routes models. Archestra includes that function (virtual API keys, cost limits, dynamic routing) but pairs it with the MCP side, so one token covers both Claude Code, Codex and Cursor access and tool invocation. The trade is control for operational surface: you run the Postgres instance, the orchestrator and the operator yourself, and the guardrail layer sits in the request path for every call. The README's migration kit, aimed at teams replacing single-tenant agents, is the clearest statement of what Archestra is meant to displace.
Maintenance, upgrade cost and licence implications
Two ongoing costs are visible in the material. The first is upgrade tracking. With one supported stable line receiving selective backports and features landing on main first, staying current means following the release guide and testing against beta tags if you depend on new capabilities. Pinning an exact tag, as the README advises, trades that tracking work for predictable upgrades. The second is the operational surface: a Postgres data volume, an application data volume, a Kubernetes operator for the orchestrator, and a Terraform provider if you manage configuration as code. Each of those is something your team owns. On licensing, the README badge points to AGPL 3.0 with an enterprise option and a free tier for teams under 30 users, while the repository metadata reports NOASSERTION. I cannot tell you from this material which terms apply to which components, and nothing here is legal advice. Read LICENSE.md and the pricing model page yourself, and if the distinction between the free tier and the enterprise tier affects your deployment, get it confirmed in writing before you build on it.
Editorial conclusion
Adopt Archestra if you are a platform team standardising many teams onto one MCP and LLM entry point, and you want OAuth On-Behalf-Of so tools execute as the calling user rather than a shared service account. Do not adopt it if you need a small, single-purpose MCP proxy, or if you cannot accept an AGPL 3.0 core with an enterprise tier and a NOASSERTION licence field. Before you commit, verify the licence file at LICENSE.md against the AGPL/Enterprise badge, confirm whether the orchestrator's Kubernetes operator is required for your deployment shape, and pin an exact platform tag instead of tracking latest.
Community notes