Coolify bad gateway shows up as a wall between you and a working deploy: the build succeeded, the container's running, and the domain still shows 502. Almost every time, it's not the app that's broken, it's Traefik, Coolify's built-in proxy, unable to reach the container it's supposed to be routing to.
This covers the actual fix, not just "check the logs": the Port Exposes setting that causes most 502s, restarting the proxy versus Coolify itself, what "Coolify down" after a reboot usually means, and rolling back a bad deploy.
Quick answer
Jump to a section
Why Coolify shows bad gateway
A bad gateway coolify error means Traefik got a request for your domain, matched it to a container, and then couldn't actually connect to it. That's a routing failure between the proxy and the app, not the app rejecting the request, and it narrows down to a short list of causes: the container crashed or is still starting, the internal port Traefik is trying to hit doesn't match what the app is actually listening on, or the app only accepts connections on localhost instead of all interfaces.
Checking Port Exposes and binding
This is the fix that resolves most 502s, and it's two settings, not one.
Port Exposes, on the application's configuration page, has to equal the port your app process actually binds to inside the container. If your app listens on 3000 and Port Exposes says 8080, Traefik dutifully routes to a port nothing is listening on, and you get a bad gateway that looks like an infrastructure problem but is really a typo.
| Symptom | Likely cause |
|---|---|
| 502 on domain, works on server IP:port directly | Port Exposes mismatch, or a host port mapping bypassing the proxy |
| 502 immediately after deploy, clears after a minute | App still starting, Traefik hit it before the process was ready |
| 502 that never clears | App bound to 127.0.0.1 instead of 0.0.0.0, or the app actually crashed |
If your compose file has its own ports: mapping to the host, remove it. Coolify's proxy is supposed to own routing, and a manual host mapping can conflict with that instead of adding a helpful fallback.
Restarting Coolify and its proxy
"Restart Coolify" means two different things depending on what's actually broken. If one app is misbehaving, restart the proxy from the Coolify dashboard, or directly:
docker restart coolify-proxy
docker logs coolify-proxy --tail 100If Coolify's own dashboard is unresponsive, that's Docker Engine, not the proxy:
sudo systemctl restart docker
docker ps -aCoolify's containers run with a restart-always policy, so once Docker itself is healthy, they come back without you touching anything else.
Coolify down after a reboot
Coolify down after a server restart is almost never Coolify's fault specifically, it's Docker not starting on boot, or starting after something else tried to reach it. Check first:
systemctl is-enabled docker
docker psIf Docker isn't enabled to start on boot, enable it and reboot again. If Docker's running but Coolify's containers aren't in the list, the install may not have completed properly, re-running the official install script is safe, it detects an existing install and brings it back up (updating it in the process) rather than reinstalling from scratch.
Rolling back a bad deploy
Coolify rollback exists, from the application's Deployments tab, and it's worth knowing the actual limitation before you rely on it during an incident: it only rolls back to an image still available locally on the server. If Coolify already pruned the old image to save disk space, or your build pulls fresh from a registry each time, there's no local image left to roll back to, and "rollback" isn't actually an option in that moment.
Plan for this before you need it
Other common Coolify errors
- Build succeeds, deploy hangs indefinitely: usually a health check configured against a path or port the app doesn't actually serve. Check the health check config against what the app really exposes.
- Works right after deploy, breaks after a few minutes: look at container memory limits, an app getting OOM-killed looks like random instability, not an obvious crash.
- SSL certificate errors on a custom domain: confirm DNS actually resolves to the server before troubleshooting Coolify itself, Let's Encrypt can't issue a cert for a domain that isn't pointed at the right IP yet.
If you haven't deployed Coolify itself yet, our Coolify developer guide and single-click AWS setup cover getting it running properly from the start, which avoids a few of these problems entirely.
Frequently Asked Questions
What causes a Coolify bad gateway error?
Traefik, Coolify's proxy, can't reach your app's container. Usually one of three things: the app crashed, the Port Exposes field has the wrong port, or the app is listening on 127.0.0.1 instead of 0.0.0.0 and Traefik can't route to it from outside the container.
How do I fix a coolify 502 bad gateway specifically?
Check Port Exposes on the application first, that field has to match the port your app actually listens on internally. Then confirm the app binds to 0.0.0.0, not localhost. Remove any host port mapping in your compose file too, Coolify's proxy handles routing and a manual port mapping can conflict with it.
How do I restart Coolify?
Docker Engine, not Coolify's UI, is what to restart if the dashboard itself is unresponsive: sudo systemctl restart docker. Coolify's own containers run with a restart-always policy, so they come back on their own once Docker is up. If they don't, re-run the official install script, it detects the existing install and just brings it back up.
What does it mean when Coolify is down after a server reboot?
Almost always Docker Engine didn't come up automatically, or came up after Coolify's containers tried to start. Confirm Docker's own service is set to start on boot (systemctl is-enabled docker), then check docker ps to see whether Coolify's containers are even present before assuming something's actually broken.
Does Coolify support rolling back a deployment?
Yes, from the application's Deployments tab, but with a real limitation: rollback only works against images still available locally on the server. If Coolify already pruned the old image, or you're pulling from a remote registry that's since changed, there's nothing local to roll back to.
Why does my app show bad gateway only through my domain, not the server IP and port?
That's the signature of a proxy routing problem, not an app problem, since the app clearly responds when hit directly. Check the domain field's port matches Port Exposes, and confirm DNS actually points at the server Coolify is running on.
Skip the Self-Managed Headaches
Launch a pre-configured Coolify server on AWS with the proxy and networking already set up correctly from the first deploy.
Get Coolify on AWS Marketplace
