OpenBot: a self-hosted agent platform where every tool call passes a gateway first

The problem OpenBot addresses: agents with access but no checkpoint

Most agent setups give a model a tool list and let it call those tools directly. The failure mode is familiar: the agent has the same reach as the credential you handed it, and the only record of what happened is whatever the tool itself logged, if anything. OpenBot's answer is to put one gateway between the agent and everything it can touch. The README states that anything a Bot does to a computer, a file, an MCP server or a component goes through a single gateway that decides and records it, and frames the distinction as the difference between an agent that can use your tools and an agent you can let near them.

The audience is narrow on purpose. This is for teams that already have an agent and want to run it against real systems (a browser with logins, a filesystem, internal MCP servers) without standing up a bespoke approval layer themselves. It is not aimed at someone who wants a chat interface over a document store. The shipped example package makes the intended shape concrete: three coworkers named General Assistant, Knowledge and Risk Analyst, described in the README as configuration rather than code, defined in agents.yaml or added from the /agents page in the UI.

How a turn flows: AG-UI in, gateway in the middle, PostgreSQL and Intelligence behind

The architecture is described in the README's diagram caption, and it is worth reading closely because it defines the trust boundary. You talk to the server, which sends the turn to a Bot over AG-UI. Every tool call the Bot makes comes back through the gateway. The gateway resolves the target, decides the call against your policy, records an audit row, and only then acts. If policy refuses, it refuses and names the rule that refused it. Allowed browser and file actions reach that Bot's own computer, which the README describes as one container each with its own Chromium, logins and workspace, built by the supervisor. Decisions land in PostgreSQL; threads land in CopilotKit Intelligence.

Two properties follow from that ordering. First, the decision happens before the action, so a refusal costs nothing and leaves a named rule behind rather than a partial side effect. Second, the audit row is written before the action executes, not after it returns, which means a crash mid-action still leaves a record that the action was permitted. The protocol choice matters here too: a Bot is any endpoint speaking AG-UI, so the governance rides the protocol rather than the framework. The README names LangGraph, Mastra, CrewAI, Pydantic AI, Google ADK and hand-written agents as arriving the same way. That is the claim to test first, because if your agent cannot present an AG-UI endpoint, the gateway has nothing to sit in front of.

Getting it running: Bun, Docker, two credentials and a start script

The requirements list is short and specific. Docker for PostgreSQL and the shipped Bots. Bun 1.3 or later for the app and API server. A CopilotKit Intelligence project and license, with a free plan available and self-hosting possible. And a model key: no model ships in the box, the proof-of-concept Bot uses OpenAI, and the README says the LangGraph Bot can use OpenAI, Anthropic or Google. An administrator supplies the credential, which the README states is encrypted at rest and never logged.

The quick start is five steps. Copy the environment file with cp .env.example .env. Fetch Intelligence credentials with npx --yes copilotkit@latest login followed by npx --yes copilotkit@latest project select, then put the cpk-... runtime key into .env as INTELLIGENCE_API_KEY. Fill OPENAI_API_KEY. Generate a real KEY_ENCRYPTION_KEY with openssl rand -base64 32, since the example value is public and only acceptable locally. Then bun install and bash scripts/start.sh, and open http://localhost:3010.

What start.sh does is documented: it starts Docker services, applies migrations, starts the API server on port 3001, starts the app on port 3010, and checks that services answer their own health routes before printing next steps. The matching scripts/stop.sh takes the same things down including each Bot's computer, which the README notes compose does not own. Nothing is deleted, because the database, the Bots' files and their browser profiles are volumes. The .env.example carries OPENBOT_SINGLE_USER=true, which admits every request as one administrator so a fresh clone reaches the product without registering an OAuth client. Sign-in turns that off and the README says it is required before anybody else can reach the deployment. There is also a prompt.txt intended to be pasted into an AI assistant, which the README says covers which of the ten blank keys in .env.example are actually yours to fill (three), which the start script generates, and what each start-up refusal means.

Deployment is one image, and EMBEDDED_POSTGRES is the switch that matters

The README gives a deployment path that avoids Kubernetes entirely. Build with docker build -t openbot . and run it with -p 3001:3001, --env-file .env, -e EMBEDDED_POSTGRES=on and a volume at /var/lib/postgresql. The image is described as carrying the app, the API, the browser the Bots drive, and optionally PostgreSQL. If you already run a database, leave EMBEDDED_POSTGRES off and set DATABASE_URL instead. docs/deployment.md is cited for minimum sizes, platform notes, and behaviour behind more than one replica.

