This is a third-party deployment note, not official CopilotKit / OpenBot documentation. It covers one checked path for v1.0.0: the official all-in-one image, a minimal Compose wrapper, and HTTPS on the host with Caddy. It is not the repository root development Compose, and it does not cover Helm or supervisor multi-tenant layouts.
CopilotKit/OpenBot is also not OpenMausBot (local-first CLI engine orchestration with pairing login), and not nightly-labs/openbot (a separate product line and license).
Keep the public surface small
Start with Docker Engine, Compose V2, and a hostname whose A record points at the VPS. Inbound website traffic should be TCP 80 and 443 only. Do not publish 3001, 4100, or 5432 to the internet—check IPv6 and cloud security groups the same way you check IPv4.
The application listens on port 3001 inside the container. Map that port to loopback only:
ports: - "127.0.0.1:3001:3001" Put a host Caddy site block in front of that listener:
openbot.example.com { reverse_proxy 127.0.0.1:3001 } Replace the hostname with yours. Caddy handles certificates and forwarding; there is no need to expose 4100 as a separate public location. If Caddy runs in another container instead of on the host, 127.0.0.1 refers to that other container—do not “fix” reachability by binding 3001 to a public address.
Pin the release digest, not latest
At the guide’s check time (2026-11-10, Asia/Shanghai), v1.0.0 is commit ac9c16f72bf2690d3bc968dddde3e160819f4e13. The release asset container-images.json lists the all-in-one image as:
ghcr.io/copilotkit/openbot@sha256:ee4bb211c066a2f15c6260889173aeb148d769b7f52575d5bcf9cf001f53a60c Download that manifest, inspect the digest on the VPS (docker buildx imagetools inspect or docker manifest inspect), then pull and run that reference. Do not assume latest matches the release you just read. A no matching manifest error means the host architecture does not match the digest’s platforms—switch machines or build from the v1.0.0 source tree; do not swap to latest to hide the mismatch.
The Compose service should use that digest as image, enable embedded PostgreSQL when you want the single-container path (EMBEDDED_POSTGRES=on), and keep three named volumes for PostgreSQL data, the bot workspace directory, and browser profiles. After up -d, check http://127.0.0.1:3001/health locally, then https://your-domain/health through Caddy.
The concrete pitfall: routines look scheduled, but nothing fires
The all-in-one image does not include a scheduled routines worker, and it does not periodically cull unsent attachments. Official deployment docs state this boundary clearly. The Routines UI can show a next run time even though nothing will trigger that run. The same image ships one-shot scripts such as bun scripts/fire-routines.ts and bun scripts/cull-staged-attachments.ts under /app/server, but the single container does not run them on a timer for you.
Without an external scheduler (and a verified worker / environment injection path), routines never fire on their own. Staged attachments that stay unsent can keep consuming quota—official deployment notes list a server-side cap of 32 unsent attachments per person, up to 8 MiB each—until uploads start failing.
Do not treat a healthy single container as an unattended production install until those two jobs are scheduled and verified outside the all-in-one process. Restarting the web UI does not install a worker. If you start a second container from the same image to run a script, override the entrypoint so /init does not bring up a second full service stack.
Login and what to preserve
Public HTTPS alone is not authentication. Configure a real identity provider (Google, Microsoft, or Okta callbacks under /api/auth/callback/...), set INITIAL_ADMIN_EMAILS, and keep Intelligence and model credentials separate—both are required for a full start on this path. Before upgrades, cold-back up .env, Compose, the release image list, and the three volumes; restore only onto matching digests and empty verification volumes.
The full Chinese step-by-step guide (Compose + host Caddy HTTPS, login, backups, routine scheduling notes) is here: https://9012938178391.gumroad.com/l/igtblm
