DEV Community

Cover image for OpenBot: Self-hosted multi-bot collaboration with workspace credential isolation
Dongsheng
Dongsheng

Posted on

OpenBot: Self-hosted multi-bot collaboration with workspace credential isolation

The problem

Engineering teams want several specialized assistants - not one chat box with everyone's API keys in a shared settings page. SaaS multi-agent products often mean someone else's trust boundary. Homegrown wrappers usually skip workspace membership, audit trails, and Bot versioning.

What OpenBot is

OpenBot is an AGPL-3.0, self-hosted multi-bot collaboration system. The current implementation includes local auth + optional OIDC, workspace membership and groups, scoped API tokens, and persistent Bot identities - shipped as a SvelteKit web app, Fastify API, PostgreSQL migrations, and a Docker Compose development stack.

Personal connections support OpenAI Chat Completions, OpenAI Responses, and Anthropic Messages-compatible endpoints, with credential-safe settings and live text/action compatibility probes. Workspace model connections support shared use without sharing credentials. Capability settings record verified evidence, explicit overrides, and compatible fallback chains.

Source: github.com/Blackman99/openbot

What you get

Self-hosted, no phoning home

OpenBot sends no telemetry, analytics, or update checks. Idle instances make no outbound requests. Named volumes preserve users, workspaces, task state, and attachments across restarts.

Identity & access

First-owner setup with OPENBOT_SETUP_TOKEN, local accounts, optional OIDC (Auth Code + PKCE). Workspace API tokens with fixed scopes (me:read, bots:*, groups:*, tasks:*, events:read, ...); only SHA-256 digests persisted; audits without credential material.

Bot identities

Create Bots with purpose -> role description + system instructions, model binding, execution limits, immutable version history, permissions and discovery, archive / soft-delete with a 30-day recovery window, copy configuration, and template export.

Conversations, tasks, routing

Unified conversation list for groups and private Bot chats. In groups: @Bot for an explicit task, or routing via a built-in workspace assistant (handoff), default lead, or local profile match. Task cards support approve, reject, answer, pause, cancel, and retry; plus streaming drafts, Markdown-safe answers, and optional SVG/HTML design artifacts in a sandboxed preview.

Personal & workspace models

Protocol-explicit adapters; AES-256-GCM for keys and custom headers; provider host / scheme / private CIDR allowlists with DNS pinning; test-and-save probes.

Routines

One-shot and repeating cron schedules in the routine's own IANA time zone; cost budgets; Bot collaboration tools limited to request_input, request_approval, delegate, and handoff (Bots cannot create or escalate routines).

Ops hygiene

Restricted openbot_runtime DB role; backup/restore archives; explicit upgrades via migrate; workspace export (no secrets); soft-delete + planned purge; PWA install with network-first offline shell and nonce CSP.

Quick start

# Docker + Compose plugin
cp .env.example .env
docker compose up --build
Enter fullscreen mode Exit fullscreen mode
  • Web: http://localhost:3000
  • API status: http://localhost:3001/api/v1/status

Before a non-local deploy: use unique Postgres passwords, a high-entropy setup token, OPENBOT_ALLOW_INSECURE_LOCAL_PASSWORD=false, an exact HTTPS WEB_ORIGIN, and TLS termination. Loopback bind is the default.

The optional local Node path uses Node.js 24 + pnpm 11: pnpm install, pnpm db:migrate, then run the API and web dev servers. Verify with pnpm verify.

Who it's for

  • Teams that must keep model credentials and chat data on infrastructure they control
  • Groups that want multiple specialist Bots with real membership, permissions, and audit history
  • Operators comfortable with Docker Compose and Postgres-backed services

Who it's not (yet) for

  • Anyone expecting a hosted SaaS or one-click "bring your ChatGPT team"
  • Single-user laptop toys that don't need workspaces, OIDC, or API tokens

  • Shops that need a closed-source or permissive license for linking (this is AGPL-3.0 only)

Light comparison (not a roast)

Need Typical pick OpenBot angle
Hosted multi-agent chat SaaS copilots Self-hosted; your DB and encryption key
Single-agent wrapper Custom Lang* scripts Persistent Bot identities, groups, tasks, routines
"Share one API key" team setup Shared .env Personal vs workspace connections; no shared secrets

Try it / tell us what's wrong

Feedback is especially useful on:

  1. First Compose bring-up and setup-token flow
  2. Whether Bot permissions + discovery match how you'd grant access
  3. Provider allowlists and Anthropic + OpenAI protocol quirks in your environment

GitHub - Blackman99/openbot

Comment with your current self-hosted agent stack and the one missing piece - we'll prioritize from real replies.

Top comments (0)