Obot: an MCP and LLM gateway for teams that need to govern AI clients

The problem Obot solves: ungoverned MCP servers and shared API keys

An engineer installs an MCP server from a README, pastes a provider key into a client config, and starts calling tools. Nothing about that flow is visible to anyone else. Multiply it by a team and you get shadow inventory: unknown servers, keys copied between laptops, and no record of which tool call touched which system.

Obot takes the position that the client does not have to change. The README states that desktop agents and tools such as Claude Code, Codex, Cursor, VS Code, and other IDEs and CLIs can use the parts of the platform that apply to them, and that no organization has to standardize on one client, model provider or tool ecosystem. The platform then supplies the missing layer: gateways for MCP and LLM traffic, an identity and secrets service, registries for approved servers and skills, sandboxed execution for hosted workloads, and correlated audit logs.

The audience is therefore not an individual developer looking for a nicer chat window. It is a platform or security team at an organization that has already lost track of which MCP servers and model credentials are in circulation.

How Obot works: gateways on the server, sentry on the device

The architecture has two halves. On user devices, desktop agents connect to Obot gateways, and Obot Sentry scans, audits and enforces policy on AI activity happening on the device itself. The Obot CLI is the piece users and AI clients talk to when discovering, installing and managing approved MCP servers and skills.

On the server side, Obot Server runs the MCP Gateway and the LLM Gateway. The MCP Gateway is described as a single governed entry point to every MCP server a user is allowed to reach. It can proxy servers hosted by Obot or running outside it, build composite servers that expose selected tools from several servers, and inspect, reject or modify requests and responses through MCP or webhook filters. Access is controlled per user or per identity-provider group, with MCP OAuth, user and shared credentials, and Kubernetes secret bindings.

The LLM Gateway presents provider-compatible endpoints for OpenAI, Anthropic, Amazon Bedrock, Azure and Generic Responses Compatible providers. Provider credentials stay in Obot rather than being distributed to users, clients authenticate with scoped Obot API keys, and Model Access Policies decide which models each user can see and call. Requests, responses, token usage and estimated model cost are recorded.

Hosted MCP servers and agents run in isolated environments outside the main server process, as Docker containers or Kubernetes workloads, including npx, uvx and containerized servers. Domain-based egress rules can be applied through a configured network-policy provider. Registries are Git-backed catalogs, either curated inside Obot or indexed from Git repositories, and MCP catalogs are exposed through the standard MCP Registry API. Sentry closes the loop by recording local tool calls alongside gateway traffic, and Device Management is marked as beta in the README.

Installing Obot with Docker and signing in for the first time

The README gives a Docker command for local development or evaluation. It publishes port 8080, keeps state in a named volume, and mounts the host Docker socket so that Obot can launch hosted MCP servers as sibling containers. Authentication is switched on with OBOT_SERVER_ENABLE_AUTHENTICATION, and OBOT_BOOTSTRAP_TOKEN is the first credential.

docker run -d \
  --name obot \
  -p 8080:8080 \
  -v obot-data:/data \
  -v /var/run/docker.sock:/var/run/docker.sock \
  -e OBOT_SERVER_ENABLE_AUTHENTICATION=true \
  -e OBOT_BOOTSTRAP_TOKEN=<token> \
  ghcr.io/obot-platform/obot:latest

The README states that the bootstrap token must be at least six characters, and that if you omit OBOT_BOOTSTRAP_TOKEN, Obot generates one and prints it in the container logs. If you are watching the logs for a generated token, that is the line to look for.

After the container is up, open http://localhost:8080 and sign in with the bootstrap token. The next step is to configure an authentication provider. A model provider is only required when you intend to use the LLM Gateway, so a deployment that only proxies MCP servers can stop earlier.

The README is explicit that this Docker configuration is for development, evaluation or trusted single-tenant environments, because the socket mount gives Obot the ability to start containers on the host. For production or multi-tenant installations it points to the Kubernetes deployment and the Installation Guide, which covers external PostgreSQL, encryption and production authentication.

Where Obot is the wrong tool: single users, untrusted hosts, no Kubernetes

