Skip to content
Pipebase

Troubleshooting

Designer returns 503

Section titled “Designer returns 503”

Cause — almost always Traefik returns 503 because the designer container is restarting (deploy in progress, OOM kill, crashed boot).

Diagnose:

Terminal window
ssh <host> 'docker ps -a --format "{{.Names}}\t{{.Status}}" | grep pipebase-designer'
ssh <host> 'docker logs --tail 100 $(docker ps --format "{{.Names}}" | grep pipebase-designer)'

If the container is Restarting, look at the last lines of the log for the boot error. Common ones:

  • PIPEBASE_DEPLOY_TOKEN must be set — missing env var. Coolify env config drifted.
  • EADDRINUSE :::3000 — leftover bind from a partial deploy. Kill orphan containers.

Flow stuck “Deploying…”

Section titled “Flow stuck “Deploying…””

Diagnose:

Terminal window
ssh <host> 'docker logs --tail 200 $(docker ps --format "{{.Names}}" | grep pipebase-runtime) 2>&1 | grep -i "PUT\|error\|<flow-id>"'

The runtime logs every PUT /_api/flows/:id plus its outcome. If you don’t see your flow id, the designer never reached the runtime — check PIPEBASE_RUNTIME_URL and the deploy token.

If the runtime logs an error parsing the YAML, the deploy was rejected (400). The designer should surface the error in a toast; if it doesn’t, that’s a designer bug — file an issue with the toast text.

”Failed to obtain certificate” (Let’s Encrypt)

Section titled “”Failed to obtain certificate” (Let’s Encrypt)”

See TLS. Almost always:

  • DNS hasn’t propagated, OR
  • Port 80 isn’t reachable from the public internet, OR
  • Let’s Encrypt rate-limited you (5 failed validations / hour / hostname)

Runtime container restarts in a loop

Section titled “Runtime container restarts in a loop”

Cause — usually one bad YAML in /opt/pipebase/routes/ that fails to parse + crashes startup.

Pre-805c243 runtime: that bug existed and required SSH cleanup. Post-805c243 runtime (everything ≥ v0.4): fail-soft is in place — a bad YAML logs a WARN and the rest of the routes load fine. If you’re seeing crash loops on a recent runtime, the problem is somewhere else (OOM, port conflict). Check docker inspect exit code.

Coolify deploy fails with “exit status 1” / “failed to compute checksum”

Section titled “Coolify deploy fails with “exit status 1” / “failed to compute checksum””

The pnpm/Java build inside the Dockerfile produced no output. Usually because:

  • A pnpm --filter @pipebase/<name> ran but no package matched (the catastrophic version of the rebrand bug)
  • A tsc --noEmit failed inside the build stage and the && chain short-circuited

Look at the [stdout] lines in the Coolify deploy log right before the error — the actual TS / pnpm complaint is in there. The trailing “failed to execute bake” message is just the orchestrator’s wrapper.

Cookbook to inspect a failed Coolify deploy:

Terminal window
ssh <host> 'docker exec coolify-db psql -U coolify -d coolify -tAc "SELECT logs FROM application_deployment_queues WHERE id=<deploy-id>;"' \
  > /tmp/deploy.log
python -c "
import json
with open('/tmp/deploy.log') as f: data = f.read()
for x in json.loads(data):
    print('[' + (x.get('type') or '?')[:6] + ']', (x.get('output') or '').rstrip()[:200])
"

Traefik routes the wrong container

Section titled “Traefik routes the wrong container”

Symptom: a flow you just deployed via the UI returns 404 from the public URL.

Cause — orphan containers. Coolify leaves the old generation attached to the network during deploys; both register the same Host(...) rule and Traefik load-balances between them.

Fix:

Terminal window
ssh <host> '
for s in pipebase-runtime pipebase-designer pipebase-kafka pipebase-pulsar; do
  keep=$(docker ps --format "{{.Names}} {{.CreatedAt}}" | grep "^$s-" | sort -k2 | tail -1 | cut -d" " -f1)
  for c in $(docker ps --format "{{.Names}}" | grep "^$s-" | grep -v "^$keep$"); do
    echo "stopping orphan $c"; docker stop "$c" && docker rm "$c"
  done
done'

Then redeploy the affected flow.

Still stuck?

Section titled “Still stuck?”

File an issue at https://github.com/jobu279/ipaas/issues/new. Include:

  • Pipebase version (PIPEBASE_VERSION from .env)
  • The exact symptom + what you expected
  • Last 200 lines of the relevant container’s logs
  • docker ps -a output for pipebase-*