Summary
Following COOLIFY_ENVIRONMENT_GUIDE.md produces an instance that starts (8/8 containers healthy) but is unusable: the libSQL database is never migrated, so sign-in fails with LibsqlError on the user table.
The root cause is that coolify-deployment.yaml does not include a db-migrate service, unlike docker-compose-lightweight.yaml which does. And the image that service relies on is not publicly available, so there is no documented way to run the migrations manually.
Steps to reproduce
- In Coolify, create a Docker Compose service and import
coolify-deployment.yaml as instructed by the guide
- Set the required variables from the guide (
DATABASE_URL=http://libsql:8080, DATABASE_AUTH_TOKEN=, AUTH_SECRET, NEXT_PUBLIC_URL, SELF_HOST=true, RESEND_API_KEY)
- Deploy, then open the dashboard and attempt to sign in
Expected
The database schema is created and sign-in works.
Actual
All 8 containers report healthy, the dashboard renders its sign-in page, but authentication fails:
[auth][error] AdapterError
[auth][cause]: Error: Failed query: select "id", "tenant_id", ... from "user" where "user"."email" = ?
"name": "LibsqlError"
The database is empty — confirmed directly against libSQL:
curl -X POST http://libsql:8080/v2/pipeline \
-H "Content-Type: application/json" \
-d '{"requests":[{"type":"execute","stmt":{"sql":"SELECT name FROM sqlite_master WHERE type=\"table\""}},{"type":"close"}]}'
# => "rows": []Attempts to run the migration image manually all fail:
docker pull openstatus/db-migrate:latest
# => pull access denied, repository does not exist or may require 'docker login'
docker pull ghcr.io/openstatushq/openstatus-db-migrate:latest
# => error from registry: denied
The server and workflows images are distroless (no shell), and no migration files could be found inside any running container, so there is no in-place workaround either.
Suggested fix
Either add a db-migrate service to coolify-deployment.yaml (as in docker-compose-lightweight.yaml) and publish the image, or document how to run migrations against a self-hosted libSQL instance.
Two other issues found along the way
1. workflows requires GCP, though the guide lists it as optional. The container crash-loops on startup without GCP_PROJECT_ID and GCP_LOCATION, because it initialises a Cloud Tasks client eagerly:
TypeError: render fails for not matching
at PathTemplate.render (google-gax/build/src/pathTemplate.js:124:27)
at CloudTasksClient.queuePath (@google-cloud/tasks/build/esm/src/v2/cloud_tasks_client.js:1243:53)
Since the five remaining services depends_on it, the whole stack stays in Created. Setting dummy values unblocks startup, but it is unclear whether scheduled checks work without a real Cloud Tasks queue — worth clarifying in the guide.
2. Env validation requires SaaS-only variables. dashboard and status-page both refuse to boot with Invalid environment variables unless these are set, even with SELF_HOST=true:
STRIPE_SECRET_KEY, PROJECT_ID_VERCEL, TEAM_ID_VERCEL, VERCEL_AUTH_BEARER_TOKEN, UNKEY_API_ID, UNKEY_TOKEN, TINY_BIRD_API_KEY
None of these are relevant to a self-hosted instance, and none are mentioned in the guide. Making them optional when SELF_HOST=true would remove a fair amount of friction.
Environment
- Coolify 4.1.2, Ubuntu 24.04, Docker 29.7.1
coolify-deployment.yaml from main, imported as documented- All images pulled at their
latest tag
Summary
Following
COOLIFY_ENVIRONMENT_GUIDE.mdproduces an instance that starts (8/8 containers healthy) but is unusable: the libSQL database is never migrated, so sign-in fails withLibsqlErroron theusertable.The root cause is that
coolify-deployment.yamldoes not include adb-migrateservice, unlikedocker-compose-lightweight.yamlwhich does. And the image that service relies on is not publicly available, so there is no documented way to run the migrations manually.Steps to reproduce
coolify-deployment.yamlas instructed by the guideDATABASE_URL=http://libsql:8080,DATABASE_AUTH_TOKEN=,AUTH_SECRET,NEXT_PUBLIC_URL,SELF_HOST=true,RESEND_API_KEY)Expected
The database schema is created and sign-in works.
Actual
All 8 containers report healthy, the dashboard renders its sign-in page, but authentication fails:
The database is empty — confirmed directly against libSQL:
Attempts to run the migration image manually all fail:
The
serverandworkflowsimages are distroless (no shell), and no migration files could be found inside any running container, so there is no in-place workaround either.Suggested fix
Either add a
db-migrateservice tocoolify-deployment.yaml(as indocker-compose-lightweight.yaml) and publish the image, or document how to run migrations against a self-hosted libSQL instance.Two other issues found along the way
1.
workflowsrequires GCP, though the guide lists it as optional. The container crash-loops on startup withoutGCP_PROJECT_IDandGCP_LOCATION, because it initialises a Cloud Tasks client eagerly:Since the five remaining services
depends_onit, the whole stack stays inCreated. Setting dummy values unblocks startup, but it is unclear whether scheduled checks work without a real Cloud Tasks queue — worth clarifying in the guide.2. Env validation requires SaaS-only variables.
dashboardandstatus-pageboth refuse to boot withInvalid environment variablesunless these are set, even withSELF_HOST=true:STRIPE_SECRET_KEY,PROJECT_ID_VERCEL,TEAM_ID_VERCEL,VERCEL_AUTH_BEARER_TOKEN,UNKEY_API_ID,UNKEY_TOKEN,TINY_BIRD_API_KEYNone of these are relevant to a self-hosted instance, and none are mentioned in the guide. Making them optional when
SELF_HOST=truewould remove a fair amount of friction.Environment
coolify-deployment.yamlfrommain, imported as documentedlatesttag