How to Get Near Zero-Downtime Deployments on Coolify in 2026

Coolify can perform rolling deployments, but that does not automatically mean every deployment is invisible to your visitors. If the replacement container receives traffic before it is actually ready, you can still see 502 errors, 503 responses, or the familiar “no available server” message during a release.

This guide shows a practical way to reduce that deployment gap: first by giving Coolify a trustworthy readiness signal, then by making sure your container can coexist with the old version, and finally by tightening the Traefik behavior that handles the brief handoff between containers.

Why you can still see errors while Coolify is “rolling” a deployment

The key distinction is running versus ready. Docker can report that a container has started even though the application inside it is still loading configuration, warming caches, connecting to a database, running migrations, importing dependencies, or starting its HTTP listener.

If the proxy begins sending requests to that replacement container during this warm-up period, users can hit a process that is technically alive but cannot answer yet. That is why a deployment can look normal inside Coolify while visitors briefly receive a 502 or 503 from the proxy.

A 502 Bad Gateway generally points to a proxy that knows about a backend but cannot successfully connect to it. A 503 / no available server more often means Traefik currently has no healthy backend available for that route. Those two symptoms look similar to a visitor, but they suggest different failure points.

Measure the deployment from outside the server

Before changing your configuration, create a simple external probe. Run it from your laptop, another VPS, a monitoring box, or any machine that reaches the application through the same public domain your users use.

Testing from inside the Coolify server can hide routing problems because you may bypass DNS, TLS, Traefik, or the exact public network path. For deployment testing, the outside view is the one that matters.

import time
import urllib.request
import urllib.error
from datetime import datetime, timezone

URL = "https://app.example.com/health"
INTERVAL = 0.10

def stamp():
    return datetime.now(timezone.utc).isoformat(timespec="milliseconds")

while True:
    started = time.perf_counter()
    status = "ERR"
    body = ""

    try:
        with urllib.request.urlopen(URL, timeout=2) as response:
            status = str(response.status)
            body = response.read(200).decode("utf-8", "replace")
    except urllib.error.HTTPError as exc:
        status = str(exc.code)
        body = exc.read(200).decode("utf-8", "replace")
    except Exception as exc:
        body = type(exc).__name__

    latency = (time.perf_counter() - started) * 1000
    print(f"{stamp()}  {status:>4}  {latency:7.1f}ms  {body[:80]}")

    elapsed = time.perf_counter() - started
    time.sleep(max(0, INTERVAL - elapsed))

Start the probe, deploy a small application update, and then look for non-200 responses. Repeat the same test several times. One deployment is not enough to tell you whether a result is consistent.

Establish a baseline before you touch the configuration

Deploy your current application with the probe running. Write down four things: how many requests failed, which status codes appeared, how long the error window lasted, and whether the new version actually became live.

This matters because an incorrectly configured health check can create a misleading result: the site stays online because Coolify keeps the old container, but the new deployment is rejected. From a visitor’s perspective there is no downtime, yet from a release perspective the deployment failed.

The four conditions that make Coolify rolling updates practical

For an application-level rolling replacement to work, the old and new application instances must be able to exist at the same time. That leads to four important configuration rules.

Step 1: add a health check that tests real readiness

The easiest mistake is to create an endpoint that always returns 200. That proves only that a tiny piece of code can respond. It does not necessarily prove that your application can use the database, read the required configuration, or serve the operations your users need.

A better readiness endpoint checks the minimum dependencies required for safe traffic. Keep it fast: a health endpoint should not run an expensive report or a large SQL query on every probe.

Example: Dockerfile health check for a Node, Python, or similar HTTP app

FROM python:3.12-slim

