Fixing Stale Coolify Deployments Caused by Orphaned Containers

I ran into an intermittent deployment problem with a Next.js application on Coolify v4. Most requests reached the current deployment, while occasional refreshes returned a version of the site from several months earlier.

What I ruled out

Caching was the obvious suspect. I disabled the relevant Cloudflare caching, but old responses continued to appear.

I then deleted the project in Coolify, recreated the application, restored its settings, and deployed it again. The stale version still appeared. Rebuilding the application configuration had no effect because the process serving the old site lived outside that configuration.

Changing the application's exposed port stopped the stale responses. That narrowed the problem to another process bound to the original port.

Finding the orphaned containers

I connected to the Coolify server over SSH and listed every Docker container:

docker ps -a

Several containers from seven months earlier were still running on the original port. They no longer appeared in the Coolify dashboard, but Docker had kept them alive.

Coolify uses Traefik as its reverse proxy. Both the current application and the old containers were available as routing targets, so requests could reach either version. That explained why the problem looked random and survived a complete project recreation.

Removing the stale containers

After confirming the container names and images, I removed the obsolete group:

docker ps -a --filter "name=oldcontainerprefix" -q | xargs -r docker rm -f

Use a filter specific to the obsolete deployment and inspect the output of docker ps -a before running the removal command. Removing the wrong container can interrupt another application.

Once the old containers were gone, Traefik routed every request to the current deployment.

Diagnostic sequence

For intermittent stale responses in Coolify, inspect the layers in this order:

• Verify CDN and browser caching.
• Change the exposed port temporarily. If the problem disappears, inspect what uses the old port.
• Run docker ps -a on the host instead of relying only on the Coolify dashboard.
• Compare container names, ages, images, labels, and published ports before removing anything.

The important clue was the port change. It turned a vague caching problem into a concrete host-level conflict.