Coolify Install: Free Self-Hosted Heroku Alternative

If you want a free, self-hosted Heroku alternative, the Coolify install takes one command. This guide walks through installing Coolify on a VPS, securing it, and deploying apps, databases, and 340+ one-click services with automatic SSL and Git-push deploys, just like Netlify or Heroku.

Coolify is open-source (Apache-2.0, 62,000+ GitHub stars) and has been in active development since 2021. The first stable v4.0.0 shipped in April 2026 after a long beta. Releases land multiple times a week: v4.3.23 (2026-09-18) is the latest stable as of this update. v5, focused on multi-server scalability, is in development while v4 stays fully supported.

Already familiar with Coolify and want a deeper comparison? See Coolify vs Dokploy vs Kamal 2.

Everything below follows the official docs as of September 2026. The screenshots and the video predate the v4.3 UI redesign from August 2026. Labels moved around, the flow did not.

What Coolify can deploy: apps, databases, and 340+ one-click services

Applications. Coolify builds with Nixpacks, Railpack (beta), a Dockerfile, Docker Compose, or a prebuilt Docker image. Framework auto-detect covers:

Databases. The picker currently includes PostgreSQL, MySQL, MariaDB, MongoDB, Redis, Valkey, KeyDB, Dragonfly, CouchDB, ClickHouse, and Databasus. The list is not exhaustive and grows with releases.

One-click services. The community templates repo now powers 340+ services: WordPress, Ghost, n8n, Plausible Analytics, Uptime Kuma, MinIO, Vaultwarden, Appwrite, Supabase, Directus, NocoDB, Meilisearch, Umami, Hasura, Beszel, Langfuse, plus newer entries like InfluxDB, Stalwart, and Termix. If n8n is the one you want, here is how to self-host n8n with Docker and Traefik.

Git sources. Coolify deploys from GitHub, GitLab, Gitea, and Bitbucket. Since v4.3.0 it also pulls from private repos on self-hosted GitLab. Push to your branch and Coolify rebuilds, same as Netlify or Heroku.

Architectures and operating systems. AMD64 and ARM64. Debian-based (Ubuntu LTS 20.04, 22.04, 24.04, Debian), Red Hat-based (CentOS, Fedora, AlmaLinux, Rocky Linux, plus TencentOS and Asahi), SUSE (SLES, openSUSE), Arch Linux, Alpine Linux, and Raspberry Pi OS 64-bit.

All of this runs on the same VPS. There is no per-app or per-dyno billing.

How Coolify works: git push to Coolify on port 8000, build pack builds Docker containers, Traefik reverse proxy with Let’s Encrypt exposes apps and databases on ports 80 and 443

New in Coolify v4.2 and v4.3 (2026)

If you last looked at Coolify in early 2026, two releases changed the day-to-day experience. v4.2.0 (2026-07-21) and v4.3.0 (2026-08-12) shipped the features below, plus breaking changes worth reading before you upgrade.

• v4.3.0 brought a full UI redesign: new navigation, a real domain manager with DNS checks, and automatic Cloudflare DNS setup.
• Scheduled volume backups now send persistent storage to a local path or S3, with retention policies, history, and an API. For an off-site target, compare the cheapest S3-compatible backup storage.
• v4.2.0 added cloud-server provisioning: create Hetzner (with firewall, network, and backup options), Vultr, or DigitalOcean servers straight from the dashboard.
• An instance-level MCP (Model Context Protocol) endpoint lets AI agents inspect Coolify. Read-only tools landed in v4.1.0, v4.3.0 added diagnostics and deployment controls, with a per-team toggle.
• Per-domain search-engine indexing controls keep preview deployments out of Google.
• New one-click services include Buzz, Celld, InfluxDB, Stalwart, and Termix.

Coolify VPS requirements

Those minimums come from the official docs as of September 2026. The disk floor used to be listed as 30 GB; 10 GB is what the docs say now, but Docker images and build caches eat disk fast. Budget for 30 GB+ of real storage on anything you care about.

The docs’ budget note: Coolify will technically run on 1 core, 512 MB RAM, and a 4 GB disk, but that is not recommended. Their guidance is to start with 1 core / 1 GB RAM and upgrade as workloads grow.

For a real-world anchor, the docs reference a Hetzner CAX11 (4 GB ARM, 40 GB disk) comfortably hosting 16 static sites, 9 Rust APIs, 5 full-stack apps, 4 Discord bots, 7 workers, 2 Valkey, 2 PostgreSQL, Umami, Beszel, and Coolify itself, averaging 3.2 GB RAM and 32 GB disk used. That tracks with what I’d expect: disk is the real constraint, not CPU. Provider details are in our Hetzner Cloud review, and raw numbers in the DigitalOcean vs Vultr vs Hetzner VPS benchmarks.

The Coolify control plane is free (Apache-2.0). You pay only for the VPS, roughly $5-15/month order of magnitude. VPS prices jumped across the board in 2026, so if you’re rethinking a rented box, see what changed and when a mini PC wins. Running it at home on a compact mini PC like the ASUS DC510 also works; Coolify does not care where the server lives. If you stay on Hetzner, Hetzner’s cost-optimized plans after the 2026 price increase are still the default pick.

