Skip to content
Latchkey

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.

prisma output
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.

Terminal
# wait until Postgres answers, then migrate
until pg_isready -h "$DB_HOST" -p "$DB_PORT"; do sleep 1; done
npx prisma migrate deploy

Use a service healthcheck in the workflow

GitHub Actions can hold the job until the service container is healthy, eliminating the race.

.github/workflows/ci.yml
services:
  db:
    image: postgres:16
    options: >-
      --health-cmd "pg_isready -U postgres"
      --health-interval 5s --health-retries 10

Verify host and port

  1. Confirm DATABASE_URL points at the host the runner can actually reach (service name vs localhost).
  2. Make sure the database port is exposed/mapped on the runner network.
  3. 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_URL host/port in sync with the CI network topology.

Frequently asked questions

Is P1001 ever a credentials problem?
No. P1001 is purely reachability - Prisma never got far enough to authenticate. Wrong credentials surface as a different error (P1000) after the connection succeeds.

Related guides

Tired of flaky CI? Latchkey auto-heals failed jobs and retries them for you. Start free →