Production boot checks

The configuration problems that make the application refuse to start in production, and how to fix each one.

For: Administrators troubleshooting a deployment that will not start · Last updated

When the app container starts with WI_ENV=prod (which the compose file sets), it checks its own configuration before it serves anything. If any check fails, it stops with the message Refusing to boot with invalid configuration: followed by every problem it found. The container then restarts and fails again until you fix .env.

Read the message with:

sudo docker compose -p wi-prod logs app

What it checks#

Problem reported What to do
WI_MASTER_KEY is unset Provide the master key in .env. If this is an existing deployment, restore the original value. See Master key custody. This check applies in every environment.
WI_PUBLIC_BASE_URL is unset The compose file sets it from WI_ALLOWED_ORIGIN. Set WI_ALLOWED_ORIGIN in .env.
WI_API_BASE_URL is unset The compose file sets it from WI_ALLOWED_ORIGIN. If you see this, the stack is running from an older compose file: re-run install.sh to replace it.
WI_ALLOWED_ORIGIN is unset Add WI_ALLOWED_ORIGIN=<your origin> to .env. Without it, the browser origin checks would reject every real client.

The production checks also reject test-only settings: the fake drivers for inference, infrastructure, deployment, updates, email, trigger scheduling, and crawling, and the ephemeral identity signing mode. The compose file does not select any of them, so you meet these checks only if you add such a variable to .env. Remove it.

Compose's own checks#

Docker Compose also refuses to start the stack, before any container runs, when WI_MASTER_KEY, WI_SESSION_SECRET, WI_ALLOWED_ORIGIN, or WI_DOKKU_SSH_HOST is missing. The error names the variable. The usual cause is running docker compose from a directory that does not contain .env, or a .env that lacks the line.

See Configuration reference for every value.