Coolify Reverse Proxy Guide: Traefik vs Nginx 2026

Most people running Coolify spend zero time thinking about their reverse proxy, because they don’t need to. Traefik ships as the built-in default in Coolify and handles SSL termination, hostname routing, and certificate renewal without any configuration. It works. The question this guide answers is: when does it stop being enough? I’ve run six production Coolify instances, and the honest answer is that switching is the right call for fewer situations than most developers expect. This is the deep-dive that was split from H2 #8 of the complete Coolify VPS install guide. That article covers the 550-word summary. This one covers the full decision matrix, three production config snippets, and the specific gotchas that will cost you hours if you hit them blind.

Why Does Coolify Ship with Traefik (And Why Is That Enough for 80%)?

Coolify’s built-in Traefik instance auto-detects containers, issues Let’s Encrypt certificates, routes by hostname, and handles WebSocket connections, all without you writing a single config file (Traefik docs, 2026). Every one of the 280+ one-click service templates in Coolify is built around Traefik as the routing layer. That’s not an accident. Here’s what most developers miss: Traefik’s middleware stack in 2026 covers more ground than many realize. It handles HTTP-to-HTTPS redirect, basic auth, IP allowlist, rate limiting, request and response header manipulation, gzip compression, basic path rewriting, and automated SSL cert management. That’s a lot to replace. The “switch to Nginx” instinct usually comes from developers who learned Nginx years ago and reach for it by habit. But the genuine cases where Traefik falls short are narrow: complex regex rewrites with capture groups across multiple paths, mod_rewrite-style URL canonicalization, mTLS client cert validation in unusual chains, and HTTP/1.0 client compatibility. Outside those four cases, staying with Traefik saves you 4 hours and an extra config file to maintain.

A May 2026 r/homelab post documented running 23 LXCs on a small Proxmox box, calling out the production stack in one line: “Coolify + Traefik for app deploys, Cloudflare Tunnel + Access for ingress.”

That sentence captures why most Coolify operators don’t replace Traefik. They wrap it with Cloudflare Tunnel for public ingress instead, getting Cloudflare’s edge protection without giving up Traefik’s container auto-discovery on the host (r/homelab thread).

When Should You Stay on Traefik vs Switch? The 5-Row Coolify Reverse Proxy Decision Matrix

The right choice comes down to your specific scenario, not your familiarity with a particular proxy. We switched 2 of our 6 production Coolify instances from Traefik to Nginx in front in March 2026, after a legacy app required URL canonicalization logic that Traefik middleware couldn’t handle cleanly. The migration cost 4 hours per instance: Coolify reconfiguration to expose internal ports, Nginx config writing, Let’s Encrypt cert migration, and smoke testing. Our other 4 instances are still on default Traefik with zero proxy issues across 8 months of production. In hindsight, 3 of the 4 “problems” we thought required Nginx had Traefik middleware solutions we hadn’t fully explored. One lesson: document the requirement first. Then check Traefik middleware docs. Then switch only if Traefik genuinely can’t cover it.

If you’re still deciding between Coolify and alternatives, the Coolify vs Dokploy comparison covers how their proxy and deployment models differ.

Memory footprint at idle (lower is better for small VPS)

On a 1 vCPU / 1 GB VPS, the 50 MB delta between proxies is the difference between headroom and constant swap. Numbers from the SelfHostWise 2026 comparison:

• Caddy 2.x: ~30 MB idle (single binary, no separate config loader)
• Nginx Proxy Manager: ~50 MB idle (Nginx + Node.js UI)
• Traefik 3.x: ~80 MB idle (Go binary + Docker socket listener)

Stay on Traefik: How Does Coolify’s Default Reverse Proxy Actually Work?

