deco Studio: an MCP control plane for teams that keep handing out API keys
Open-source control plane for your AI agents. Connect tools, hire agents, track every token and dollar
At a glance
- What is it?
- deco Studio is an MIT-licensed TypeScript control plane that puts agents, MCP connections, model routing, and per-call cost accounting behind one endpoint. The interesting part is the vault and the RBAC model; the part to scrutinise is operational weight.
- Who is it for?
- Adopt deco Studio if you already run several MCP servers and the credential sprawl is the actual bottleneck: the vault, tool-level grants, and per-call cost attribution are the reason to take on a control plane. Do not adopt it if you have one agent and two tools, or if you cannot run PostgreSQL and a long-lived Bun process, because the platform will cost more to operate than the problem it removes.
- Can I use it commercially?
- Yes. MIT is a permissive licence: you can use, modify and sell software built on it, as long as you keep its copyright and licence notices.
- 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 is credential sprawl, not agent capability
Most teams do not have an agent problem. They have a secrets problem that agents made visible. A developer wires Claude Desktop to a GitHub MCP server, another wires Cursor to Postgres, a third pastes a Slack token into a JSON file on a laptop. Each connection is a personal credential with organisation-wide reach, and nobody can answer which agent touched which system last Tuesday.
deco Studio targets that specific mess. The README frames it as packaging "the infrastructure behind an internal AI rollout: model routing, MCP authentication, agent configuration, SSO, RBAC, audit logs, and usage accounting." The audience is explicit: platform or infrastructure engineers at an organisation that has already decided to roll AI tooling out to more than one team and now needs the boring layer underneath. It is not aimed at a solo developer who wants a chat window, and the README's own framing ("Your team needs a secure internal vibecoding platform") is unusually blunt about that.
One endpoint in front of agents, connections, and models
The architecture in the README is a three-tier diagram. Clients (Cursor, Claude, VS Code, custom agents) talk to deco Studio. Studio holds agents, connections, models, the vault, and observability. Below that sit the actual tools and MCP servers: GitHub, Slack, Postgres, OpenRouter, your own APIs.
The unit of packaging is the agent. An agent contains instructions, skills, files, approved MCP access, and a model policy, and it is published to the organisation. The detail that matters is that each agent is itself an MCP endpoint, callable from Cursor, Claude Desktop, custom code, or another agent. That inverts the usual arrangement: instead of every client holding credentials for every tool, clients hold a single endpoint and the endpoint decides what the caller may reach.
Connections are registered at the organisation level through a web UI with one-click OAuth, and tokens live in an encrypted vault. Access is granted at tool level by organisation, role, or agent. The README's phrasing is "share MCP capabilities, not credentials," which is the whole design in five words.
Models sit behind a router. OpenRouter is one option; Anthropic, OpenAI, Google, or any compatible provider can be connected directly, and the choice is made per agent and per tool. There is also a path for engineers to link their own Claude Code or Codex session and use the subscription already authenticated on their machine. That last feature is worth pausing on, because it is unusual: it lets a developer's existing seat count toward agent work, which in practice means the cost model is not purely per-token billing through the router.
Virtual MCPs are the answer to tool-surface growth
Once you register a dozen MCP servers, the tool list handed to a model becomes the limiting factor. Studio's response is Virtual MCPs: one endpoint with different strategies for which tools to surface.
The README names three. Full-context exposes everything and is described as simple, deterministic, and good for small toolsets. Smart selection narrows the toolset before execution. Code execution loads tools on demand in a sandbox.
This is the most interesting design decision in the repository and also the least specified. The README gives no selection criteria for smart selection, no sandbox implementation detail, and no guidance on when code execution is worth the added complexity over full-context. If you are evaluating Studio specifically for a large tool surface, that is the area where the supplied documentation runs out and you will need the linked docs site.
Getting it running takes two commands, and then a decision
The quick start is genuinely short. The README gives:
bunx decostudio
or, from source:
git clone https://github.com/decocms/studio.git bun install bun run dev
The dev server runs at http://localhost:4000 for the client, with API routes proxied to the Bun server.
The decision comes after. Local mode is `bunx decostudio` on a desktop with an embedded PostgreSQL, described as private. Cloud mode means logging in to studio.decocms.com and controlling local projects from any browser. Team mode adds invitations, SSO, and roles. The README's table is cut off mid-row at "Invite people. SSO", so the full team feature set is not recoverable from this material.
The dependency picture is worth stating plainly: TypeScript, Bun as the runtime, React 19 and Hono on the front end and server, PostgreSQL for storage, OpenTelemetry for tracing. That is a modern stack, but it means a self-hosted deployment is a Node-adjacent service plus a database, not a binary you drop on a laptop and forget.
Cost attribution is the feature that survives the honeymoon
Observability here is not log aggregation. The README states that Studio traces the user, agent, model, tools, latency, errors, tokens, and cost for every thread, and that usage can be broken down by agent, connection, organisation, or teammate.
That breakdown is the part with real organisational value, because it answers a question finance will eventually ask: which team's agents are burning the budget. It also pairs with the model router, since per-agent and per-tool model choice is only meaningful if you can see the cost difference afterwards.
The limitation is that this is accounting, not enforcement. The README describes tracking and breakdowns; it does not describe hard spend caps, per-team budget limits, or what happens when a limit is hit. If your requirement is "stop the spend at a threshold," the supplied material does not confirm that Studio does it.
Where deco Studio is the wrong tool
The honest failure mode is over-provisioning. If you have one agent and three tools, Studio adds a PostgreSQL instance, a Bun server, an OAuth registration flow, and a permissions model to maintain. The credential sprawl it removes does not exist yet at that scale, and you have taken on a platform to solve a problem you could handle with a single config file.
A second boundary is the MCP assumption. Studio is built around MCP as the integration surface. Systems that do not speak MCP have to be wrapped before they fit, and the README's list (GitHub, Slack, Postgres, Sentry, OpenRouter, your APIs) is a set of examples rather than a claim of universal coverage.
A third is release cadence as an operational cost. The three most recent releases listed are v4.346.0, v4.345.5, and v4.345.4, published on 2026-09-10 at 16:15, 15:15, and 14:33 UTC. Patch releases an hour apart on a single day indicate a project that ships continuously. That is fine if you deploy from a pinned version and upgrade deliberately. It is a problem if you track main on a shared internal service, because you will be restarting a control plane that other people's agents depend on.
Finally, the README's own positioning cuts both ways. It calls Studio a "secure internal vibecoding platform." If your organisation's review process treats that framing as unserious, the SSO, RBAC, and audit log features underneath will not save the procurement conversation.
How it differs from n8n and from a bare MCP client
The repository's own topic list includes n8n, which invites the comparison. The difference is where the logic lives. n8n is a workflow engine: you draw a graph of nodes, and the graph is the artefact you maintain. Studio's artefact is the agent, which packages instructions, skills, files, tool grants, and a model policy, and is then exposed as an MCP endpoint that other clients call. In n8n the trigger and the orchestration are the product. In Studio the orchestration happens in whatever client you already use (Cursor, Claude Desktop, custom code) and Studio supplies identity, credentials, routing, and accounting.
Against a bare MCP client, the difference is the vault and the grant model. A client configured with MCP servers directly holds credentials per machine, per user. Studio moves the credentials to an organisation-level vault and issues tool-level grants by organisation, role, or agent. The trade is that every tool call now transits a service you operate, which is exactly the point, and exactly the cost.
There is also a project layer that neither alternative has in the same form. Projects group agents and connections around a goal, and the README states the UI adapts to what is inside: a content agent plus a CMS connection produces a content-management sidebar, an analytics agent plus a database produces dashboards and queries. That is a genuine architectural bet on configuration-driven UI, and it is the claim in the README most likely to disappoint in practice, because adaptive interfaces tend to be excellent for the demo case and awkward for the case the author did not anticipate.
Licence, maintenance, and what to check before you commit
Studio is MIT licensed, which is the permissive end of the spectrum: it permits commercial use, modification, and redistribution, with the usual requirement to preserve the copyright notice and licence text. This is not legal advice, and if you are embedding Studio in a product you sell, have counsel read LICENSE.md in the repository rather than a summary of it.
The MIT grant also means there is no vendor lock-in at the licence layer, but there is lock-in at the operational layer. Your agents, connections, and grants live in Studio's PostgreSQL database. Migrating away means re-registering MCP servers and re-granting access somewhere else, and the README offers no export path.
Maintenance cost is dominated by the cadence described above. A control plane that other people's agents depend on needs a version pinning policy and a test environment, which is more process than a config file requires. On the plus side, the stack is unremarkable (Bun, Hono, React, PostgreSQL, OpenTelemetry), so the skills to operate it are already on most platform teams.
What to verify first, in order: that your existing MCP servers register through the web UI without hand-written JSON, since that is the core promise and the README gives no fallback for servers that resist one-click OAuth; that tool-level grants by organisation, role, or agent can express your actual permission model rather than an approximation of it; and that the observability breakdown matches your reporting lines, because cost attribution that does not map to a budget owner is just a nicer log.
Editorial conclusion
Adopt deco Studio if you already run several MCP servers and the credential sprawl is the actual bottleneck: the vault, tool-level grants, and per-call cost attribution are the reason to take on a control plane. Do not adopt it if you have one agent and two tools, or if you cannot run PostgreSQL and a long-lived Bun process, because the platform will cost more to operate than the problem it removes. Before committing, verify three things in your own environment: that your existing MCP servers register through the web UI with one-click OAuth rather than needing hand-written config, that the tool-level access rules map onto your organisation's actual roles, and that the observability breakdown by agent, connection, organisation, or teammate matches how you report spend. Also check the release cadence against your upgrade tolerance: v4.345.5 and v4.346.0 landed an hour apart on the same day, which tells you the project ships fast and expects you to keep up.
Community notes