Troubleshooting
Diagnose common startup and configuration failures on a self-hosted stack.
Most self-hosting problems surface at startup. Start by looking at the service state and logs:
cd ~/sdp
docker compose ps
docker compose logs -f sdp-apiDocker is not ready
The install script checks for Docker up front. If you see that Docker is not installed, that Compose v2 is unavailable, or that the daemon is unreachable, install or start Docker and retry — see the Docker Engine and Compose docs.
A required variable is missing
compose.yml fails fast when a required variable is unset, with a message such
as set POSTGRES_PASSWORD in .env. Make sure a .env exists next to
compose.yml and fills in every required variable. The
configurator produces a complete file; the
environment reference lists what is required.
Images won't pull
If docker compose pull reports access denied or a missing manifest:
- Confirm
SDP_IMAGE_REGISTRYandSDP_VERSIONpoint at a registry and tag you can reach. - Pull a single image directly to see the underlying error, e.g.
docker pull ghcr.io/solana-foundation/sdp/sdp-api:latest. - If the registry is private, run
docker loginfor it first.
Port already in use
The API, web, and docs default to ports 8787, 3000, and 3001. If another
process holds one of them, the service won't bind. Override the host port in
.env with SDP_API_PORT, SDP_WEB_PORT, or SDP_DOCS_PORT and run
docker compose up -d again.
Migrations failed
sdp-migrate runs once before the API starts; if it fails, the API stays down.
Inspect it with:
docker compose logs sdp-migrateA failure here is usually a database connection problem — check POSTGRES_* (or
DATABASE_URL) and that the postgres service is healthy in docker compose ps.
Database connection refused
The API and migration services wait for Postgres to report healthy before
starting. If they still can't connect, verify the credentials in .env, and for
an external database (DATABASE_URL set) that it is reachable from inside the
Docker network.
Authentication errors in the dashboard
Sign-in problems point at the Clerk configuration. Re-check
NEXT_PUBLIC_CLERK_PUBLISHABLE_KEY, CLERK_SECRET_KEY, and CLERK_ISSUER
against your Clerk application, and confirm the keys match the environment
(development vs production) you intend to run.
Still stuck?
Capture the failing service's logs and your (secret-redacted) .env settings,
then open an issue on the
project repository.