Docker¶
The deployment uses two images, started together with Docker Compose:
| Container | Responsibility | Persistent files |
|---|---|---|
octomate |
Server, agents, channel connections and storage; includes Git, Node.js and the locked Claude/Codex executables | state/ and agent-home/ |
trunkline |
Web UI and Nginx proxy to the server | None |
Your browser and native clients use the same host address. Trunkline forwards API, OAuth, hook and MCP requests to Octomate over the Compose network, including streaming responses and WebSocket connections. Only Trunkline publishes a host port; the server's port stays internal. The web container has no credentials or database mounts.
Deployment support
Windows users: Docker is the recommended deployment path. Sorry, we don't have a native Windows installer yet. Use the PowerShell setup below with Docker Desktop running Linux containers.
The interactive wizard runs on macOS and Linux. The Windows Docker steps have not been tested end to end; macOS native setup remains the only flow tested end to end with live agents.
1. Prepare the deployment¶
macOS and Linux: use the wizard¶
On the host, install Git, uv and a running Docker engine with Compose 2.24.0 or newer. Node.js and the agent executables are built into the image, so they do not need installing on the host for driven sessions.
Choose a new directory, port, Claude or Codex, and Trunkline. The wizard builds both images, runs the configuration generator in a temporary server container, and checks the result. It does not start Octomate, create a database or copy host credentials. Select Claude or Codex for this image. DSH needs a custom image with its executable; add it to the configuration after preparation.
For a version that has not shipped yet, run from your development checkout:
Choose an installation outside that checkout. The prepared layout is:
<installation>/
app/ source used to build both images
compose.yaml two services, host port and persistent mounts
state/
config/ seven YAML configuration files
.env generated salts; optional source of runtime variables
CONFIGURATION.md configuration checklist
octomate.db created later, during database initialisation
.octomate/ working data and project workspaces
agent-home/ persistent container home, including agent logins
logs/prepare.log image build and configuration output
Run the remaining commands from the installation directory. The generated
Compose file builds and runs the server account with your host UID/GID so its
private bind mounts stay writable.
It maps state/ to /data and agent-home/ to /home/octomate. Moving the setup
to another host may require updating the UID/GID build arguments, user: and
directory ownership, then rebuilding the image.
Windows: use Docker Compose¶
Install Git and Docker Desktop for Windows, checking its Windows edition and virtualization requirements. Start Docker Desktop in Linux-container mode, then use PowerShell. Python, Node.js and the agent executables run inside the containers.
The native octomate service init wizard does not run on Windows yet. Use the
same configuration generator inside the server container instead:
git clone https://github.com/kalynnka/octomate.git octomate-server
Set-Location octomate-server
New-Item -ItemType Directory state, agent-home
docker compose build
docker compose run --rm octomate python -m octomate_cli.deployment prepare --target docker --port 8000 --agent codex --channel trunkline
Use a checkout that includes the deployment files described here. Replace
--agent codex with --agent claude, or repeat the option for both.
These commands prepare a new installation; they do not create a database or
start the server. The generator refuses to overwrite existing configuration.
For this path, docker-compose.yml, state/ and agent-home/ live directly in
the checkout rather than in the wizard's separate installation directory. Keep
both data directories when updating or replacing the checkout. Leave the supplied
container UID/GID at 1000:1000; Windows accounts do not use Unix UIDs.
Continue below from this PowerShell directory: review configuration, authenticate
agents inside Docker, then initialise the database and start both containers.
Use docker compose logs to inspect startup and verify a real agent reply before
relying on unattended operation.
2. Review configuration¶
Complete state/CONFIGURATION.md. Review the settings and
tentacles, using the
packaged YAML templates as a reference.
Leave the server's tentacles.trunkline.static_dir unset. The separate Trunkline
container serves the compiled UI; its API remains part of the Octomate server.
For an installation prepared before this split, remove an existing
static_dir: /app/trunkline/dist entry when switching to the new images. Update
its Compose file with the separate trunkline service and move the host port
mapping there, preserving your paths, port and server UID/GID. Rerunning
init --prepare validates an existing installation; it does not rewrite it.
The server listens on 0.0.0.0:8000 inside the Compose network. Trunkline
listens on port 8080 in its container; Compose publishes that as
127.0.0.1:<your-port> on the host. Use this host address for browser access,
native clients and OAuth callbacks. Set auth.cookie_secure: false in state/config/auth.yaml
for the initial local HTTP session.
Provide Octomate secrets in YAML or container environment variables. Compose
also loads state/.env if present; you can use another env_file or your own
environment injection. Host shell variables are not automatically forwarded.
YAML values take precedence, so remove matching placeholders when using environment
variables. See Compose environment files.
3. Authenticate the agents¶
Log in inside the container, using its persistent home. A login on your
laptop does not automatically authenticate the container. Rebuilding or replacing
the container preserves agent-home/; deleting that directory removes the
stored logins.
Claude¶
docker compose run --rm octomate claude auth login
docker compose run --rm octomate claude auth status
Follow the printed browser instructions. On Linux, Claude stores its login under
~/.claude/, which maps to agent-home/.claude/ here. On macOS, credentials may
live in Keychain, so copying ~/.claude alone may not transfer a working login.
See Claude authentication.
For unattended authentication, explicitly provide ANTHROPIC_API_KEY or a
CLAUDE_CODE_OAUTH_TOKEN generated with claude setup-token in the container's
environment. These are Claude runtime variables, not fields in Octomate's YAML.
Keep them out of the Dockerfile and image build arguments. API-key usage follows
the provider's API billing; it does not reuse a subscription login.
Codex¶
docker compose run --rm octomate codex -c 'cli_auth_credentials_store="file"' login --device-auth
docker compose run --rm octomate codex login status
Complete the device-code flow in your browser. It may need enabling in your
account or workspace settings. The file-backed cache lives in
agent-home/.codex/auth.json. See Codex authentication.
If you already have a file-backed auth.json, you may copy it into that location
yourself. Keep it private and writable by the container user so refreshed tokens
can be saved. An OS keyring login cannot be transferred by copying an absent or
stale file. A separate container login avoids sharing a refreshable credential
file with another running agent.
For API-key login, pass OPENAI_API_KEY into a one-off container and use stdin:
docker compose run --rm -e OPENAI_API_KEY octomate sh -c 'printenv OPENAI_API_KEY | codex login --with-api-key'
Set the variable through your preferred secret source first; do not paste its value into the command. This saves the login in the persistent Codex home.
Repository access¶
Model login and Git authentication are separate. Private repositories need credentials available inside the container as well. Configure a dedicated Git credential or narrowly scoped SSH mount yourself; the image does not mount your host's SSH directory or Docker socket. Project paths refer to container paths.
4. Initialise the database and start¶
Confirm that /data/octomate.db maps to this installation's
state/octomate.db. These commands write that database; use them for a new
installation. Back up existing data before applying migrations.
docker compose run --rm octomate alembic -c /app/octomate/migrations/alembic.ini upgrade head
docker compose run --rm octomate alembic -c /app/octomate/migrations/alembic.ini current
docker compose up -d
docker compose logs --tail 100 octomate trunkline
Startup does not apply migrations. Create an invitation, substituting your host port if different; this command writes the invitation to the same database:
Open the registration link, register and sign in. Follow
Accounts and tokens for client credentials.
Send a simple request to each selected agent through Trunkline, then repeat after
docker compose restart and confirm that history remains.
5. Operate the service¶
| Task | Command |
|---|---|
| Status | docker compose ps |
| Follow logs | docker compose logs -f octomate |
| Follow web/proxy logs | docker compose logs -f trunkline |
| Restart | docker compose restart octomate |
| Stop | docker compose stop octomate |
| Rebuild after an intentional source update | docker compose build |
| Recreate with the new image | docker compose up -d |
To update only the UI, run docker compose build trunkline, then
docker compose up -d --no-deps trunkline. The server and its agent processes
keep running. Restarting or rebuilding either container preserves the host's
state/ and agent-home/ directories.
Before an upgrade, stop the service and back up state/ together with
agent-home/. Preserve the database, auth salts and OAuth key together. Review
the release's migrations before recreating the service; rebuilding alone does
not update the schema. See Upgrades and backups.
Use Tailscale or another private connection for remote access. Public internet exposure is not recommended, even with Octomate login. Connect native agents using the client quick start; their hooks run on the machine where the native session lives.