openbot
Open-source AI coworkers that each get a computer of their own: a browser, files and tools, with every action decided before it happens and recorded after. Bring any AG-UI agent.
What is it?
What it is
An agent platform that runs inside your own infrastructure, providing AI coworkers each with their own computer (browser and workspace) and governed by a gateway that records every action.
Why it exists
To give users AI coworkers they can trust with real work, ensuring every action is decided and recorded, with policy enforcement and audit trails.
Who should use it
Teams and organizations seeking autonomous AI agent platforms with full control over infrastructure, security, and governance. Specifically: companies building internal AI coworkers, developers creating custom agent workflows, and teams requiring on-premise or private deployment of AI agents.
Who should avoid it
Beginners unfamiliar with AI agent concepts, projects lacking dedicated DevOps resources for managing complex deployments, and environments where strict security controls and self-hosting are not required. Those new to Docker, PostgreSQL, or the AG-UI protocol will find the initial setup challenging.
Stars over time
No change stars in the last 1 day
How it works
A quick walkthrough in plain English
How OpenBot works
Step 1 of 3
You interact with it
Open OpenBot, send a request, or connect it to your stack.
Features
Advantages
- Runs on your own infrastructure for full data and model control
- Each Bot operates in an isolated environment (own browser, file system, and workspace)
- Strong security with gateway-mediated actions, policy enforcement, and immutable audit trail
- Flexibility to bring your own AG-UI agent or use built-in coworkers
- Component-based interactions for richer user experience beyond prose
- Supports multiple identity providers (Google, Microsoft, Okta, SAML, OIDC)
- MIT license allows permissive use and modification
Disadvantages
- Currently in Alpha stage with potential rough edges and bugs
- Requires multiple dependencies: Docker, Bun, CopilotKit Intelligence (with license), and a model API key
- Setup involves several steps including environment configuration and credential management
- Embedded PostgreSQL option is not suitable for production (requires external database)
- Certain local-only features (like AGENT_COMPUTER_ALLOW_PRIVATE_HOSTS) are disabled in production
Installation
docker
docker build -t openbot . docker run -p 3001:3001 --env-file .env \ -e EMBEDDED_POSTGRES=on -v openbot-data:/var/lib/postgresql/data openbot
FAQ
How do I get started with OpenBot?
1. Copy `.env.example` to `.env` and fill required values. 2. Run `npx --yes copilotkit@latest login`, `npx --yes copilotkit@latest project select`, and `npx --yes copilotkit@latest license --write` to get CopilotKit Intelligence credentials and write the runtime key and license token into `.env`. 3. Add `OPENAI_API_KEY` (or other model keys) and generate a `KEY_ENCRYPTION_KEY` with `openssl rand -base64 32`. 4. Install dependencies with `bun install` and start the stack via `bash scripts/start.sh`. 5. Open <http://localhost:3010> to begin using the UI.
What are the system requirements for running OpenBot?
- Docker (for PostgreSQL and the per‑Bot computers). - Bun 1.3+ (for the app and API server). - A CopilotKit Intelligence project and license (free plan available, can be self‑hosted). - A model key (the proof‑of‑concept Bot uses OpenAI; the LangGraph Bot supports OpenAI, Anthropic, or Google). - Required environment variables: `DATABASE_URL`, `KEY_ENCRYPTION_KEY`, `INTELLIGENCE_API_URL`, `INTELLIGENCE_GATEWAY_WS_URL`, `INTELLIGENCE_API_KEY`, `COPILOTKIT_LICENSE_TOKEN`.
How do I deploy a custom agent (bring my own agent) in OpenBot?
Any AG‑UI endpoint can become a Bot. You can create a coworker via the `/agents` UI or by editing `agents.yaml`. Provide a name, title, role description, visibility (private/public), an optional AG‑UI endpoint URL, and a write‑only authorization header if needed. The server validates custom endpoints against `AGENT_ENDPOINT_ALLOWED_HOSTS` and checks them on each redirect. If no custom endpoint is set, product‑created coworkers use `MANAGED_AGENT_AG_UI_URL` when configured; otherwise they are refused. Private addresses are only allowed if listed in `AGENT_ENDPOINT_ALLOWED_HOSTS`.
How does governance and audit work in OpenBot?
Every Bot action passes through a single gateway that resolves the target, evaluates a CEL policy, writes an audit row, and then executes the action (or refuses it). Policies can inspect fields like `tool.name`, `intent`, `bot.id`, `actor.id`, `page.url`, `page.host`, `element.*`, `key`, `file.*`, and `mcp.*`. Deny rules are evaluated before allow rules; a missing policy permits nothing, and a broken rule refuses rather than opening. The audit trail is viewable at `/admin/audit`, showing permitted, refused, and failed actions with the rule that caused each refusal. Boundaries and presets are configured via `/admin/boundaries`.
How are credentials and secrets managed in OpenBot?
Credentials are stored write‑only and encrypted at rest via the `/admin/credentials` surface. They are never returned by any API and are redacted from audit events. Use a strong `KEY_ENCRYPTION_KEY` (generated with `openssl rand -base64 32`) to protect them. Never commit credential values to version control or tenant YAML files.
How do I take the wheel when a Bot needs help (e.g., login or 2FA)?
When a Bot encounters a login wall or 2FA prompt, it asks for assistance. You can take control directly in the same panel. This interaction is recorded as `computer.help_requested`, `computer.control_taken`, and `computer.control_released`. While a human is driving, Bot actions are refused rather than queued, ensuring you stay in command until you release control.
Featured in Videos
YouTube tutorials and walkthroughs for openbot
Alternatives
Similar projects ranked by category, topics, and text overlap.
