Troubleshooting

The failures that come up most often, in the order you are likely to meet them. Each one starts with what to check first.

A domain’s SSL stays PENDING

• DNS has not propagated — wait, then click Verify now in the Records tab.
• The A record points at the wrong address — fix it at your registrar.
• Ports 80 and 443 are closed on the server — check the firewall. Let’s Encrypt has to reach the server to validate the domain.

The application is RUNNING but the URL does not answer

• No domain is attached — Applications → the application → Domains → attach.
• The reverse proxy is out of sync — Domains → Sync reverse proxy.
• The port is wrong. The application must listen on the port configured on it, inside the container — and on 0.0.0.0, not 127.0.0.1. An application bound to localhost is unreachable from outside its own container.

Services on a remote server cannot reach each other

The project network requires an up-to-date agent. The agent is a standalone binary, not a Git checkout, so updating it means re-running its installer: Servers → your server → Install command, pasted over SSH. It downloads the latest binary and restarts the service.

curl -fsSL '<api>/api/agent/install.sh?token=…' | sh

Then confirm both services are in the same project — the network does not span projects. See service networking.

After a move, the data is still on the old server

• Volumes transfer asynchronously during a move. If the transfer setup failed, the applications were deployed with empty volumes and a warning was raised — check the migration warnings on the project.
• Source volumes are preserved on the old server. The move itself never purges anything.
• The reliable recovery is a backup taken on the old server and restored on the new one.

I switched to Local mode and my applications vanished

They are still running on the remote servers — Local mode simply hides them. Switch back to multi-server to see them again, or move them onto this server first. Nothing was deleted. See deployment modes.

The build fails on a monorepo

Almost always the build context. A COPY pnpm-lock.yaml in a sub-folder’s Dockerfile fails when the context is that sub-folder, because the lockfile sits above it. DockBoard detects workspaces and builds from the repository root automatically; when the detection is wrong, set it explicitly — applications, monorepos.

The full build log is on the deployment — open it from the deployment history.

Still stuck

• Read the deployment’s build log first — most failures say exactly what happened.
• Check the audit trail: it records who changed what, and when, which often explains a change in behaviour nobody remembers making.
• Check quotas — a project at its ceiling refuses new work rather than degrading quietly.