RUN apt-get update \
    && apt-get install -y --no-install-recommends curl \
    && rm -rf /var/lib/apt/lists/*

WORKDIR /app
COPY . .

EXPOSE 3000

HEALTHCHECK --interval=5s --timeout=3s --retries=3 \
  CMD curl -fsS http://127.0.0.1:3000/health || exit 1

CMD ["python", "app.py"]

If your image does not include curl or wget, the health check can fail forever even when the application itself is healthy. Verify the command manually inside the running container.

curl -i http://127.0.0.1:3000/health

The response should become 200 only when the service is actually ready for real user requests.

Why a default health check can accidentally block every deployment

Imagine your application normally needs 12 to 18 seconds to boot. If the health check begins too early and Docker counts those expected startup failures against the retry limit, the container can be marked unhealthy before startup has finished. Coolify may then keep the old version and reject the new one.

That behavior is safer than replacing a healthy release with a broken one, but it means your health-check timing must reflect the real boot profile of your application.

Step 2: tune start-period to match your application

Docker’s start-period gives the new container a grace window during startup. Failed checks inside that early window do not immediately condemn a container that simply needs more time.

HEALTHCHECK \
  --interval=2s \
  --timeout=3s \
  --retries=3 \
  --start-period=25s \
  CMD curl -fsS http://127.0.0.1:3000/health || exit 1

Do not blindly copy 25 seconds. Measure your own worst normal startup time and give yourself reasonable headroom. If an application usually needs 8 seconds, a 15-second start period may be enough. If it performs initialization that can take 40 seconds, a 10-second grace period is obviously too short.

After saving the Dockerfile, deploy again with the external probe running. You should see the old instance remain available until the replacement reports healthy.

Step 3: make graceful shutdown part of the deployment

Readiness solves the start side of the handoff. Graceful shutdown solves the stop side.

When Coolify asks the old container to terminate, your application should stop accepting new work, finish or safely abandon in-flight requests, close connections, and exit inside the configured grace period. If it disappears immediately, a request that was already being served can still be cut off.

Also think about release compatibility. During a rolling deployment, old and new code can run at the same time. Database migrations should therefore be backward compatible during that overlap. A migration that instantly removes a column still required by the old version can create failures even if your container handoff is perfect.

Step 4: reduce the last proxy handoff gap with Traefik

After a good readiness check, you may still observe an occasional failed request right as the old container disappears. Reverse proxies update their backend view very quickly, but there can still be a tiny interval where a request chooses a backend that has just gone away.

A retry middleware can help when the failure occurs at the connection layer. Instead of immediately returning an error to the visitor, Traefik can retry against another available backend.

Part A: add a retry middleware to the application router

In Coolify, open your application and inspect the generated Traefik labels under the advanced/container-label settings. Router names vary between applications, so do not paste a router name from someone else’s server without checking yours.

traefik.http.middlewares.app-retry.retry.attempts=3
traefik.http.middlewares.app-retry.retry.initialinterval=100ms

# Example only — replace YOUR_ROUTER with the router name Coolify generated.
traefik.http.routers.YOUR_ROUTER.middlewares=gzip,app-retry

Part B: use a shorter backend dial timeout

Retry logic cannot help quickly if the proxy spends a long time trying to connect to a backend that no longer exists. Traefik’s ServersTransport settings let you define the backend dial behavior. A short dial timeout can make a dead-target failure surface quickly enough for a retry to reach the healthy replacement.

In Coolify’s proxy dynamic configuration area, create a dynamic YAML file. Use a unique name so it is obvious what the file controls.

http:
  serversTransports:
    app-fast-dial:
      forwardingTimeouts:
        dialTimeout: "1s"

Then connect the application’s Traefik service to that transport. Again, the exact generated service name is unique to your resource.

traefik.http.services.YOUR_SERVICE.loadbalancer.serverstransport=app-fast-dial@file

Once the retry and transport settings are in place, run your external probe through multiple deployments again. The result you care about is not whether the Coolify dashboard says “deployed”. It is whether real public requests stay successful through the transition.

Put all of your test results in one table

Instead of relying on memory, compare each configuration side by side. Your numbers will differ from another server because boot time, image size, CPU, storage, network performance, application framework, and migrations all change the timing.

A result worth trusting

Run at least three deployments after every meaningful change. For a high-traffic or business-critical application, test more aggressively: multiple endpoints, concurrent requests, authenticated traffic, slow requests, file uploads, API calls, and any route where losing an in-flight request would be expensive.

Zero downtime is not just a reverse-proxy setting. It is a property of the whole release path: readiness, routing, graceful termination, shared state, schema compatibility, external dependencies, and how the application behaves while two versions briefly coexist.

The Docker Compose limitation: what to do instead

If your application lives inside a Docker Compose resource, do not assume that adding a health check turns it into Coolify’s application-level rolling replacement. Compose is orchestrated differently.

For a blog, internal tool, automation platform, or third-party stack that is updated occasionally, the simplest answer may be to schedule updates during a quiet period. A short planned interruption can be easier to operate than a complicated custom deployment system.

For your own application, split the frequently deployed web service

A practical architecture is to keep slow-changing infrastructure such as PostgreSQL, Redis, and other supporting services in a Compose stack, while deploying the web/API application as its own Coolify Application resource.

Coolify Project
│
├── Infrastructure (Docker Compose)
│   ├── PostgreSQL
│   ├── Redis
│   └── Worker dependency
│
└── Web Application (Dockerfile Application)
    ├── health endpoint
    ├── rolling replacement
    ├── Traefik domain
    └── frequent code deployments

This keeps the part you deploy every day on the deployment path that can overlap old and new containers, without forcing your database to be recreated every time you ship a frontend or API change.

Frequently asked questions

Related self-hosting guides

Technical note: deployment behavior changes over time. Re-check the current Coolify and Traefik documentation before applying production proxy changes, especially after a major Coolify upgrade.