Self-Host Coolify on a VPS With Nginx and HTTPS

Coolify is what many teams wish Heroku still felt like: a clean deploy workflow you control. It runs on infrastructure you pay for directly. If you can run Docker on a Linux server, you can self-host Coolify on a VPS. You’ll ship apps with git-based builds, environment variables, service templates, and one-click rollbacks. You keep control, and your production stack doesn’t become someone else’s product.

This is an operator-focused setup guide. It covers tradeoffs, a realistic sizing baseline, a Docker Compose deployment, and Nginx + Let’s Encrypt TLS. It also covers two items people skip until it hurts: backups and safe updates.

Coolify in plain terms: who it’s for, and what it replaces

Coolify is a self-hosted PaaS that sits between “a raw VPS with Docker” and “a fully managed platform.” You connect it to a server and wire up a Git provider (or push manually). Coolify builds and deploys containers.

From the web UI, you manage the everyday plumbing: domains, HTTPS, environment variables, logs, health checks, and background workers.

Coolify tends to fit well if you:

• Run 2–30 services and want one consistent deploy flow.
• Host internal tools, client apps, staging environments, or a small SaaS stack.
• Prefer Docker images and Compose-style definitions over custom shell scripts per app.
• Want costs that track CPU/RAM/disk instead of per-service tiers.

It’s a weak fit if you need multi-region autoscaling, deeply managed data services with point-in-time restore, or compliance constraints that usually require a dedicated platform team.

Self-host Coolify on a VPS vs hosted PaaS (Heroku, Render, Fly.io)

Hosted PaaS options are still a great deal when you truly want “deploy and forget.” You get managed runtimes, polished add-ons, and a support path. The tradeoff is price, especially once you add multiple services, workers, and persistent storage.

When you self-host, you’re making a different swap:

• Cost profile: spend follows CPU/RAM/disk, not per-service packaging.
• Network control: you own firewall rules, private networking, and egress behavior.
• Ops responsibility: you patch the OS, rotate keys, and prove backups restore.

If you already run at least one production VPS, Coolify is often a net win. If you don’t, start with managed VPS hosting. That way patching, monitoring, and baseline security don’t become your new full-time job.

Licensing and what “open source” means here

Coolify is source-available and built for self-hosting. Before you package it into a client deliverable or any commercial offering, read the project’s license terms in the official repository. Confirm they match your use case.

The steps below assume a standard self-hosted deployment.

What you’ll run it on: realistic resource requirements

Coolify itself is light. Your apps—and especially your builds—aren’t. Size the server for the workloads, not the dashboard.

• Small sandbox: 2 vCPU / 4 GB RAM / 60+ GB NVMe. Fine for 5–10 lightweight services.
• Team staging: 4 vCPU / 8 GB RAM / 120+ GB NVMe. A better floor for multiple Node/PHP apps plus databases.
• Production for small SaaS: 4–8 vCPU / 16 GB RAM / 200+ GB NVMe, or move to a dedicated box once disk and RAM pressure becomes steady.

Two realities to plan around:

• Disk fills first. Images, build cache, and logs surprise people. Watch Docker storage early.
• RAM spikes during builds. Local image builds can surge memory usage. Keep headroom or offload builds.

If you want a clean baseline with room to grow, start on a HostMyCode VPS. Scale up once CPU or memory pressure becomes consistent.

Architecture: keep the blast radius small

A simple production layout works well at the start:

• One VPS runs Coolify and a handful of services.
• Nginx terminates TLS and routes traffic to Coolify and your apps.
• Backups copy Coolify’s persistent data to offsite storage.

Once the apps become business-critical, split responsibilities:

• VPS A: Coolify control plane + build tooling
• VPS B: production workloads
• Optional: managed database host (or separate DB VPS) for durability

This reduces the “one bad change took down everything” failure mode.

If you’re building your ops baseline, the checks in our server monitoring setup guide map cleanly onto a Coolify host.

Deploy Coolify with Docker Compose (operator-friendly, not fragile)

Coolify supports Docker-based installs. The exact images and variables change over time. Treat the official docs as the source of truth.