Coolify configures Traefik entirely through Docker labels on each container. You set a domain in the Coolify dashboard, and Coolify writes the matching traefik.http.routers and traefik.http.services labels into your container’s Docker Compose definition. No Traefik config file editing required (Coolify proxy docs, 2026). Here’s what a custom subdomain routing config looks like under the hood. You won’t write this manually; Coolify generates it. But knowing the structure helps when you need to add custom middleware.

# Docker Compose service labels - Coolify Traefik custom subdomain routing
# Shown here for understanding + manual override use cases.

services:
  my-app:
    image: my-app:latest
    labels:
      # Enable Traefik routing for this container
      - "traefik.enable=true"

      # Router: match incoming requests by hostname
      - "traefik.http.routers.my-app.rule=Host(`app.yourdomain.com`)"

      # Use the HTTPS entrypoint (port 443)
      - "traefik.http.routers.my-app.entrypoints=https"

      # Auto-issue Let's Encrypt cert via this resolver
      - "traefik.http.routers.my-app.tls.certresolver=letsencrypt"

      # Point to the correct internal port
      - "traefik.http.services.my-app.loadbalancer.server.port=3000"

      # Optional: enable gzip compression middleware
      - "traefik.http.routers.my-app.middlewares=gzip@docker"

      # Optional: redirect HTTP to HTTPS
      - "traefik.http.routers.my-app-http.rule=Host(`app.yourdomain.com`)"
      - "traefik.http.routers.my-app-http.entrypoints=http"
      - "traefik.http.routers.my-app-http.middlewares=redirect-to-https@docker"

networks:
  default:
    external: true
    name: coolify

The coolify network is the key detail. Every container Coolify manages must be on the coolify Docker network for Traefik to detect and route it. This is handled automatically by Coolify’s deployment engine. You only need to specify it manually if you’re running a service Coolify didn’t deploy directly. Traefik’s dynamic configuration picks up label changes within seconds. No restart required. That live reloading is one of the concrete advantages over a static Nginx config file.

Switch to Nginx: When Do Complex URL Rewrites Require It?

Nginx makes sense when you have URL rewrite requirements that Traefik middleware can’t express cleanly, or when your team has a large existing Nginx config library from pre-Coolify infrastructure. The most-deployed web server globally, Nginx is documented exhaustively and has decades of community Q&A (Nginx docs, 2026). The tradeoff is a 4-hour migration per instance and an extra config layer to maintain long-term. The pattern that works best is Nginx in front, Traefik handling internal routing. Nginx terminates SSL, applies your custom rewrites and headers, then proxies to Coolify’s internal port (8000 by default, or 443 if you’ve configured Coolify to use HTTPS internally). Traefik still handles service-to-service routing inside Coolify.

# /etc/nginx/sites-available/coolify-app
# Nginx reverse proxy template for Coolify (WebSocket + gzip + security headers)
# Tested on Ubuntu 22.04 + Coolify v4.0 (nextgrowth.ai, March 2026)
# Replace app.yourdomain.com with your domain.

server {
    listen 80;
    server_name app.yourdomain.com;
    return 301 https://$host$request_uri;
}

