Prisma "P1001: Can't reach database server" in CI
Prisma could not open a connection to the database host before its connect timeout. The migration engine never reached the server - this is a connectivity problem, not a SQL or schema problem.
What this error means
prisma migrate deploy (or migrate dev) aborts immediately with P1001, naming the host and port it tried. It often passes on retry once a service container finishes booting or a network blip clears.
Error: P1001: Can't reach database server at `db`:`5432`
Please make sure your database server is running at `db`:`5432`.Common causes
Database service not ready yet
In CI the database is often a service container that is still starting when the migrate step runs. Prisma connects before Postgres/MySQL is accepting connections and reports P1001.
Transient network blip or DNS hiccup
A brief loss of connectivity, a slow DNS resolution, or a runner network flake can stop the TCP connection from completing inside the connect timeout.
Wrong host, port, or unexposed service
If the host or port in DATABASE_URL is wrong, or the service port is not mapped on the runner network, every attempt fails the same way.
How to fix it
Wait for the database to be ready before migrating
Gate the migrate step on the database actually accepting connections rather than racing it.
# wait until Postgres answers, then migrate
until pg_isready -h "$DB_HOST" -p "$DB_PORT"; do sleep 1; done
npx prisma migrate deployUse a service healthcheck in the workflow
GitHub Actions can hold the job until the service container is healthy, eliminating the race.
services:
db:
image: postgres:16
options: >-
--health-cmd "pg_isready -U postgres"
--health-interval 5s --health-retries 10Verify host and port
- Confirm
DATABASE_URLpoints at the host the runner can actually reach (service name vslocalhost). - Make sure the database port is exposed/mapped on the runner network.
- Retry the job once dependencies are healthy - a clean retry confirms it was transient.
How to prevent it
- Gate migrate steps on a
pg_isready/healthcheck rather than a fixed sleep. - Define service-container healthchecks so the job waits for readiness.
- Keep
DATABASE_URLhost/port in sync with the CI network topology.