Archestra Enterprise AI Platform: Who It’s For and a First Docker Launch

Who it’s for

• The official positioning is “an all-in-one open-source enterprise AI platform”: it takes on the MCP registry, gateway, and orchestrator roles at once, not the role of a single-purpose MCP server. The shape that fits: a team self-hosts one platform on its own machines and points users, agents, and Claude / Codex / Cursor clients at the same URL; the platform carries all tool calls, and the clients know exactly one entry point.
• Its MCP gateway uses OAuth + On-Behalf-Of, so tools run as the user themselves rather than under a shared service account; teams that care about attributing every call to a person are clear beneficiaries.
• How to judge: if your problem is only “one client is missing one tool”, finding a single MCP server is enough. The platform layer only comes into play when several services, several clients, and several identities need unified management.
• The right environment: teams that can run Docker on a local machine or an intranet and are willing to weigh the cost of the socket mount; the quickstart binds its ports to the loopback address, so it suits a single-machine trial first, then long-term running once the side effects are accepted.
• Prerequisite: Docker on the machine. The evidence states no minimum resource configuration and no supported operating systems, and mentions no way to run outside Docker — all of that is unconfirmed.

A first try in 3 minutes

• Before acting, confirm you accept the two side effects the official notes state openly: first, the command mounts the host’s /var/run/docker.sock, so the container can control the host’s Docker daemon; second, the image’s latest tag points to the newest release and usually runs a release candidate. Both points are written in the official notes — count them in during evaluation, not as details to settle after deployment.
• The first launch is not a read-only operation either: the named volumes archestra-postgres-data and archestra-app-data write database and app data into local Docker volumes; the official documentation gives no cleanup or undo command, and the evidence does not say whether leftover data affects a fresh start between repeated experiments — do not try this casually on a host that holds important data.
• Once you accept that, run the official quickstart command:

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

• The success signal you can confirm goes this far: the container keeps running, and the two ports bind only to the loopback address 127.0.0.1; the configuration the quickstart explicitly requires is ARCHESTRA_QUICKSTART=true plus this set of ports and mounts. With loopback-only binding, only the local machine can reach them by default; how to configure remote access is not covered by the evidence.
• The next step is pointing Claude / Codex / Cursor at that one URL; the command does not contain the URL’s actual value, so confirm it from the platform side once it is up. How the first login works is likewise nowhere in the evidence.

Use cases

• Case 1: one entry point for several clients. Scenario: people across the team use Claude, Codex, and Cursor, and nobody wants to wire MCP into each client separately. Approach: quickstart the platform as above and point the clients at Archestra’s single URL. What to expect: tool calls go through the MCP gateway and execute as the user themselves, and the same tools reach all three clients through the same entry. Boundary: the evidence lists no inventory of which services the platform side can take — before connecting, confirm that the services you need are among them.
• Case 2: nothing lands on a shared service account. Scenario: the team will not accept every tool call being recorded under one shared service account. It uses the gateway’s same identity mechanism. Approach: after connecting, check whether the tools run as the user themselves; if your automation runs under a shared account today, you can compare before and after. What is confirmed: the official statement says exactly that; what the account configuration screens and the call logs look like is absent from the evidence — do not presume they exist.
• The difference between the two cases: case 1 verifies the unified entry, case 2 verifies identity attribution; try each once, in turn.

Usage boundaries

• Read/write nature: the first launch already writes local state (the two named volumes); the socket mount lets the container control the host’s containers — the heaviest side effect of all, and one to weigh on its own.
• Credentials and identity: the gateway depends on OAuth; how the provider is configured, and whether an identity source must be connected first, are not explained by the evidence — unconfirmed.
• How clients and platform relate: the official line is to point users, agents, or clients at one URL and let the platform carry the rest; which versions or plugins each client needs is not mentioned.
• Version boundary: the official line is that production deployments should pin an exact version tag; latest usually maps to a release candidate — do not put real workload on it directly.
• Order of actions: accept the socket mount and the version question first, then run the command; finish the first trial inside a local loopback environment, and do not open it straight to the public internet.
• Key information still unconfirmed: resource usage, upgrade and rollback steps, data backup methods, the read/write declarations of each MCP tool inside the platform, and the initial credential policy are all outside the evidence; keep real data out of the first-trial environment. No documentation found does not mean no risk; the official docs are the reference.