<div align="center">

OpenBot

The AI assistant your company can actually own. Same shape as ChatGPT, Claude or Grok, with one difference that matters: it runs on your infrastructure and you can change anything about it. Any agent stack, through AG-UI.

Each coworker gets a computer of its own: a real browser with its own logins, its own files, and only the tools you grant. Every action decided before it happens and recorded after.

Talk to an engineer · Have us build it with you · copilotkit.ai/openbot · Quick start · Docs

</div>

https://github.com/user-attachments/assets/535ef7ee-1631-4a69-b839-564c56cf90b4

<div align="center">

Bring any AG-UI agent, written on a framework or by hand, and it arrives as a coworker with a channel of its own. Watch it work on its own screen, take the wheel when it reaches something it should not do alone, then hand it back. It answers with components rather than only prose, and the whole thing runs on your own machine.

</div>

A template, not a product. OpenBot is meant to be cloned and made your own. There is no hosted version to sign up for, and nothing here is published as a package to depend on: every workspace in this repository is private. You take the repository, replace the example tenant package under examples/ with your own coworkers, channels and skills, and run it. Everything below describes a starting point, not a finished thing somebody operates for you.

Alpha, and under active development. OpenBot is early. Expect rough edges and bugs, and expect things to move. Issues and pull requests are welcome.

Runs on your machine. Everything below is written for a laptop. .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 first. Sign-in turns that off, and is required before anybody else can reach the deployment.

Do not want to build it yourself? We will. Our engineers will stand OpenBot up inside your infrastructure, customize it into something that looks like your own product, and hand it back to you to keep changing. Start the conversation.

What it is

An agent platform that runs inside your own infrastructure. Docker Compose brings up every part of it, the data sits in your PostgreSQL, and the model is yours to choose: no model ships in the box, and an administrator supplies the credential, which is encrypted at rest and never logged.

Thirteen coworkers ship in the example package, and they are configuration rather than code: General Assistant for everyday work and Knowledge for company questions, a Risk Analyst reached as an endpoint, and ten in examples/fintech/agents/ that each do one job — reading an expense claim against the policy as written, turning a meeting note into the follow-ups actually in it, drafting release notes from what shipped, triaging a ticket, answering a new starter from the handbook, writing a brief that names what it could not find, writing up an interview, handing an on-call shift over, assembling what is known before a renewal, and grouping customer feedback into themes it can cite. Add your own by dropping a file in that directory, by editing agents.yaml, or from /agents in the UI.

Anything a Bot does to a computer, a file, an MCP server or a component goes through one gateway that decides and records it. That is the difference between an agent that can use your tools and an agent you can let near them.

More at copilotkit.ai/openbot.

Built on AG-UI

A Bot is any endpoint speaking AG-UI, the open protocol for agent-to-user interaction, so OpenBot is not tied to a framework and neither are you. Agents built with LangGraph, Mastra, CrewAI, Pydantic AI, Google ADK or written by hand all arrive the same way, and the governance rides the protocol rather than the framework.

<picture> <source media="(prefers-color-scheme: dark)" srcset="assets/architecture-dark.svg"> <img src="assets/architecture-light.svg" alt="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, which resolves the target, decides it against your policy, records an audit row, and only then acts, or refuses and names the rule. Allowed browser and file actions reach that Bot's own computer, one container each with its own Chromium, logins and workspace, built by the supervisor. Decisions land in PostgreSQL and threads in CopilotKit Intelligence."> </picture>

Requirements

• Docker, for PostgreSQL and the shipped Bots.
• Bun 1.3+, for the app and API server.
• A CopilotKit Intelligence project and license. A free plan is available, and Intelligence can be self-hosted.
• A model key. The proof-of-concept Bot uses OpenAI; the LangGraph Bot can use OpenAI, Anthropic, or Google.

Quick start

Setting up with an AI assistant? Paste prompt.txt into it first. It carries the same steps as below plus the things that are easy to get wrong: which of the ten blank keys in .env.example are actually yours to fill (three), which the start script generates for you, and what each start-up refusal means. Every claim in it is checked against this repository.

1. Create .env:

   cp .env.example .env
   

