Production boot checks
The configuration problems that make the application refuse to start in production, and how to fix each one.
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.