How to install Coolify on a VPS

Any VPS provider works. Hetzner offers the best price-to-performance for self-hosting in my experience. Other options: DigitalOcean, Vultr, Hostinger.

Step 1: run the Coolify install script

SSH to your VPS as root and run the official one-liner:

curl -fsSL https://cdn.coollabs.io/coolify/install.sh | bash

Not root? Prefix the pipeline with sudo. The script handles everything: dependencies (curl, wget, git, jq, openssl), Docker Engine 24+, directories under /data/coolify, SSH key generation, and starting Coolify. Re-running it is safe.

Note for Ubuntu users: the automated script works with Ubuntu LTS versions only (20.04, 22.04, 24.04). On a non-LTS release like 24.10, use the manual installation method.

Verify: curl -I http://localhost:8000 on the server returns HTTP 200 or 302. docker ps shows the Coolify containers. The URL printed by the script opens in a browser.

What broken looks like: port 8000 already in use (stop or move the other service); Snap Docker present (remove it, re-run); non-LTS Ubuntu (use the manual install); script dies mid-way (safe to re-run; check ownership and permissions under /data/coolify).

Step 2: create the admin account (or pre-create it securely)

env ROOT_USERNAME=dragos \
    [email protected] \
    ROOT_USER_PASSWORD='UseALongPassword123!' \
    bash -c 'curl -fsSL https://cdn.coollabs.io/coolify/install.sh | bash'

http://your-server-ip:8000

Verify: you are logged into the dashboard at :8000. If you used the env-var method, open http://your-server-ip:8000 in a private browser window: no registration form should be reachable.

What broken looks like: password rejected (it must hit the 8+ character, 4-class policy); env vars ignored (they must be in the same env ... bash -c '...' invocation; use sudo -E when not root).

Step 3: point a domain to the server

For production, run Coolify over HTTPS on a real domain. Add an A record for coolify.yourdomain.com (or similar) pointing at your server IP. Since v4.3, the domain manager can also set up Cloudflare DNS records automatically.

Verify: dig +short coolify.yourdomain.com returns the server IP before you continue. Let’s Encrypt issuance fails on a wrong or missing record.

What broken looks like: DNS not propagated yet. Wait it out, or lower the TTL before you change records. dig still showing the old IP is your answer.

Step 4: set the FQDN for free Let’s Encrypt SSL

Go to Settings > Coolify Settings and set the URL (FQDN) field to your domain. Coolify provisions a Let’s Encrypt certificate automatically.

Verify: curl -I https://coolify.yourdomain.com returns 200 and the browser shows a padlock.

What broken looks like: issuance fails on a FQDN typo (check Traefik’s logs from the dashboard); ports 80/443 blocked at the provider firewall; Let’s Encrypt rate limits after too many retries. Fix the cause before retrying, do not hammer it.

Step 5: connect a Git source

Go to Create New Resource and pick your Git source: GitHub, GitLab, Gitea, or Bitbucket. For GitHub, Coolify walks you through installing its GitHub App on your repositories. The video above covers this in detail. Since v4.3.0, private repos on self-hosted GitLab work too.

Verify: the repo list populates after connecting, and a webhook appears in the repo’s webhook settings on GitHub.

What broken looks like: the GitHub App landed on the wrong account or org (re-run the install flow from Coolify’s Git sources page); self-hosted GitLab needs a reachable instance plus app credentials.

Step 6: deploy your first application

Here is a walkthrough deploying a static Astro site. The flow is the same for any framework.

Create the application. Go to Create New Resource > Application, select GitHub, choose your repository and branch, then save. Coolify auto-detects the framework:

Pick a build pack. Nixpacks is the default. Railpack is available in beta, and you can always bring a Dockerfile, Compose file, or prebuilt image. For static frameworks, if the deployed site looks empty, check the publish directory in the build pack settings.

Point the domain. Add an A record for the app’s domain or subdomain pointing to the server IP, then set the URL in the application settings. Coolify configures Traefik and SSL automatically:

Deploy. Hit save, then hit deploy. The first build is slow (Coolify pulls base images and installs dependencies). Later builds are faster thanks to Docker layer caching.

Enable automatic deployments. Push a commit to your connected branch and Coolify rebuilds automatically. It is on by default under Features > Enable Automatic Deployment, same as Netlify or Vercel deploy hooks.

Verify: the build log reaches “Build succeeded”; curl -I https://app.yourdomain.com returns 200; push a trivial commit and watch the auto-deploy fire.

What broken looks like: build OOM on a 2 GB box (add swap or upgrade RAM, back to the requirements section); wrong publish directory for static frameworks; domain not resolving so Let’s Encrypt fails; auto-deploy not firing (check the webhook delivery log in GitHub and the automatic deployment toggle).

Step 7: deploy a database

From Create New Resource, pick a database type and deploy it. Coolify handles the Docker setup and volume persistence. Scheduled backups are first-class now: point them at a local path or S3-compatible storage with a retention policy, then check the backup history after the first run.

