Markdown

Archestra: LLM proxy, MCP gateway, and OpenAPPA host¶

Scope: the Archestra enterprise agent platform (repository archestra-ai/archestra) as an operations target: what components it bundles, how the OpenAPPA guardrail integration is enabled and keyed to sessions, and which of its claims are self-reported. The policy engine itself is on OpenAPPA; MCP and tool-calling background is in tools and function calling.

flowchart LR
  C["Clients: coding CLIs, chat, n8n, services"] -->|"X-Appa-Session-ID + credential"| P["Archestra LLM proxy"]
  P --> G["Guardrails: existing checks, then OpenAPPA"]
  G --> M["LLM providers"]
  G --> W["MCP gateway and private registry"]
  E["OpenAPPA policy in PostgreSQL, optional GitHub sync"] --> G

What it is¶

Per the README (read at commit 7b489cb), an all-in-one open-source enterprise AI platform: chat for non-technical users, an LLM gateway for multiple providers with cost limits and virtual API keys, an MCP gateway with OAuth and on-behalf-of identity, an A2A gateway, a private MCP registry, a Kubernetes MCP orchestrator, an agent runtime with triggers, a RAG knowledge base, SSO and RBAC, and OpenTelemetry and Prometheus output.

Licensing is a router: dual AGPL-3.0 and an Archestra enterprise licence, decided per file by LICENSE.md. The README says it is free for teams under 30 users; verify the current terms on the pricing page before relying on that. Its backend is TypeScript (Fastify), with a native Rust addon for OpenAPPA (openappa-rs).

Why use it¶

One URL for many agents: any client that talks to a model through the proxy falls under one policy without per-agent integration, per the OpenAPPA site. The README lists Claude Code, Codex, Cursor and others as proxy clients.
Centralises cost limits, credentials, and tool access that otherwise sit in each developer's environment.

When to use it (and when not)¶

Use it for an organisation standardising many agents behind one gateway with audit and policy. Do not treat it as a drop-in for a single agent: the proxy only sees model traffic and MCP calls that flow through it, so local tools an agent runs itself are outside its view unless the client routes them. The OpenAPPA support is beta (release candidate 1.4 line at the time of reading); the README states release candidates are built from main and that latest usually points to one, so production should pin a stable tag or chart version.

Architecture¶

OpenAPPA evaluates tool results and tool calls at the proxy. Findings from docs/openappa-architecture.md in the repo:

Enablement needs two things: ARCHESTRA_BETA=true on the server (registers the plugin, shows the editor) and the "Enable Guardrails v2" switch on /openappa, which defaults to off. Until both are on, APPA enforces nothing. The deployment-level flag requires a backend restart; saving a policy does not.
When the flag is on, the older trusted-data guardrail stands down (no untrusted marking, no dual-LLM sanitization). An existing invocation policy that only restricts untrusted context then never fires, while one that blocks outright still does. A deployment with the flag on but the switch off therefore has neither guardrail judging traffic.
Session identity: the proxy detects it from client headers or an explicit X-Appa-Session-ID; X-Appa-Parent-ID links a subagent to its parent. External sessions are scoped to the authenticated credential (user:<id>, app:<id>, virtual-key:<id>) so another user's session cannot be reached by guessing an ID. Requests with no header share one fallback session per credential and agent, which merges unrelated work into one label.
Remedies are exposed as two MCP tools, archestra__get_remedy_plans and archestra__execute_remedy_plan.
Policy is stored as organization revisions in PostgreSQL; new conversations use the latest, existing ones keep the policy they started with. A tool-name rule matches exactly or as *; partial globs such as grain__* match nothing.
GitHub sync pulls a file (limit 1 MiB) every 15 minutes, hourly, or daily; a pull that drops a battery or changes a credential grant is held until an administrator accepts it. Failed pulls keep the active policy.
Batteries are provider policy packages (policy file plus helper scripts and an APPA_PROVIDER_* credential). Uploaded packages may use local command externals rewritten to a helper bridge; url externals are refused.

How to use it¶

Quickstart from the README (pull archestra/platform, run with Docker, open port 3000) uses :latest, which the README itself says may be a release candidate; pin a tag in anything real. The repository's own words for production are a Helm chart with an exact version. To try OpenAPPA: set ARCHESTRA_BETA=true on 1.4 or later, restart, create a starter policy in the /openappa setup chat (it covers Archestra's own tools and leaves the rest open), then approve to turn enforcement on.

How to develop with it¶

Point a client at the proxy and send X-Appa-Session-ID (a stable UUID per conversation) on every request. Keep the policy in a private repository created from archestra-ai/openappa-config, add trajectory traces under traces/, and require the validation check in branch protection; the configuration agent then opens pull requests for changes and a change applies after merge and a successful sync.

How to maintain it¶

Policy revisions are reviewed like code; the editor and Batteries panel become read-only while GitHub sync is connected. Existing file-based OpenAPPA deployments must copy their policy into the editor. Template fixes apply only to repositories created afterwards; existing repositories need their own pull request. Follow the stable branch for patches and treat release candidates as previews.

How to run it in production¶

Pin image digests or chart version; the repo's release checklist installs the saved chart with ARCHESTRA_BETA=false to confirm digests.
Confirm both enforcement switches and watch the sidebar warning; test a known-bad call end to end (read a private source, attempt an external send) and confirm a block with remedies.
Use credentialed sessions for external clients; uncredentialed loopback is the documented trust boundary for internal requests.

Claims not verified¶

"31 ms at p95", "$13.5M total funding", and "Three Fortune-50 deployments" are README statements, not reproduced here.
The OpenAPPA benchmark numbers belong to the engine's authors; see the audit on the OpenAPPA page.
This review read the repository and docs; it did not deploy Archestra, so the enablement flow is documented behaviour, not observed behaviour.
The OpenAPPA site says Archestra sponsors OpenAPPA development; both pages' sources are therefore from related parties.

Failure modes¶

Flag on, switch off: neither old nor new guardrail is enforcing.
Missing session header: unrelated conversations share one label and start being blocked, or one agent's reads restrict another's sends.
Running latest in production and receiving an unreviewed release candidate.
Policy drift between a synced repository and the editor copy; held pulls need an administrator to accept.
Tools reached outside the proxy are not evaluated.

References¶

Repository: https://github.com/archestra-ai/archestra (licence router in LICENSE.md; docs/openappa-architecture.md; platform/.env.example)
Guardrails doc: https://archestra.ai/docs/platform-ai-tool-guardrails
Deployment doc: https://archestra.ai/docs/platform-deployment
Policy template: https://github.com/archestra-ai/openappa-config
OpenAPPA on Archestra: https://www.openappa.com/archestra