The Docker socket mount is the sharpest limitation. Handing a service the host Docker socket means that service can start containers as siblings, which is precisely how hosted MCP servers work. On a shared or multi-tenant machine that is a privilege boundary problem, and the README treats it as one by steering production installs to Kubernetes. If your team has no Kubernetes and no appetite for running one, the evaluation path is a dead end rather than a starting point.

Scale is the second constraint. The Dockerfile builds on a Wolfi base image and installs PostgreSQL 17 inside the image, and the README lists external PostgreSQL as a production configuration topic. That suggests the bundled database is meant for evaluation. Anyone expecting the single-container command to become a production deployment should read the Installation Guide first.

Device-level governance depends on Obot Sentry, which the README describes as beta for Device Management. Enrolling devices, installing hooks for Claude Code, Codex, Cursor and VS Code, and applying monitoring and enforcement policies is a beta surface. An organization that needs audited endpoint coverage today should treat that coverage as incomplete rather than assume it.

Finally, Obot is not a chat product. If a team wants one assistant with one interface, the platform's premise of letting users keep their existing clients works against that goal. The gateways govern traffic; they do not replace the client.

Obot compared with running an MCP gateway library yourself

The closest alternative is not another governance product but the do-it-yourself route: a self-written proxy in front of your MCP servers, plus a secrets manager and log pipeline behind it. The difference is in what you have to build. A hand-rolled proxy can forward requests, but the MCP Gateway in Obot also composes new servers from selected tools across servers, applies MCP or webhook filters that can reject or modify payloads, and controls access by identity-provider group. Those are separate features you would otherwise implement and test individually.

The LLM side differs in the same way. A generic reverse proxy in front of a provider API forwards keys and requests. Obot keeps provider credentials server-side, issues scoped Obot API keys to clients, applies Model Access Policies per user, and records token usage and estimated model cost per request. The audit correlation across MCP servers, LLM providers, hosted workloads and devices is the part that is hardest to reproduce by assembling open source components, because each component would log in its own format.

The trade-off is depth versus control. A custom proxy fits your exact routing rules and adds no new dependency. Obot adds a Go service, a UI, a database, container or Kubernetes orchestration, and a Git-backed catalog model you have to populate before the registries are useful. If your MCP footprint is two servers and five engineers, the platform is more machinery than the problem.

Maintenance, licensing and what the repository tells you about upgrades

Obot is MIT licensed, which permits commercial use and modification with the usual requirement to keep the licence and copyright notice. The Dockerfile pulls several prebuilt images from ghcr.io/obot-platform, including providers, enterprise-providers and encryption binaries, so a deployment depends on artifacts outside this repository even though the server code itself is MIT. Anyone auditing the supply chain should note those image references rather than assume a single self-contained binary.

The repository is not archived, and the last push was on 2026-09-10. Releases are frequent and include release candidates: v0.25.5 and v0.25.6-rc1 both appeared on 2026-09-09. A project that ships release candidates alongside stable tags on the same day expects operators to pin a version rather than track latest. The README's Docker example uses the latest tag, which is convenient for evaluation and a poor choice for a governed deployment.

Upgrade cost is dominated by schema and configuration rather than code. The README lists external PostgreSQL, encryption and authentication as production configuration topics, and the repository carries separate aws-encryption.yaml, azure-encryption.yaml and gcp-encryption.yaml files, so encryption setup is provider-specific and worth versioning alongside your manifests. There is also a design process to follow: significant changes begin as Obot Design Proposals so the architecture can be discussed before implementation. Teams that need to modify core behaviour should expect to write a proposal, not just a pull request. The README does not document a rollback procedure for upgrades.

Editorial conclusion

Adopt Obot if you already have several AI clients in use and need MCP servers, provider keys and audit records behind one policy layer. Do not adopt it if you want a single chat UI or you cannot run Docker or Kubernetes. Verify first that your identity provider and Git provider appear in the integration list, and that the Docker socket mount is acceptable only on a trusted single-tenant host; the README points production and multi-tenant installs at the Kubernetes path.

Frequently asked questions

Official sources

1. License: MIT
2. obot-platform/obot on GitHub
3. Project website
4. README
5. Releases