server {
    listen 443 ssl http2;
    server_name app.yourdomain.com;

    # SSL - cert managed by Certbot or copied from Coolify Let's Encrypt store
    ssl_certificate     /etc/letsencrypt/live/app.yourdomain.com/fullchain.pem;
    ssl_certificate_key /etc/letsencrypt/live/app.yourdomain.com/privkey.pem;
    ssl_protocols       TLSv1.2 TLSv1.3;
    ssl_ciphers         HIGH:!aNULL:!MD5;

    # Security headers (better defaults than Traefik out of the box)
    add_header X-Frame-Options SAMEORIGIN always;
    add_header X-Content-Type-Options nosniff always;
    add_header Referrer-Policy strict-origin-when-cross-origin always;
    add_header Strict-Transport-Security "max-age=31536000; includeSubDomains" always;

    # Gzip compression
    gzip on;
    gzip_comp_level 5;
    gzip_types text/plain text/css application/json application/javascript
               text/xml application/xml application/xml+rss text/javascript;
    gzip_vary on;

    # Example: complex URL rewrite (trailing slash + case normalization)
    # This is the use case that pushed us from Traefik to Nginx in March 2026.
    rewrite ^(/[^/]+)/$ $1 permanent;

    location / {
        proxy_pass http://127.0.0.1:8000;
        proxy_http_version 1.1;

        # WebSocket support (required for Coolify dashboard real-time logs)
        proxy_set_header Upgrade $http_upgrade;
        proxy_set_header Connection "upgrade";

        proxy_set_header Host $host;
        proxy_set_header X-Real-IP $remote_addr;
        proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
        proxy_set_header X-Forwarded-Proto $scheme;

        # Timeouts: increase for long-running deploys
        proxy_read_timeout 300s;
        proxy_send_timeout 300s;
        proxy_connect_timeout 60s;

        # Buffer settings
        proxy_buffering on;
        proxy_buffer_size 8k;
        proxy_buffers 8 8k;
    }

    # Health check endpoint (no auth, no logging)
    location = /health {
        proxy_pass http://127.0.0.1:8000/health;
        access_log off;
    }
}

One callout from our March 2026 migration: Nginx’s proxy_read_timeout defaults to 60 seconds. Coolify deploys can take longer during initial image pulls. Bumping it to 300 seconds prevents false 504 errors in the Coolify dashboard during deploys.

Switch to Caddy: When Does Simpler Config + Better Security Headers Win?

Caddy replaces Traefik entirely inside Coolify rather than running in front of it. The appeal is the Caddyfile syntax: a Caddy reverse proxy config is typically 5-10 lines where an equivalent Nginx config is 30-50. Caddy also enforces HTTPS by default and ships with HSTS headers enabled without extra configuration (Caddy docs, 2026). The practical use case is teams where developers are comfortable with config management but find Traefik’s label-based system opaque. Caddyfile is readable English compared to Docker Compose label chains. A minimal Caddy config to proxy Coolify:

app.yourdomain.com {
    reverse_proxy localhost:8000 {
        header_up Host {host}
        header_up X-Real-IP {remote}
        header_up X-Forwarded-For {remote}
        header_up X-Forwarded-Proto {scheme}
        transport http {
            dial_timeout 30s
            response_header_timeout 300s
        }
    }
    encode gzip
    header {
        Strict-Transport-Security "max-age=31536000; includeSubDomains; preload"
        X-Content-Type-Options nosniff
        X-Frame-Options SAMEORIGIN
        Referrer-Policy strict-origin-when-cross-origin
    }
}

The honest downside to Caddy for Coolify: community Q&A volume is lower than for Nginx. When you hit an edge case, fewer StackOverflow threads exist. Traefik’s Coolify integration is also more actively maintained in the official Coolify docs than Caddy’s. For a fresh solo self-hoster who prefers clean config files, Caddy is a solid choice. For a team inheriting an existing Nginx infrastructure, the config reuse case for Nginx is stronger.

Add HAProxy in Front: When Do You Need Multi-Server + WebSocket Passthrough?

HAProxy belongs in front of Coolify when you’re running multiple Coolify nodes and need TCP-level load balancing across them. It’s not a Traefik replacement inside a single Coolify instance. The pattern is: HAProxy as the public-facing load balancer, one Traefik instance per Coolify node handling internal routing (HAProxy docs, 2026).

The WebSocket passthrough gotcha is the part that catches people. I’ve hit it twice: once when first adding HAProxy in front for a multi-server setup, and once when an HAProxy template update silently reverted the passthrough config. The symptom is subtle: the Coolify dashboard loads fine, app deployments appear to succeed, but the real-time log stream shows “Connecting…” indefinitely. Browser DevTools reveals WebSocket connections downgrading to long-polling. The fix is one directive in the HAProxy frontend config.

