"Deployment: Docker, Compose, Coolify, CI (SSOT)"

Deployment: Docker, Compose, Coolify, CI (SSOT)

Single navigation hub for container images, Compose files, hosted deploy (Coolify), CI checks, and how they relate to mens and mobile/edge (which are not the same shape as a Linux OCI image).

Compose profiles (which file when)

ProfilePurposeCompose / templateDefault image / buildPorts (typical)
MCP single-nodeRun vox mcp with API keys + optional Codex (Turso)Repo root docker-compose.ymlRoot Dockerfile (CMD vox mcp)3000
MCP + mens (multi-service)Control plane + MCP + worker; shared registry volumeexamples/mens-compose.ymlSame Dockerfile with build-arg VOX_CLI_FEATURES=mens,script-execution9847 (mens), 3000 (MCP)
Codex API (BaaS template)Self-hosted Codex-style HTTP API on Turso (placeholder service name)infra/coolify/docker-compose.ymlVOX_CODEX_IMAGE (you build/push); not the default vox MCP image unless you retag/repurpose8080 (template)
Generated app stackvox deploy / vox-container sample (Node + nginx + optional mens env)Emitted by generate_compose_fileProject Dockerfile from @environment / package flow3000 + 80/443

Do not assume root docker-compose.yml and infra/coolify/docker-compose.yml are interchangeable: they target different workloads (MCP vs Codex API template). See Codex BaaS and infra/coolify/README.md.

Optional split-plane sidecar: run vox-orchestrator-d alongside vox-mcp and set VOX_ORCHESTRATOR_DAEMON_SOCKET on MCP to the daemon TCP endpoint. Use VOX_MCP_ORCHESTRATOR_RPC_READS=1 / VOX_MCP_ORCHESTRATOR_RPC_WRITES=1 only when both services share the same repo/db context and startup probe confirms matching repository_id.

OCI image (repo Dockerfile)

Environment SSOT (Compose-friendly)

Runtimes: Docker vs Podman

  • CLI / deploy: vox-container implements ContainerRuntime for Docker and Podman; Compose execution prefers podman-compose then docker compose (deploy_target.rs).
  • CI: GitHub self-hosted jobs use Docker (see workflow enumeration). Validate Podman locally for rootless/volume/DNS differences before claiming parity.

Coolify

CI (GitHub & GitLab)

  • GitHub: docker compose … config on the mens example + docker build default and mens feature matrix — .github/workflows/ci.yml.
  • GitLab: see workflow enumeration for parity jobs (compose config + optional image smoke).

Do’s and don’ts (short)

  • Do keep variable names identical to env-vars SSOT / mens / ADR 004.
  • Do use persistent volumes for /root/.vox (or documented VOX_DB_PATH) in production Compose.
  • Don’t embed secrets in committed defaults; use substitution + CI/secret stores.
  • Don’t document “run the MCP Dockerfile on mobile”; use mobile-edge SSOT profiles and mens HTTP from the app.

Remote mobile operations boundary

When teams need phone-based project management:

  • Run Vox services on a remote host (Docker/Compose, VM, or bare-metal).
  • Expose a hardened network control plane for bounded operations from mobile clients.
  • Front the optional MCP HTTP gateway with a trusted reverse proxy and TLS termination; keep vox-mcp itself private-bind where possible.
  • For strict proxy signaling, pair VOX_MCP_HTTP_REQUIRE_FORWARDED_HTTPS=1 with a proxy-set X-Forwarded-Proto: https; only trust forwarded client IPs when ingress is fully controlled.
  • Keep repository/toolchain state on the host; mobile clients should not be expected to run Cargo/git/vox locally.

See MCP HTTP gateway contract, Crate API: vox-mcp, and env vars SSOT for the complete control-plane policy surface.

This deployment SSOT remains about server/container runtime surfaces; it does not redefine phones as first-class OCI runtime hosts.