On a production VPS, aim for consistency. Use fixed paths, predictable upgrades, and an obvious home for secrets.

Assumptions: Ubuntu 24.04+ or Debian 12+, a non-root sudo user, and DNS for coolify.example.com pointing at your VPS.

1) Prep the host

Install Docker Engine and the Compose plugin from your distro or Docker’s repository. Then verify:

docker --version
docker compose version

Create a dedicated directory:

sudo mkdir -p /opt/coolify
sudo chown -R $USER:$USER /opt/coolify
cd /opt/coolify

Keep the firewall narrow. Only SSH, HTTP, and HTTPS should be reachable from the internet.

If you haven’t locked that down yet, follow our UFW firewall walkthrough.

2) Compose file structure (what to persist)

Coolify stores state (config, metadata, and more) in persistent volumes. Put that state on disk you actually back up. Keep ownership and permissions stable.

A practical starting layout:

/opt/coolify/
  docker-compose.yml
  .env
  data/
    coolify/

Example Compose skeleton (use it as a template; confirm the current image name and required variables from Coolify’s docs):

services:
  coolify:
    image: <coolify-image-from-official-docs>
    container_name: coolify
    restart: unless-stopped
    env_file:
      - .env
    volumes:
      - ./data/coolify:/data
      - /var/run/docker.sock:/var/run/docker.sock
    networks:
      - coolify_net

networks:
  coolify_net:
    name: coolify_net

Two habits that pay off later:

• Put everything under /opt/coolify. Backups and restores stay simple.
• Treat Docker socket access as privileged. Coolify needs it to deploy. The host becomes part of your security boundary.

Start it:

docker compose up -d
docker compose ps
docker logs --tail=100 coolify

Nginx reverse proxy + HTTPS (Let’s Encrypt) for Coolify

Coolify can manage domains for apps. Even so, it helps to keep the dashboard entry point clean and explicit.

Nginx is a good default. It’s predictable under load and easy to debug at 2 a.m.

If you prefer Caddy for automatic TLS, we’ve documented that path in Set Up Caddy Reverse Proxy for Docker on a VPS. This guide sticks with Nginx because it’s common on hosting servers.

1) Install Nginx and Certbot

sudo apt update
sudo apt install -y nginx certbot python3-certbot-nginx

2) Create an Nginx server block

Create /etc/nginx/sites-available/coolify:

server {
  listen 80;
  server_name coolify.example.com;

  location / {
    proxy_pass http://127.0.0.1:3000;  # replace with the port Coolify listens on
    proxy_http_version 1.1;
    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;

    proxy_set_header Upgrade $http_upgrade;
    proxy_set_header Connection "upgrade";
  }
}

Enable and test:

sudo ln -s /etc/nginx/sites-available/coolify /etc/nginx/sites-enabled/coolify
sudo nginx -t
sudo systemctl reload nginx

3) Issue the TLS certificate

sudo certbot --nginx -d coolify.example.com

For a deeper SSL checklist (chain problems, mixed content, renewals), keep our TLS setup guide handy. It’s also the fastest way to chase down the odd edge cases.

Backups: what to save (and what people miss)

If Coolify is your deployment control plane, losing its data is painful. You can rebuild containers, but you’ll lose mappings, environment variables, and deployment history unless you back it up.

Back up three buckets:

• /opt/coolify (Compose file, .env, and persistent data)
• Any app volumes you care about (uploads, user files, etc.)
• Databases (logical dumps or physical backups, depending on your DB and size)

A simple, dependable backup approach

For many teams, a nightly compressed archive plus an offsite copy is enough. Example using tar and rsync to a second server:

sudo tar -C /opt -czf /var/backups/coolify-$(date +%F).tar.gz coolify
rsync -av --delete /var/backups/ backupuser@backup-vps:/data/backups/coolify/

If you store secrets in .env, treat the backup as sensitive data. Encrypt it before sending, or use an encrypted backup tool.

For a stricter pattern (retention, prune rules, restore drills), read our disaster recovery runbook and adapt it to your Coolify setup.

Database backups for workloads you deploy