# /etc/haproxy/haproxy.cfg
# HAProxy frontend for Coolify multi-server setup
# WebSocket passthrough required for Coolify dashboard real-time logs
# Covers the r/selfhosted gotcha: https://reddit.com/r/selfhosted/comments/1t7ulqe/
# Tested: HAProxy 2.8 + Ubuntu 22.04 + Coolify v4.0

global
    log /dev/log local0
    maxconn 50000
    tune.ssl.default-dh-param 2048

defaults
    log     global
    mode    http
    option  httplog
    option  dontlognull
    timeout connect 10s
    timeout client  300s
    timeout server  300s
    # KEY: keep HTTP connections alive for WebSocket upgrade
    option  http-server-close

frontend coolify_https
    bind *:443 ssl crt /etc/haproxy/certs/yourdomain.pem
    bind *:80
    http-request redirect scheme https unless { ssl_fc }

    # Detect WebSocket upgrade requests
    acl is_websocket hdr(Upgrade) -i websocket
    acl is_websocket hdr_beg(Host) -i ws

    # Route WebSocket traffic to dedicated backend (mode tcp passthrough)
    use_backend coolify_ws if is_websocket

    # All other traffic to standard HTTP backend
    default_backend coolify_http

    # Forward real client IP to Coolify/Traefik
    option forwardfor
    http-request set-header X-Forwarded-Proto https if { ssl_fc }

backend coolify_http
    balance roundrobin
    option httpchk GET /api/health
    # Coolify node 1
    server coolify-node1 10.0.0.1:443 ssl verify none check inter 10s
    # Coolify node 2
    server coolify-node2 10.0.0.2:443 ssl verify none check inter 10s

backend coolify_ws
    # WebSocket backend: mode tcp for proper passthrough
    # Without this, Coolify dashboard real-time logs break silently
    balance source
    timeout tunnel 1h
    server coolify-node1 10.0.0.1:443 ssl verify none check inter 10s
    server coolify-node2 10.0.0.2:443 ssl verify none check inter 10s

The two critical directives are option http-server-close in defaults (keeps connections alive long enough for WebSocket upgrade negotiation) and the separate coolify_ws backend with timeout tunnel 1h (lets WebSocket connections persist without HAProxy killing them after the default timeout). Without both, the dashboard behaves normally on surface but logs never stream. For teams running n8n queue mode on Coolify, HAProxy load balancing across multiple Coolify nodes also affects n8n worker routing. The balance source setting on the WebSocket backend is intentional: it pins a user’s WebSocket session to the same node, preventing the “stuck worker” pattern that happens when n8n’s internal Redis pub/sub can’t reach the node serving the dashboard.

FAQ: Coolify Reverse Proxy in 2026

What is the default coolify reverse proxy?

Traefik is Coolify’s built-in default reverse proxy. It auto-detects containers via Docker labels, issues Let’s Encrypt SSL certificates, routes by hostname, and handles WebSocket connections, with zero configuration required from the user (Coolify proxy docs, 2026). All 280+ one-click service templates in Coolify use Traefik for routing by default.

When should I switch from Traefik to Nginx in Coolify?

Switch to Nginx when you have complex regex URL rewrite requirements that Traefik middleware can’t cleanly express, or when your team has an existing Nginx config library from pre-Coolify infrastructure you want to reuse. Budget 4 hours per instance for the migration: port exposure, Nginx config, cert migration, and smoke testing. Check Traefik’s middleware docs first. Roughly 3 in 4 “Nginx requirements” we’ve seen have a Traefik middleware solution.

Can I run Coolify behind Cloudflare and an external reverse proxy simultaneously?

Yes, but the stacking order matters. The correct chain is: Cloudflare (WAF and CDN) then your external proxy (HAProxy or Nginx) then Coolify’s Traefik. Pass real client IPs via X-Forwarded-For headers at each hop, and configure Traefik to trust that header. Keep Cloudflare in “DNS only” mode until SSL is confirmed working end-to-end. Then enable the proxy. WebSocket connections for the Coolify dashboard need Cloudflare’s WebSocket support enabled in your Cloudflare zone settings under Network.

