Docker production deployment

docker-compose.yml defines a self-hosted application and PostgreSQL stack. The official staging and production services use Azure App Service through .github/workflows/build.yaml; this page covers the supplied compose file.

Before you startCopy Anchor Link

Choose a host with Docker Compose, persistent storage and an HTTPS entry point. The compose file uses a named postgres_data volume for the database and an uploads_data volume for local files. It maps the application's port 3000 to APP_PORT, which defaults to 3000. Only PostgreSQL has a compose health check; /api/health is an application endpoint that you can monitor separately.

Configure the stackCopy Anchor Link

Supply POSTGRES_DB, POSTGRES_USER and POSTGRES_PASSWORD for the database, and NEXTAUTH_SECRET and NEXTAUTH_URL for authentication. The compose defaults for the database are tea, tea_user and tea_password; replace the password for a real deployment. Compose builds DATABASE_URL from those values and uses the internal host name postgres.

USE_LOCAL_STORAGE defaults to true; uploads are stored in the uploads_data volume, mounted at /app/uploads (UPLOADS_DIR's default inside the container). The compose file shows Azure Blob storage variables as commented alternatives. The authentication configuration reads GitHub and Google client variables; the compose file currently passes GitHub client values but does not pass Google client values. OAuth token storage also reads TOKEN_ENCRYPTION_KEY, a base64 encoding of 32 bytes, which the compose file does not pass. If you enable those integrations, add the required variables to your deployment configuration rather than assuming they are already forwarded.

Email uses ACS_CONNECTION_STRING and ACS_SENDER_ADDRESS when configured. The scheduled maintenance routes use CRON_SECRET; the compose file does not pass it. See the deployment overview for the variable list.

Start and updateCopy Anchor Link

After correcting the image reference and supplying the deployment settings, start the stack with the production compose file:

docker compose -f docker-compose.yml up -d

The application waits for the PostgreSQL health check. Its image entrypoint applies pending SQL migrations with prisma migrate deploy and then starts server.js. Check the application logs and /api/health after startup. Do not run a separate manual migration inside tea_app as a routine step.

When updating, take a database backup first, then pull the intended image and recreate the application. The image path and tag in your deployment configuration determine which build you receive. The database guide covers backup and restore.