Verify: the connection string works from your app container (psql, mysql, or docker exec into the DB container). A test backup completes and shows up in the backup history.

What broken looks like: the app cannot reach the DB because it uses localhost instead of Coolify’s internal network hostname; disk fills from unbounded growth; S3 backups return 403 on bad keys or the wrong bucket region.

Troubleshooting common install problems

Securing your Coolify instance

Installing is the easy part. Coolify’s own security model puts SSH access, firewall rules, and provider network controls on you. The controls below are what turn a fresh install into something I would put a real domain on.

Pre-create the admin account (Step 2). The public registration race is the fastest way to lose a box.

Firewall the box. At your provider (Hetzner Cloud Firewall, DigitalOcean Firewalls, Vultr Firewalls) or with UFW:

• SSH on 22/tcp: restrict to your IP.
• HTTP and HTTPS on 80 and 443: open. Apps, Let’s Encrypt HTTP-01, and your Coolify FQDN need them.
• The Coolify UI on 8000/tcp: restrict to your IP, or close it entirely once the FQDN works over 443.
• Realtime websocket and instant terminal on 6001/6002/tcp: historically required. Check the current Coolify docs before you punch these through; I have not found an explicit current port list to quote.

Coolify ports and firewall: provider firewall allowing 22 restricted, 80 and 443 open, 8000 restricted, 6001 and 6002 to verify, in front of the VPS running Traefik, the Coolify UI, and internal apps and databases

Patch on a schedule. Between June 25 and July 2, 2026, Coolify published a cluster of security advisories: one critical, six high, three low. The worst of them: a cross-team IDOR that let one team deploy to another team’s servers, unauthenticated deploy triggers via a webhook HMAC bypass, authenticated RCE to host root, and OS command injection through volume names and database fields. All of it is fixed in current v4.3.x. The fix is “update to latest”, not a config change. Full list on the GitHub security advisories page.

Turn on notifications. Configure SMTP or the Resend integration (instance SMTP/Resend settings arrived in v4.3.10) so failed deploys and backup errors reach you instead of rotting in a log.

Back up /data/coolify/source/.env (Step 1). Without APP_KEY, you cannot restore Coolify from its own backups.

Provider firewalls and CrowdSec are free. Patching is yours. For host-level hardening beyond Coolify, see how to secure a VPS server with CrowdSec and how I locked down my Docker server after the BSI Hetzner report.

Keeping Coolify updated

Updates live under Settings > Configuration > Updates. Update-check frequency defaults to hourly (cron-configurable). The Auto Update toggle defaults to daily at 00:00, also cron-configurable. If AUTOUPDATE is set in /data/coolify/source/.env, it overrides the dashboard toggle, so keep one source of truth.

Each update writes a log to /data/coolify/source/upgrade-YYYY-MM-DD-HH-MM-SS.log. There is a terminal update method as well, and v4.3.10 added manual upgrade controls on the same page.

Before jumping from v4.1.x or older to current, re-read the breaking changes in the v4.2/v4.3 section above. Team roles and GET-based API or webhook scripts will bite you.

Verify: after an update, the version in Settings matches the release page, and ls /data/coolify/source/upgrade-*.log shows a fresh log with no errors.

What broken looks like: an update started while a deploy is running (check active deployments first); a failed update (read the dated log, it is not subtle); the dashboard toggle and AUTOUPDATE disagreeing (the env var wins).

Coolify Cloud pricing

Don’t want to run the control plane yourself? Coolify Cloud is the managed version: same UI and features, Coolify handles the infrastructure. Pricing as of 2026-09-28: $5/month base for 2 servers, plus $3/month per additional server, roughly 20% off on annual billing.

You still bring your own servers (Hetzner, DigitalOcean, AWS, a Raspberry Pi, a laptop at home). Cloud is the management plane, not the compute. You get unlimited deployments per server, managed email alerts, and the dashboard on app.coolify.io or your own domain. See coolify.io/cloud.

Cost math: self-hosted is a $5-10/month VPS plus your time. Cloud is $5/month plus $3 per extra server, on top of the VPS bill. Worth it when your time is the expensive part.

More Coolify tutorials

Coolify install FAQ

Conclusion: is Coolify worth self-hosting?

Yes, if you want Heroku or Netlify ergonomics without per-app billing. The Coolify install is one command. You get Git-push deploys, automatic SSL, real databases with scheduled backups, and 340+ one-click services on a box that costs $5-15/month instead of $7-25+ per dyno.

The counterweight: you own patching, backups, and uptime. The June/July 2026 advisory cluster is exactly why the Security and Updates sections above are not optional reading. That is the price of admission for self-hosting anything.

v4.3.x is current and ships releases multiple times a week. v5, aimed at multi-server scalability, is in development while v4 stays supported, so there is no dead end. You get the full deployment lifecycle on one box: Git integration, automatic builds, SSL, reverse proxy, databases, backups, preview deployments.

If you are paying for Heroku, Vercel, or Netlify and want to cut costs without losing convenience, Coolify on a $5-10/month VPS does the job.

For managing your server with a reverse proxy panel alongside Coolify, check out: