Docker in production

Docker runs three production stacks on the Apex server: Jitsi Meet for client video calls during discovery and delivery, PeerTube for internal video hosting, and Mattermost for team communications. All three replace paid SaaS equivalents that would cost $50-$200/month each.

The decision to self-host these services rather than pay for Zoom/Loom/Slack is an instance of the build-don't-rent mandate applied to infrastructure. At single-founder scale, $200-600/month in SaaS is a meaningful operating cost. Self-hosted Docker stacks reduce that to Hetzner compute costs already committed.

Jitsi runs with a custom TURN server configuration to handle clients behind restrictive NATs. The docker-compose stack includes Prosody (XMPP), Jicofo, and JVB. Client calls for discovery sessions and project delivery reviews route through this stack. The average call quality at 1080p is indistinguishable from Zoom for 2-person calls.

Mattermost replaces Slack for any coordination that involves subcontractors or setters. The on-premise data storage means conversation history is not subject to Slack's 90-day free tier limitation.

PeerTube hosts recorded client delivery walkthroughs and internal capability demos. Rather than uploading to Loom or YouTube (which indexes content publicly), recordings go to the self-hosted PeerTube instance with private visibility.

Example workflow: wiring up a local development environment for a client project with multiple services. 1. Write a docker-compose.dev.yml that defines the same service ports as production: ClickHouse on 8123, Redis on 6379, PostgreSQL on 5432. 2. Use named volumes so data persists across container restarts. Never use bind mounts for database data directories; they cause permission issues on Linux. 3. Add a healthcheck to each service definition so docker compose up --wait blocks until ClickHouse and PostgreSQL are accepting connections before the app starts. 4. Set COMPOSE_PROJECT_NAME in the .env file so multiple projects can run simultaneously without port conflicts. 5. Document the exact docker compose up command in the project README, including the --profile flag if optional services (e.g., a mock SMTP server) should be opt-in. 6. Confirm parity with production: if ClickHouse runs version 26.3 in production, pin the exact same image tag in the dev compose file.

For the Avo Engine system itself, Docker is used for local development environments where Rust services need to run alongside ClickHouse, Redis, and PostgreSQL. The docker-compose.dev.yml file brings up all dependencies with a single command, matching the production port layout.