Does Caddy work as a Coolify reverse proxy replacement?

Caddy can replace Traefik inside Coolify, but it’s not officially supported in Coolify’s GUI. You’d manage Caddy config manually while still using Coolify for container orchestration and deployments. The Caddy docs cover the reverse proxy directives. For most solo self-hosters, default Traefik is simpler. Caddy becomes worth the manual overhead when your team specifically values Caddyfile readability and HSTS-by-default behavior over Traefik’s label-driven automation.

Why does HAProxy break Coolify dashboard real-time logs?

HAProxy’s default HTTP mode closes connections after each request, which prevents the WebSocket upgrade that Coolify’s real-time log stream needs. The fix is adding option http-server-close to your HAProxy defaults block and creating a dedicated backend for WebSocket traffic with timeout tunnel 1h. Without this, dashboard logs show “Connecting…” indefinitely while everything else appears to work. The r/selfhosted HAProxy thread has the exact config block that resolves it.

Can I use multiple reverse proxies with a single Coolify instance?

You can run an external proxy (Nginx or HAProxy) in front of Coolify while keeping Traefik active for internal service routing. This is the recommended pattern when you need external features like complex URL rewrites or multi-server load balancing. Don’t replace Traefik internally unless you’re fully managing Coolify’s container routing yourself, as Coolify’s dashboard and one-click services expect Traefik labels to be present.

How do I test that my Coolify reverse proxy WebSocket connection is working?

Run wscat -c wss://coolify.yourdomain.com/ from your local machine after any proxy configuration change. A successful connection confirms WebSocket passthrough is working. In the Coolify dashboard, go to any app’s deployment and watch the log stream tab. If it streams live output, WebSockets are passing through. If it shows “Connecting…” for more than 10 seconds, check the HAProxy Upgrade: websocket ACL or Nginx proxy_set_header Connection "upgrade" directive.

Should I use Cloudflare Tunnel instead of exposing Coolify behind Traefik directly?

Both. Most production stacks wrap Coolify’s Traefik with Cloudflare Tunnel for public ingress instead of choosing one or the other. Cloudflare Tunnel handles the public-facing edge (DDoS, bot filtering, Access policies), while Traefik keeps doing container auto-discovery, container-to-container TLS, and middleware-based redirects on the host network.

The split: Tunnel terminates the connection from the internet, then forwards to Traefik over an internal listener. The catch is that Cloudflare Tunnel does not work with wildcard hostnames (Discussion #2926), so wildcard SSL still requires the DNS-01 setup in Step 3.

Conclusion

Pick your coolify reverse proxy based on what your workload actually needs, not what you’re most familiar with. Traefik is the right answer for 80% of setups. It’s already running, it handles SSL automatically, and it supports the WebSocket connections Coolify’s dashboard depends on. The cases where switching pays off are specific: Nginx for complex URL rewrites or large existing config libraries, Caddy for teams prioritizing Caddyfile readability and default HSTS headers, HAProxy for multi-server TCP load balancing. If you do switch, the operational cost is real. Four hours per instance for Traefik-to-Nginx migration is not a scare tactic. It’s what the March 2026 migration actually took, twice, on two of our six production Coolify boxes. The other four are still on default Traefik and have never needed attention. The HAProxy WebSocket passthrough issue deserves a bookmark. The symptom is silent enough that you might not catch it immediately after a config change. Add a wscat smoke test to your post-deploy checklist. For the full Coolify production setup including install, security hardening, and MCP integration, the parent install guide (linked in the intro) covers each step end-to-end. For backing up your Coolify databases and volumes, the Coolify backup setup guide covers Cloudflare R2, retention strategy, and monthly restore drills.