Common issues

Start with the symptom. Most problems here are one of about ten things.

The app deployed but the URL doesn't respond#

Nearly always one of two causes, and the deploy succeeds either way because nothing probes your app.

1. It's listening on 127.0.0.1. That's reachable only from inside the container. Bind 0.0.0.0.
2. The port doesn't match. The container port you bound must be the port your app actually listens on.

EXPOSE in a Dockerfile doesn't publish anything — the Ports panel does.

To check from inside, open the app's Shell and request it locally. If that works and the public URL doesn't, it's the bind address or the port; if it fails there too, your app isn't serving.

The app keeps restarting#

Look at the Events view for the exit code:

Stop the app while you investigate. Logs rotate, so a fast loop scrolls its own cause out of retention — and for a Discord bot, each restart that reaches the gateway consumes a daily connection allowance with a harsh penalty for exhausting it.

If it restarts on a regular schedule — every few days, always after similar uptime — that's a memory leak meeting the hard RAM cap rather than a crash.

The logs are empty#

Output buffering, not a platform problem. Runtimes buffer stdout when it isn't a terminal, so output sits unwritten until the buffer fills — and is lost if the process crashes first.

Python: set PYTHONUNBUFFERED=1. Others have an equivalent.

Data disappeared#

It was written outside a volume. The container's filesystem is discarded whenever the container is recreated — on every deploy and every configuration change.

There's no error when this happens; your app just creates an empty database or upload directory and carries on.

All my apps stopped at once#

Two causes, both account-wide:

• Total volume size exceeded your disk limit. Nothing starts until it drops back below. Free space by pruning, or ask support to raise the limit.
• Your balance ran out. Top up and start them again.

Both send a notification, in the panel and by email.

My first app stopped shortly after starting#

On a new account, the first app you deploy gets a short trial run so you can see it build, start and work. That is the end of the trial run, not a crash. Add credit and start the app again to run it continuously. Configuration and volumes are preserved.

The build fails#

• Stops part-way with no clear error — out of memory. The builder has less memory than your app does. Build in CI and push the image, or make the build lighter.
• "No Dockerfile found in the root of the pushed branch" — it's in a subfolder or named something else. It must be Dockerfile, at the root.
• "You have just pushed to not tracked branch" — push to deploy or build.
• shallow update not allowed — your CI checkout is shallow. Fetch full history.

The frontend calls undefined/api/...#

A build-time variable that wasn't set during the build. The build receives no environment variables and no build arguments, so NEXT_PUBLIC_*, VITE_* and similar are inlined as empty.

Build in CI where you can supply them, or read the value at runtime. See Configuration.

Can't connect to my database#

• Use the address from the database app's Ports panel. TCP bindings get a generated high port, not 5432 or 3306. There is no internal hostname — see Databases.
• Check the port is still bound. If you unbound it, nothing external can reach it.
• Confirm the credentials match what the database container was created with. For images that initialise credentials on first start, changing the variables later has no effect on an existing volume.

Certificate errors from my own app#

Your app is trying to obtain its own certificate. TLS is terminated at the edge, so your app should serve plain HTTP on the bound port.

This is common with Caddy-based servers — disable automatic HTTPS, usually by setting the server name to a bare port.

Changing CPU or RAM did nothing#

Quota changes apply when the container is next created. Restart the app.

Still stuck#

Collect the app ID, the exit code from Events, and the last few dozen log lines before the failure, then contact support. Those three things answer most questions immediately.