How to Deploy OTserver With Docker Compose
Prerequisites
Install Docker Engine with Compose. Use long random, URL-safe database credentials and a separate long random OTSERVER_SECRET; keep the environment file out of source control. Put TLS in a reverse proxy in front of OTserver and do not expose MongoDB outside its Docker network.
Local development
Clone the OTserver manager repository, including the pinned Otter contract submodule, and run the following commands from its root:
| |
For an existing checkout, run git submodule update --init --recursive before building.
The repository’s docker-compose.yml bind-mounts the source, installs dependencies, runs pnpm dev, and publishes MongoDB on port 27017. Use it only as a local quick start:
| |
Open http://localhost:3000/admin to create the first administrator account.
Production example with MongoDB
The repository’s multi-stage Dockerfile builds the standalone application and runs it as an unprivileged user. From the repository root, save this as compose.production.yml:
| |
Create .env.production with no quotes and URL-safe values so the MongoDB connection string remains valid:
| |
Protect the file and start the stack:
| |
This compact example uses the MongoDB bootstrap administrator for the application. Create a dedicated least-privilege MongoDB user and update DATABASE_URL where your security policy requires separate database administration credentials.
Proxy HTTPS traffic to 127.0.0.1:3000. Keep a new instance private until you open /admin and create the first account, which receives the protected Admin role. Then create the site hierarchy that will receive discovery imports.
Back up both the mongo-data and import-files volumes. Pin and test MongoDB and OTserver upgrades rather than changing image versions during an unplanned restart.
Update an existing production deployment
Back up MongoDB and the uploaded import files, then check out the OTserver release tag or commit you have tested. From the same repository directory, update its pinned submodule and rebuild only the application:
| |
Keep the same Compose project name, production environment file, and volumes so the replacement container uses the existing inventory and import files. Do not use down -v during an upgrade: it deletes the named volumes. After restarting, sign in and verify the inventory and a small import. If rollback is needed, rebuild the previous tested revision; restore the matching database and import-file backup if the upgrade changed stored data incompatibly.
Import configuration
Import an authorized scanner export through Imports → Create New, or configure the scanner’s direct upload with the destination URL, site document ID, and a user API key with read/write access to that site.
Verify the result
Sign in at /admin, confirm that the expected site exists, and create a small authorized import before planning a plant-wide rollout. The import result shows created, updated, skipped, unresolved, and warning counts.