Coolify may run your database containers, but it doesn’t own your backup plan. If you’re on MariaDB/MySQL, follow the approach in Install MariaDB and Create Secure Backups on Ubuntu. Schedule dumps on the host (or inside the DB container), and keep retention explicit.

Updates: don’t treat your PaaS like a toy

Coolify upgrades are usually painless. In production, add two steps: take a backup first, and know how you’ll roll back.

A clean update sequence looks like this:

1. Confirm you have a fresh backup of /opt/coolify.
2. Pull new images: docker compose pull
3. Apply changes: docker compose up -d
4. Check logs and health: docker compose ps and docker logs

If the upgrade includes a data migration, startup may take longer than usual. Watch container logs until the service is listening normally again.

Also schedule a monthly patch window for the host OS. A PaaS on an unpatched VPS is still an unpatched VPS.

Security basics that matter for a Coolify host

Coolify needs privileged access to Docker. That’s expected for this kind of tool. It also changes how you should treat the machine.

A few items shouldn’t be optional:

• SSH hardening: key-only auth, no password logins, and no direct root SSH.
• Firewall: only expose 22/tcp (or your SSH port), 80/tcp, and 443/tcp publicly.
• Separate admin access: consider a VPN for admin endpoints. WireGuard is a good fit; see our WireGuard VPN guide.
• Protect the dashboard: strong admin passwords, 2FA if supported, and minimal user accounts.

If you’re running customer workloads, add basic abuse controls at the edge (rate limiting, bot filtering).

Nginx rate limiting is often enough to blunt credential stuffing on login forms; our Nginx rate limiting tutorial is a practical starting point.

Operational gotchas you’ll hit in the first month

• Disk pressure from Docker: cleanup helps, but don’t blindly prune on production hosts. Inspect first: docker system df.
• Builds timing out: slow networks and low RAM cause flaky builds. If it keeps happening, offload builds or scale the box.
• Outbound email: apps need password resets and notifications. Plan SMTP early. If you run your own relay, align with our Postfix relay guide and set SPF/DKIM/DMARC correctly.
• Too much on one box: Coolify + database + queue + search + builds can overwhelm a 4 GB VPS quickly. Move stateful services out first.

Where Coolify fits best on HostMyCode infrastructure

For experiments, one VPS is fine. Once real users show up, isolation and recovery matter more than convenience.

• For most teams: start on a HostMyCode VPS, keep the Coolify control plane and staging apps together, and put production databases on a separate instance.
• For production workloads you can’t pause: step up to dedicated servers so noisy neighbors and shared IO don’t sit in your risk model.
• If you want fewer moving parts: use managed VPS hosting for patching help and baseline monitoring, then run Coolify on top.

Summary: a Heroku-like workflow without renting your platform

To self-host Coolify on a VPS successfully, run it like production software. Don’t run it like a weekend container.

Put it behind Nginx with real TLS, lock down the host, back up the state, and update with a rollback plan. Do that and you get a comfortable deploy experience on infrastructure you control.

You can also scale from a single VPS to a dedicated server as your service count grows.

If you’re migrating off a hosted platform, HostMyCode migrations can help you plan a clean cutover, including DNS and TLS.

FAQ

Can I run Coolify and production apps on the same VPS?

You can, and plenty of teams start there. For production, move stateful services (databases, object storage) off the box first. Then split the control plane if you outgrow the setup.

Do I need Nginx if Coolify can manage domains?

Coolify can route apps, but you still need a reliable TLS entry point for the dashboard. You also need a place to enforce edge rules. Nginx keeps that layer explicit, testable, and easy to troubleshoot.

What should I back up for a working restore?

Back up /opt/coolify (including persistent data), plus the volumes and databases used by your deployed apps. Test restores at least quarterly.

How do updates usually fail?

The usual culprits are a full disk, Compose changes that don’t match your local files, and migrations that take longer than expected. Take a backup first and watch logs during restart.

Is a managed VPS worth it for Coolify?

If your team is small or you don’t have a dedicated operator, yes. Managed service helps keep the host patched and monitored so Coolify doesn’t end up running on a neglected server.