That last pointer is doing more work than it looks. The gateway writes audit rows to PostgreSQL and the supervisor builds one container per Bot, so running more than one replica raises questions the README does not answer in the body text: which process owns container lifecycle, and whether audit writes from multiple instances converge on the same policy view. The README says the answers are in docs/deployment.md rather than here, so treat that document as required reading before scaling out, not as optional. A single-node deployment on a laptop or one VM is the shape the documentation actually describes end to end.

Where OpenBot is the wrong tool: alpha, template-only, and no package to depend on

The README is unusually direct about this, and it should be taken literally. OpenBot is a template, not a product. There is no hosted version to sign up for, and nothing in the repository is published as a package to depend on: every workspace is private. You clone it, replace the example tenant package under examples/ with your own coworkers, channels and skills, and run it. Upgrades therefore mean merging or rebasing against a moving repository rather than bumping a version in package.json. The release history supports the pace claim: v0.0.6, v0.0.7 and v0.0.8 all landed within a week of each other in September 2026, and the README carries an alpha badge with a note that things will move.

The second limitation is the dependency on CopilotKit Intelligence. Threads land there, and the runtime key is the only Intelligence credential the README says you need, because managed Intelligence derives entitlement from the project key. Self-hosting Intelligence is offered as an option, which matters for anyone who cannot send thread data to a managed service, but the README does not walk through that path in the material available here. The third is the single-user default. OPENBOT_SINGLE_USER=true admits every request as one administrator, which is fine on a laptop and disqualifying for anything reachable, so sign-in is not optional once a second person can hit the port. Finally, the per-Bot container model has a real cost: each coworker gets its own Chromium, logins and workspace, and those are volumes that persist across stop.sh. That is the right call for isolation and the wrong call if you wanted twenty cheap coworkers on one box.

How this differs from pointing an agent straight at MCP servers

The obvious alternative is to skip the platform and wire your agent directly to MCP servers and a browser automation library, which is what most teams do first. The difference is not capability, it is where the decision lives. In the direct setup, policy is whatever each tool enforces and the audit trail is whatever each tool logs, so a browser action and a file write produce records in two different places with two different formats, and neither one knows about the other. In OpenBot, the README describes a single gateway that resolves the target, decides against your policy, writes the audit row, and then acts or refuses with the rule named. One format, one place, one ordering guarantee.

There is a second difference in the agent contract. Direct wiring tends to bind you to whichever framework's tool-calling convention you started with. OpenBot takes any endpoint speaking AG-UI, so LangGraph, Mastra, CrewAI, Pydantic AI, Google ADK and hand-written agents arrive identically. The trade is that you now run a platform (PostgreSQL, a supervisor that builds containers, an API server on 3001, an app on 3010) where before you ran a script. For a single agent doing read-only work, the script wins. For several agents touching a logged-in browser and shared files, the gateway is the part you would otherwise have to build, badly, under deadline.

Licence and the cost of staying current

OpenBot is MIT licensed, which permits commercial use, modification and redistribution provided the copyright notice and permission notice are retained. That is a permissive position for a template you are expected to fork and modify, and it is consistent with the README's instruction to replace the example tenant package with your own. Two caveats sit outside the licence itself and are not legal advice. First, the CopilotKit Intelligence dependency has its own terms: the README mentions a free plan and a self-hosted option, so the licence of OpenBot's code does not settle what you owe for the Intelligence service or what happens to thread data you send it. Second, MIT covers the repository, not the models you connect or the third-party MCP servers your Bots call.

Maintenance cost is the more practical number. Because nothing is published as a package, every upstream change is a merge into your fork, and the September 2026 release cadence suggests those merges will be frequent. The mitigation visible in the repository is that coworkers are configuration rather than code, so your edits concentrate in examples/ and agents.yaml rather than in the gateway itself. Keep the diff between your fork and upstream small, and the recurring cost stays in reviewing what changed in the gateway and the supervisor.

Editorial conclusion

Adopt OpenBot if you want AG-UI agents running on your own hardware with a single mediation point for browser, file, MCP and component actions, and you are willing to treat the repository as a starting point rather than a dependency, since every workspace in it is private and nothing is published as a package. Do not adopt it if you need a supported release, a hosted sign-up, or a stable API surface; the README labels it alpha with rough edges and bugs expected. Before cloning, verify three things: that your agent already speaks AG-UI or can be wrapped to, that you have a CopilotKit Intelligence project (free plan available, self-hosting possible) plus a model key, and that you understand the ten blank keys in .env.example, of which the README says only three are yours to fill and the rest the start script generates.

Official sources

1. CopilotKit/OpenBot on GitHub
2. License: MIT
3. Project website
4. README
5. Releases