Docker operations
You can run Pulse in Docker with the published image or by building from local source. Use Docker when you want a repeatable runtime and persistent /data volume.
Published image vs build from source
| Path | Use it when |
|---|
| Published image | You want the released runtime from ghcr.io/oktolabsai/okto-pulse:latest. |
| Build from source | You are testing local changes across okto-pulse and okto-pulse-core. |
Volume strategy
Persist /data. It holds SQLite, uploads, board graphs, global discovery, and MCP traces.
docker run --rm -p 8100:8100 -p 8101:8101 -v okto-pulse-data:/data ghcr.io/oktolabsai/okto-pulse:latest
Listening on 0.0.0.0:8100 and 0.0.0.0:8101
Environment variable overrides for production
Inside containers, bind both API and MCP to all interfaces:
HOST=0.0.0.0
MCP_HOST=0.0.0.0
DATA_DIR=/data
KG_BASE_DIR=/data
HF_HOME=/opt/hf-cache
Multi-container setups
The community image defaults to local SQLite and embedded LadybugDB files. If you move supporting services out of the container, keep Pulse single-process for the API/UI and MCP servers so shared state and the embedded graph writer stay coherent.
Logs and debugging
okto-pulse | API/UI listening on 8100
okto-pulse | MCP listening on 8101
Upgrading
For minor releases, pull the new image and restart against the same volume. Check the upgrade guide when a release notes a schema migration.
Related pages
Last modified on May 8, 2026
