Self-hosted troubleshooting
Use this page if you followed Self-hosted Rejourney and something fails or behaves oddly. Commands are run from the repository root (where docker-compose.selfhosted.yml lives).
Start Here
Pick the symptom that best matches what you are seeing.
| Symptom | First place to look |
|---|---|
| Install exits during bootstrap | Install or update fails before or during bootstrap |
| Dashboard opens, but recordings are empty | Sessions are counted but Replay stays empty |
| Dashboard loads, but requests fail | Dashboard loads, but auth or API calls fail |
| Browser SDK says config is forbidden | Web SDK config returns 403 |
| HTTPS does not issue | TLS or certificate issues |
| S3 credentials work locally, but uploads fail | External S3 works in CLI, but Rejourney cannot upload |
90-second triage
-
./scripts/selfhosted/deploy.sh statusshows API and upload relay running. - DNS for dashboard, API, ingest, and www points at this server.
-
.env.selfhostedis the original file for this deployment. -
PUBLIC_API_URLandPUBLIC_INGEST_URLuse the public HTTPS hosts. - If using the Web SDK, the app origin is in Web allowed domains.
- If using external S3, the
ingest-uploadcontainer can reach the S3 endpoint.
Fast Checks
Service status
./scripts/selfhosted/deploy.sh statusAPI logs
./scripts/selfhosted/deploy.sh logs apiUpload relay logs
./scripts/selfhosted/deploy.sh logs ingest-uploadWorker logs
./scripts/selfhosted/deploy.sh logs ingest-worker
./scripts/selfhosted/deploy.sh logs retention-worker
./scripts/selfhosted/deploy.sh logs alert-worker1. Install or update fails before or during bootstrap
Symptoms
bootstrapexits non-zero- app services never become healthy
statusshows API or workers waiting on bootstrap- install or update exits with
Database authentication failed before bootstrap.
Checks
docker compose -f docker-compose.selfhosted.yml --env-file .env.selfhosted logs bootstrapCommon causes:
- bad
DATABASE_URL - credentials mismatch (e.g. from an earlier failed deployment)
- missing
STORAGE_ENCRYPTION_KEY - invalid S3 credentials
- broken external S3 endpoint URL
- on ARM64, missing image support (set
DOCKER_DEFAULT_PLATFORM=linux/amd64or use./scripts/selfhosted/deploy.sh, which sets it when unset)
Recovery:
- If you still have the original
.env.selfhosted, restore it and run:
./scripts/selfhosted/deploy.sh update- If you do not need old data, wipe and reinstall:
./scripts/selfhosted/deploy.sh reset
./scripts/selfhosted/deploy.sh installSchema / migration messages: On a normal install, the database starts empty and bootstrap sets everything up. If you restored Postgres from a backup into a new server but migration metadata is missing, or you pointed the stack at the wrong database, bootstrap may exit with an error about an inconsistent database instead of overwriting your data. Unless you are doing advanced recovery, fix DATABASE_URL and restore a consistent backup, or start from a clean volume. For deliberate migrate-only recovery, some setups use REJOURNEY_ALLOW_ORPHAN_DB_MIGRATE_ONLY=1 in .env.selfhosted (see maintainer docs or support before using this).
Fix
- If you have the original
.env.selfhosted, restore it and rerun:
./scripts/selfhosted/deploy.sh update- If you do not have the original
.env.selfhosted, wipe and reinstall:
./scripts/selfhosted/deploy.sh reset
./scripts/selfhosted/deploy.sh installupdate reruns schema, seed, and storage-endpoint sync. reset removes self-hosted containers and data volumes so a fresh install can generate new credentials safely.
2. Sessions are counted but Replay stays empty
What this usually means now
With the current architecture, this is usually one of two things:
ingest-uploadcould not store the artifact bytesingest-workercould not process an uploaded artifact
The device no longer uploads directly to MinIO/S3, so bucket reachability from the phone is no longer the main suspect.
Checks
./scripts/selfhosted/deploy.sh logs ingest-upload
./scripts/selfhosted/deploy.sh logs ingest-worker
./scripts/selfhosted/deploy.sh logs apiLook for:
artifact.upload_receivedartifact.upload_storedartifact.retryartifact.failedsession.reconciledsession.finalized
Common causes
- wrong S3 credentials in
.env.selfhosted - external S3 bucket missing
- external S3 endpoint unreachable from Docker network
- upload relay unhealthy
- worker stuck retrying failed artifacts
Fix
- verify
S3_*values - if you changed storage config, rerun:
./scripts/selfhosted/deploy.sh update3. Dashboard loads, but auth or API calls fail
Checks
- dashboard host DNS points to the server
- API host DNS points to the server
- ingest host DNS points to the server
- ports
80and443are open - Let's Encrypt has issued certificates
Inspect:
./scripts/selfhosted/deploy.sh logs traefik
./scripts/selfhosted/deploy.sh logs api4. Web SDK config returns 403
The Web SDK enforces the project's allowed browser origins before it returns configuration or accepts ingest.
Checks:
- The app's browser origin is listed in the project's Web allowed domains.
- Include the host and port for local or staging apps, for example
localhost:3100. PUBLIC_API_URLpoints at the public API host that browsers can reach.PUBLIC_INGEST_URLpoints at the public ingest upload relay host that browsers can reach.
After changing domain or ingest values in .env.selfhosted, rerun:
./scripts/selfhosted/deploy.sh update5. TLS or certificate issues
Traefik manages certificates automatically.
Checks
dig example.com
dig api.example.com
dig ingest.example.com
dig www.example.comMake sure all names resolve to the server running the stack.
If DNS was wrong during first install, fix DNS and rerun:
./scripts/selfhosted/deploy.sh update6. External S3 works in CLI, but Rejourney cannot upload
Remember the upload path is server-side.
The important network path is:
ingest-uploadcontainer -> your S3 endpoint
Test from the server by reviewing relay logs and confirming the endpoint/bucket/keys in .env.selfhosted.
If you changed them, rerun:
./scripts/selfhosted/deploy.sh update7. Built-in MinIO install, but artifacts still fail
Checks
./scripts/selfhosted/deploy.sh logs minio
./scripts/selfhosted/deploy.sh logs minio-setupThe minio-setup one-shot should create the bucket named by S3_BUCKET.
If you changed the bucket name after first install, run:
./scripts/selfhosted/deploy.sh update8. Billing pages show disabled billing
That is expected unless Stripe keys are configured.
The stack no longer disables billing because it is "self-hosted". It disables billing because Stripe is unconfigured.
If you do not set Stripe keys:
- billing UI stays in the self-hosted/unlimited state
- Stripe checkout and webhooks stay disabled
9. Storage endpoint in Postgres is wrong after changing .env.selfhosted
Run:
./scripts/selfhosted/deploy.sh updateThe update path reruns bootstrap and resyncs the active storage_endpoints row.
10. Need to stop services without losing data
Use:
./scripts/selfhosted/deploy.sh stopThis stops containers only. It does not remove volumes.
11. Need deeper logs for one service
./scripts/selfhosted/deploy.sh logs api
./scripts/selfhosted/deploy.sh logs ingest-upload
./scripts/selfhosted/deploy.sh logs ingest-worker
./scripts/selfhosted/deploy.sh logs web