This one caused a long chase through symptoms that all looked unrelated (404, then missing HTTPS) before the real cause turned up. Worth remembering the shape of it.
Postgres only applies POSTGRES_USER / POSTGRES_PASSWORD the first time it initializes an empty data directory.
If you change SERVICE_USER_POSTGRES or SERVICE_PASSWORD_POSTGRES (or the plain env var equivalents) on a service that already has a running Postgres volume, changing the env var does nothing to the actual database - Postgres keeps whatever credentials it was first initialized with, forever, regardless of what the env vars say afterward. The application container then tries to connect with the new credentials against a database that only accepts the old ones, and fails with something like:
error: Database Connection Error: 28P01 undefined:undefined
...
error: Database Initialization Error: password authentication failed for user "yourusername"
This single root cause cascades into several other things that look like separate problems:
Filtering unhealthy or starting container on every cycle - it never gets a stable backend.CN=TRAEFIK DEFAULT CERT), not a real one - see DNS & TLS/dns-tls) for how to check this.So "the site 404s and has no valid HTTPS" can genuinely mean "a database in a completely different part of the stack has stale credentials." Worth checking the app's own container logs early, not just the proxy layer.
1. Stop the service - both the app container and the Postgres container.
2. Delete the Postgres data volume in Coolify's terminal. Get the exact volume name from the service's docker-compose config first - it's namespaced with the project UUID:
docker volume rm <project-uuid>_<service>-postgresql-data
3. Start the service again. Postgres reinitializes fresh, using whatever credentials are in the env vars right now - so this only works cleanly if the env vars are already correct before this step.
4. Redeploy properly if needed. If a simple start doesn't recreate things cleanly, trigger a full redeploy instead - a docker compose up recreate is more reliable than restarting old container definitions after a volume's been removed.
This wipes whatever was in that database. Only safe to do if the app never successfully connected in the first place (so there's no real data to lose) - or if there's a backup. Don't reach for this if the app has been running fine and only the credentials changed recently; that's a different, more careful migration.