2. Get CopilotKit Intelligence credentials:

   npx --yes copilotkit@latest login
   npx --yes copilotkit@latest project select
   

   Put the cpk-... runtime key from project select in .env as INTELLIGENCE_API_KEY. That is the only Intelligence credential you need: managed Intelligence derives entitlement from the project key, so there is no separate licence token to fetch.

3. Fill the remaining required values:

   • OPENAI_API_KEY

   Keep the managed Intelligence URLs from .env.example unless you run Intelligence yourself. The example KEY_ENCRYPTION_KEY is public and fine locally; generate your own with:

   openssl rand -base64 32
   

4. Install and run:

   bun install
   bash scripts/start.sh
   

5. Open http://localhost:3010.

scripts/start.sh starts Docker services, applies migrations, starts the API server on port 3001, starts the app on port 3010, and checks that the services answer their own health routes before printing next steps.

scripts/stop.sh takes the same things down, including each Bot's computer, which compose does not own. Nothing is deleted: the database, the Bots' files and their browser profiles are volumes.

Deploy it

One image carries the app, the API, the browser the Bots drive, and optionally PostgreSQL. Same .env, no Kubernetes.

# The published image. Nothing to clone and nothing to build.
docker run -p 3001:3001 --env-file .env \
  -e EMBEDDED_POSTGRES=on -v openbot-data:/var/lib/postgresql \
  ghcr.io/copilotkit/openbot:latest

# Or the tree you have in front of you.
docker build -t openbot .
docker run -p 3001:3001 --env-file .env \
  -e EMBEDDED_POSTGRES=on -v openbot-data:/var/lib/postgresql openbot

Everything is on 3001 here, the app included, rather than the 3010 the clone uses. latest is the most recent release and a version tag such as :v0.0.9 pins one.

Leave EMBEDDED_POSTGRES off and set DATABASE_URL to point at a database you already run. docs/deployment.md has the minimum sizes, the platform notes, and how it behaves behind more than one replica.

Try it

• Open /bot and ask: Open news.ycombinator.com and tell me the top story.
• Ask the Bot to fill out https://httpbin.org/forms/post, then inspect /admin/audit.
• Open /admin/boundaries, add a deny rule or preset, and retry the same browser action.
• Create a coworker from /agents, give it a standing role, and start a channel with it.

Main surfaces

| Route | Purpose | | --------------------------- | ------------------------------------------------------------------ | | / | Start and browse channels. | | /agents | Create, edit, duplicate, hide, delete, and launch coworkers. | | /channel/:id | Converse with one coworker, watch its screen, and see what it ran. | | /bot | Direct chat with a Bot; ?agent=<id> selects one. | | /skills | Create and enable personal skills. | | /routines | See the routines that are standing, and stop one. | | /settings | User preferences. | | /admin/credentials | Store write-only encrypted credentials. | | /admin/computers | View, stop, and reset Bot computers. | | /admin/boundaries | Configure browser/file/MCP action policy. | | /admin/components | Publish components and govern which Bots may use them. | | /admin/playground | Draft and publish sandboxed components in the browser. | | /admin/plugins | Configure MCP servers and grant their tools to Bots. | | /admin/skills | Write deployment skills and grant them to Bots. | | /admin/people | List, promote, demote, and remove people who have signed in. | | /admin/identity-providers | Register a company SAML or OIDC provider, routed by email domain. | | /admin/audit | Review permitted, refused, and failed actions. |

Features

• A computer per Bot: the supervisor gives each Bot its own container, its own /workspace volume and its own browser profile. Set COMPUTER_RUNTIME=runsc to run them under gVisor where the host supports it.
• A shell, not just a browser: a Bot can run a command in its workspace, install what it needs, and process a file it saved. Through the same gate as everything else, so a rule can refuse a shell outright or refuse particular commands, and the command is on the record either way. The command inherits PATH, locale, terminal and proxy variables, not the rest of the deployment's environment.
• The gateway is the only way in: it resolves the target from a server-held snapshot, evaluates the policy, writes the audit row, and only then calls the computer. There is no path that acts without the record existing first.
• CEL policy, fail closed: rules can inspect tool.name, intent, bot.id, actor.id, page.url, page.host, element.*, key, command, file.*, mcp.* and initiator.* (what started the run, so a rule can refuse a scheduled routine what it would allow a person). Deny is evaluated before allow, a missing policy permits nothing, and a broken r