Deployment

Deployment

Production uses deploy/docker-compose.production.yml to run PostgreSQL, MongoDB, the Node API, Python AI service, Caddy, and a private update agent. Only Caddy publishes ports 80 and 443; internal services use the Compose network.

Bootstrap a VPS

git clone https://github.com/adm73/OpenBcon.git /opt/openbcon
cd /opt/openbcon
./deploy/deploy.sh --setup

The setup script starts a temporary setup page on port 8090 and prints its one-time URL. Complete it to create deploy/.env.production; the script then creates needed Test/Live databases, validates Caddy, builds services, and waits for health checks. The setup page expires and should not remain publicly open.

For later deploys, run:

./deploy/deploy.sh

Before going live

• Point the domain's DNS record at the VPS and set DOMAIN in the production environment file.
• Keep deploy/.env.production out of Git and use strong, unique database, MongoDB, encryption, and update-agent secrets.
• Set production origins and server-side provider credentials; do not seed demo data in production.
• Ensure persistent backups for PostgreSQL and MongoDB, and test restoring them.
• Confirm HTTPS and https://YOUR_DOMAIN/api/health work after deployment.
• Keep Python, PostgreSQL, MongoDB, and the update agent private.

Operations

Always pass the production environment file when using Compose directly:

docker compose --env-file deploy/.env.production \
  -f deploy/docker-compose.production.yml ps
docker compose --env-file deploy/.env.production \
  -f deploy/docker-compose.production.yml logs --tail=200 api

Do not run docker compose down --volumes on a production deployment unless you intentionally want to delete all persistent application data. Admin Console updates use a private, token-protected agent and preserve database volumes.