Video summary

Zero downtime deployments & high availability setup using Coolify + Hetzner • 2026 Guide

Main summary

Key takeaways

Technology

Overview / Goal

  • Tutorial for zero-downtime deployments and high availability using Coolify plus Hetzner (Hzner) infrastructure.
  • Starts with the problem of single-server bottlenecks (resource limits + single point of failure) and scales the architecture step-by-step:
    1. Separate the database to its own server
    2. Move the application to its own server
    3. Add multi-server high availability behind a load balancer

High Availability Setup (Multi-Server + Load Balancer)

  • Run the app on multiple servers.
  • Use a load balancer in front:
    • Domain points to the load balancer IP
    • Load balancer distributes traffic to app servers
    • It performs continuous health checks and sends traffic only to healthy servers

Optional Extras

  • Add Cloudflare for DDoS protection and caching
  • With Cloudflare proxy enabled, the load balancer and backend servers are hidden behind Cloudflare

Zero-Downtime Deployments Using Coolify (How It Works)

  • Coolify assigns one server as primary and others as additional.
  • For a deployment:
    1. Build on the primary server
    2. Push the built Docker image to a Docker registry
    3. Additional servers pull the image (build happens only once)
    4. Coolify updates additional servers after the primary deployment succeeds

Key “No Downtime” Mechanism During Container Swap

Deployment involves switching from container v1 to container v2, which can otherwise create a short downtime window. The solution relies on:

  • Docker sending SIGTERM with a grace period
  • A custom health check endpoint that flips behavior during shutdown

Custom Health Check / Shutdown Logic (Critical Requirement)

  • The app maintains an internal is_shutting_down flag:
    • Normal state: health check returns HTTP 200
    • After receiving SIGTERM:
      • health check returns HTTP 503
      • the app exits after ~20–25 seconds

Purpose

  • Prevent the load balancer from routing new requests to a server that is shutting down
  • Allow in-flight requests time to finish while the server is marked unhealthy

“Five Rules” to Make Multi-Server Zero Downtime Work

  1. No Docker Compose for multi-server deployments (Coolify limitation)
  2. Build pushes a Docker image to a registry; all app servers must be logged in to pull it
    • Works with DockerHub, GitHub Container Registry, etc.
  3. No volume-based persistent storage in the way required for multi-server setups (Coolify limitation)
  4. Must implement a custom health check endpoint
  5. Domain must be managed by the load balancer provider
    • If using Cloudflare in front, domain managed by Cloudflare + Cloudflare origin certificate configuration required

Example Application + Implementation Details (Next.js + Prisma + Dockerfile)

  • Deploys a full-stack Next.js app with a database.
  • Uses a Dockerfile (since Compose multi-server isn’t supported).
  • Uses Prisma ORM for database access and runs migrations with:
    • prisma migrate deploy

Health Logic in the Next.js App

  • health module + health API route used by the load balancer
  • Health endpoint returns 200 only if DB access works; otherwise 503

Server Behavior

  • Custom server.js handles SIGTERM by:
    • continuing for ~25 seconds while health returns 503
    • then stopping/exiting
  • SIGINT exits immediately

Step-by-Step Infrastructure Provisioning (Hetzner + Coolify)

  • Prepare DNS so the Coolify and app domains resolve correctly:
    • Create DNS zone on Hetzner, update registrar name servers (GoDaddy mentioned)
    • A record for the Coolify subdomain to reach the Coolify dashboard
  • Use private networking (internal-only access):
    • Create Hetzner private network so servers + DB aren’t directly exposed publicly
  • Create a Hetzner load balancer:
    • Configure HTTPS termination at the load balancer
    • Generate SSL certificates on the load balancer
    • Configure health checks (HTTP to backend over private network)
    • Health check settings described as aggressive for the demo (e.g., 3s interval, short timeout)
  • Create application servers (3 app servers + database server mentioned):
    • Firewall restricted to the private network
    • Placement group used to spread across physical hosts
  • Configure SSH keys between Coolify and Hetzner servers
  • Configure Docker registry access:
    • Create DockerHub Personal Access Token with read/write permissions

Deployment Flow (Database + App)

  • Connect servers to Coolify using private IPs.

Deploy Database

  • Uses Coolify one-click Postgres 17
  • Port mapping configured (host port → database port) so app servers can reach DB internally

Deploy App

  • From private GitHub repository via GitHub App integration
  • Build with Dockerfile
  • Push image to DockerHub; additional servers pull and run it

Demo: Verifying Zero Downtime

  • A “tester” monitoring app pings the main site every second and computes success rate based on 200 responses.
  • During Coolify redeploy:
    • One backend server goes down during deployment
    • Still, the tester shows no downtime (requests keep receiving 200)
  • Load balancer + health-check signaling prevent failed traffic routing

Cloudflare in Front of the Load Balancer (DDoS + Caching)

  • Point Cloudflare DNS A record to the load balancer public IP with proxy enabled.
  • Create a Cloudflare Origin Certificate (RSA, long validity like 15 years).
  • Upload the origin certificate + private key to Hetzner load balancer service TLS settings.
  • Ensure Cloudflare encryption mode is Full / Full strict.

Main Speakers / Sources

  • Speaker/host: The video’s primary presenter (includes “I personally use…” and step-by-step tutorial narration).
  • Sponsor/primary external source: Hzner / Hetzner (sponsorship + infrastructure provider used throughout).
  • Product referenced: Coolify (used for multi-server deployments and dashboard orchestration).

Original video