This is a third-party deployment note, not official OpenMausBot documentation. It covers the guide’s Path B: a Linux VPS, a domain under your control, Docker Compose, and Caddy for HTTPS.
The useful distinction is between pulling a prepared image and building one with your own configuration. Both use Compose, but they do not produce the same result when ENGINES changes.
Keep the network layout intact
Start with Docker Engine and Compose V2. Point the domain’s A record at the VPS and allow inbound TCP 80 and 443. The hostname entered as DOMAIN must not include https://.
The supplied deployment has an unusual but deliberate layout: Caddy uses network_mode: service:omb, sharing the application’s network namespace. Public port mappings therefore belong to omb, even though Caddy handles HTTPS.
Caddy forwards normal requests to the loopback application listener and /hooks/* to the separate webhook listener. The supplied configuration also disables buffering for event streams.
Never publish 8799/8800 to the internet.
Pulling an image is not configuring its contents
From the repository’s deploy/ directory, copy .env.example to .env and edit the domain and engine selection. The standard prebuilt-image startup is:
docker compose pull omb && docker compose up -d
docker compose ps
The expected state is omb healthy and caddy running. Open the HTTPS domain after Caddy has obtained its certificate. A pairing prompt is expected before login; it does not mean deployment failed.
The concrete pitfall: editing ENGINES in .env does not change an already-pulled image. Those engine command-line packages are baked into the image during its build. Pulling the prebuilt image retrieves whatever its own build included, not a new image tailored to the local .env.
To build with the configured engine list, run this from deploy/:
docker compose up -d --build
The supplied Compose file already defines the build context and passes ENGINES as a build argument. Installing the required command-line packages and logging into their accounts are separate steps: rebuilding handles the former, not the latter.
Choose the image reference deliberately
At the guide’s check time, 2026-11-06, :latest and :v0.1.142 had different index digests. They should not be treated as interchangeable references.
The default Compose image follows :latest. To pin the checked release, change omb.image in docker-compose.yml to ghcr.io/milind-soni/openmausbot:v0.1.142, then run the pull-and-start command above. Pinning an equivalent digest is another option described in the guide. This image-reference choice is separate from building a customized image with ENGINES.
Pair, then preserve the data
After completing the required account login inside the container, generate a pairing link:
docker compose exec omb node dist-server/openmausbot.js pair --label "My MacBook"
Open the returned HTTPS link to connect the browser. Pairing is the login path; codes are single-use and expire after roughly five minutes.
The container uses HOME=/data, backed by the named data volume. Application state and command-line credentials persist there. Before upgrades, back up the actual volume name: changing the Compose project name can change which volume the deployment uses. Stop omb for the guide’s backup procedure, and keep the archive somewhere other than the VPS.
The full Chinese step-by-step guide (Compose + Caddy HTTPS, pairing, backups, ARM notes) is here: https://9012938178391.gumroad.com/l/hkvly
Top comments (1)
The ENGINES trap is the kind of thing that only bites you once, but it bites hard — a rebuild silently ignoring your .env edit is exactly the failure mode that makes people distrust their own deploy. The network_mode: service:omb detail is worth calling out too: it makes the port mapping confusing at first glance, but it's what keeps the webhook listener off the public interface. One addition I'd suggest: a docker compose config diff before and after the rebuild, so you can prove the new image actually carries the engine list you asked for.