Coolify VPS Setup: Install, Secure and Size a Self-Hosted PaaS (2026)

A Coolify VPS is a Linux server running Coolify, an open-source (Apache 2.0) platform that gives you a Heroku-, Vercel- or Netlify-style workflow on a server you control: connect a Git repository, and Coolify builds the app, runs it in Docker containers behind a reverse proxy with automatic HTTPS, and manages databases and backups from a web dashboard. Coolify’s documented minimum is 2 CPU cores, 2 GB of RAM and 10 GB of free disk on a 64-bit Linux server such as Ubuntu 24.04 LTS, and one install command, run as root, sets everything up.

The command is the easy part. This guide covers what most setup guides skip: what the script changes on your server, why the first visitor to a fresh install can take it over, why UFW cannot close the dashboard port, and how much CPU and RAM your builds need. Every step was checked against Coolify’s documentation and the install script served on October 3, 2026, when Coolify v4.3.23 (released September 18, 2026) was the current release.

Key takeaways

• Coolify documents a 2-core, 2 GB RAM, 10 GB disk minimum on 64-bit Linux such as Ubuntu 24.04 LTS; builds on the same server, not Coolify itself, are what usually overload a small VPS.
• Pass ROOT_USERNAME, ROOT_USER_EMAIL and ROOT_USER_PASSWORD to the installer, because Coolify warns that whoever reaches the registration page first becomes admin with root access to the server.
• Ports 8000, 6001 and 6002 are published by Docker, so UFW cannot close them; once the dashboard works on its HTTPS domain, bind them to 127.0.0.1 with docker-compose.custom.yml.
• Coolify manages its own server over SSH as root with a key, so a hardened server needs PermitRootLogin prohibit-password, not no.
• Back up three things separately and off the server: the Coolify database plus the APP_KEY in .env, each database through scheduled dumps, and app volumes; a rollback restores none of them.

What is Coolify, and what does it replace?

Coolify is a control plane. It connects to each server over SSH, runs Docker commands there, and keeps your configuration in its own PostgreSQL database. Your apps are ordinary Docker containers, so if the Coolify dashboard goes down, running apps keep serving traffic; you lose deploys, scheduled jobs and the dashboard until it comes back, as How Coolify works explains.

It deploys three kinds of resources: applications (from a Git repository, a Dockerfile, a Docker Compose file or a prebuilt image), databases, and one-click services, of which its GitHub repository lists more than 300. If you are coming from a managed platform, this mapping, based on Coolify’s migration guide, shows where each familiar piece now lives:

On a managed platform	On Coolify	Who runs it
Git integration and auto-deploy	A Git source (public repository, deploy key or GitHub App) plus webhooks	Coolify
Framework preset or buildpack	Nixpacks or Railpack detection, or your own Dockerfile	Coolify, on your server
Dyno or serverless runtime	A Docker container	Your VPS
Production domain and certificate	A domain on the resource; the proxy (Traefik by default, or Caddy) requests and renews TLS	Coolify’s proxy on your VPS
Managed Postgres or Redis add-on	A database container, with scheduled dumps for every engine except Redis, Dragonfly and KeyDB	You: data, storage and restores
Instant rollback	Redeploy an image still kept on the server; data is not rolled back	Coolify
OS patching, firewall, disk space	Not included	You

That last row is the real trade. Coolify’s security model lists operating-system updates, SSH access, firewall rules, DNS and tested backups as your responsibility, whether you self-host Coolify or use Coolify Cloud. If the idea of a server you administer is new, start with what a VPS is and what you manage on one.

Coolify VPS requirements: CPU, RAM, disk, OS and ports

Item	Coolify’s documented requirement	What it means in practice
CPU	2 cores	Add cores if builds run on the same server
Memory	2 GB RAM	Builds are the spike; see the sizing section
Disk	10 GB free	Plus room for Docker images, volumes and local backups
Architecture	amd64 or arm64	HourlyVPS plans run on Intel Xeon hosts (amd64)
Operating system	Debian, Ubuntu LTS (20.04, 22.04, 24.04), the Red Hat family, SUSE, Arch, Alpine, 64-bit Raspberry Pi OS	This guide uses Ubuntu 24.04 LTS. Debian 12 works the same way. Non-LTS Ubuntu: use the manual install
Access	SSH, and root for the automated installer	A sudo user can run the script with sudo
Server state	A fresh server is recommended	Do not reuse a box that already serves websites on ports 80 and 443

Coolify also documents that it can start on 1 core, 512 MB of RAM and 4 GB of disk, “but this is not recommended”, and that running builds and Coolify on one server can make it unresponsive if you do not watch resource usage.

Which ports does Coolify need?

Port	Used for	Keep it public?
22/tcp	SSH: your logins and Coolify’s own connection to this server	Yes; read the UFW note before you limit it to your IP
80/tcp	HTTP and Let’s Encrypt certificate challenges through the Coolify proxy	Yes
443/tcp	HTTPS to your apps, and later to the dashboard	Yes
8000/tcp	The dashboard by IP, http://SERVER_IP:8000	Only until the dashboard has a domain
6001/tcp	Real-time dashboard updates by IP	Only until the dashboard has a domain
6002/tcp	The browser terminal by IP	Only until the dashboard has a domain

Coolify builds its sslip.io test addresses from the server’s public IP, so a public IPv4 address matters. Every server comes with one dedicated IPv4 address and IPv6, included in the plan price. A remote server that Coolify only manages needs 22, 80 and 443, not the three dashboard ports.

What does the Coolify install script change on your server?

The install script, as served on October 3, 2026, does more than Coolify’s docs summarize, and several of its changes matter if the server is not brand new:

Stage	What the script does	Why it matters
Checks	Exits unless it runs as root; refuses Docker installed from the Snap Store	As a sudo user, pipe it to sudo bash
Packages	Installs curl, wget, git, jq and openssl	Nothing to do
OpenSSH	Installs and starts openssh-server if missing, reads PermitRootLogin and only prints a warning when root login is off. It never edits sshd_config	A hardened server installs fine, then fails Coolify’s server validation (step 1 below)
Docker	If Docker is missing, runs Docker’s convenience script from get.docker.com, falling back to Docker’s apt repository. Stops if Docker Engine is older than version 24	Docker updates now come from Docker’s repository, which Ubuntu’s unattended upgrades skip by default
Docker daemon	Copies any existing /etc/docker/daemon.json to daemon.json.original-<timestamp>. Unless that file already defines an address pool, writes a new one with json-file logs capped at 10 MB × 3 files and a 10.0.0.0/8 address pool split into /24 networks, then restarts Docker	Docker settings you made for earlier stacks are replaced; compare with the backup copy
/data/coolify	Downloads Coolify’s Compose files and upgrade.sh into /data/coolify/source, generates APP_KEY and the database, Redis and real-time secrets in .env, and sets owner UID 9999 and mode 700	Use sudo to read anything there; .env is your recovery key
SSH key	Creates an ed25519 key in /data/coolify/ssh/keys and appends its public half to root’s ~/.ssh/authorized_keys, after deleting any line in that file containing the word “coolify”	This key is how the Coolify container manages the server as root
Coolify	Runs upgrade.sh, which pulls and starts four containers: coolify, coolify-db (PostgreSQL), coolify-redis and coolify-realtime	Ports 8000, 6001 and 6002 are now published on every interface

Two consequences follow. First, start from a fresh server, as Coolify recommends: if you already followed our Docker install guide, the installer keeps that Docker Engine but replaces its daemon.json. Second, Coolify’s proxy needs ports 80 and 443 for itself, so it cannot share them with an Nginx or Caddy reverse proxy you installed earlier.

How to install Coolify on a VPS running Ubuntu 24.04

Run these four steps in order on a fresh Ubuntu 24.04 LTS server, as a sudo user who logs in with an SSH key. You need a domain whose DNS you control later, when the dashboard moves to HTTPS.

Step 1: Harden the server, but keep key-only root login

Deploy the VPS, connect to it over SSH, and work through steps 1 to 5 of our VPS security checklist: updates, a sudo user, your SSH key, password logins off, and UFW with SSH allowed. Make one deliberate change. Coolify manages its own server over SSH as root with a key, so the checklist’s PermitRootLogin no breaks Coolify’s connection to localhost. Coolify’s OpenSSH page asks for PermitRootLogin prohibit-password instead, which lets root in with a key but never with a password.

If you already created the checklist’s drop-in file, change that one line, test the configuration and reload SSH:

sudo sed -i 's/^PermitRootLogin no$/PermitRootLogin prohibit-password/' /etc/ssh/sshd_config.d/00-hardening.conf
sudo sshd -t && sudo systemctl reload ssh
sudo sshd -T | grep -i -E '^(permitrootlogin|passwordauthentication)'

The last command should print permitrootlogin with without-password or prohibit-password (two names for the same setting) and passwordauthentication no. Root still cannot log in with a password. Coolify’s alternative, a non-root server user, is marked experimental and needs passwordless sudo for every command, so it is root-equivalent anyway.

Step 2: Run the installer with a pre-created admin account

Anyone who reaches the registration page first can become the instance admin and gain root access to your server.

Coolify Docs, Start with Self-hosted

Port 8000 is open to the internet the moment the installer finishes. Close that window by passing the admin account to the installer, a documented option that exists so “the registration page is never exposed”. Download the script first so you can read what you are about to run as root:

curl -fsSL https://cdn.coollabs.io/coolify/install.sh -o coolify-install.sh
less coolify-install.sh

Then run it with sudo. read -s keeps the password out of your shell history:

read -r -s -p 'Coolify admin password: ' CPW; echo
sudo env ROOT_USERNAME='admin' ROOT_USER_EMAIL='[email protected]' ROOT_USER_PASSWORD="$CPW" bash coolify-install.sh
unset CPW

• ROOT_USERNAME: 3 to 255 characters; letters, digits, spaces, underscores and hyphens.
• ROOT_USER_EMAIL: a real address on a domain with valid DNS records.
• ROOT_USER_PASSWORD: at least 8 characters with uppercase, lowercase, a digit and a symbol. The installer writes it into /data/coolify/source/.env with sed, so use symbols such as ! or - and avoid |, &, \, $, quotes and spaces.

When it finishes, the script prints the dashboard address, http://SERVER_IP:8000, and a reminder to back up the .env file. If you prefer Coolify’s one-line form, run curl -fsSL https://cdn.coollabs.io/coolify/install.sh | sudo bash as your sudo user (Coolify’s docs pipe it to plain bash as root), then register your admin account immediately.

Step 3: Log in through an SSH tunnel and lock the settings

http://SERVER_IP:8000 is plain HTTP, so your password would cross the internet unencrypted. Forward the three dashboard ports over SSH instead (how local port forwarding works), then open http://localhost:8000 on your own computer:

ssh -L 8000:127.0.0.1:8000 -L 6001:127.0.0.1:6001 -L 6002:127.0.0.1:6002 you@SERVER_IP

Forwarding 6001 and 6002 too lets live updates and the browser terminal, which use those ports for direct access, work through the tunnel. Once you are logged in:

1. Open Servers > localhost and confirm the General page reads “Server is reachable and validated”. If it does not, recheck step 1.
2. In Settings > Configuration > Advanced, set Registration to “Registration disabled”, and keep API access disabled until an integration needs it.
3. Turn on two-factor authentication for your account and store the recovery codes.
4. In Settings > Configuration > Updates, choose automatic updates or a manual routine (see keeping Coolify updated).

Step 4: Save the .env file off the server

Coolify encrypts stored credentials and private keys with the APP_KEY in /data/coolify/source/.env, and an instance backup does not include that file. Without it, a restored Coolify cannot read its own secrets. Print the file and store its contents in a password manager:

sudo cat /data/coolify/source/.env

If you used step 2’s variables, the file also holds the admin password, so treat all of it as a secret.

How do you secure the Coolify dashboard?

Ports 8000, 6001 and 6002 are published by Docker, and Docker’s NAT rules forward published ports before UFW sees the traffic, so ufw deny 8000 changes nothing (why Docker bypasses UFW). Coolify’s firewall page says the same: do not rely on plain UFW; use a provider firewall, the community tool ufw-docker, or change how Coolify publishes the ports. On a single VPS the cleanest fix is the last one: give the dashboard a domain, then bind the three ports to 127.0.0.1.

Give the dashboard its own domain

1. Create an A record, and an AAAA record for IPv6, such as coolify.example.com pointing at the server (setting A and AAAA records).
2. In Settings > Configuration > General, enter https://coolify.example.com in URL and save. The Coolify proxy requests a Let’s Encrypt certificate through ports 80 and 443.
3. Open https://coolify.example.com, log in, and check that the dashboard loads over HTTPS, status changes appear without a page reload, and Terminal in the sidebar connects.

Do not reuse an application’s domain for the dashboard; Coolify warns that routing and certificates become unpredictable. Set this domain before you connect a GitHub App, because GitHub needs a public Coolify URL to deliver webhooks.

Add one more DNS record while you are there: a wildcard such as *.apps.example.com pointing at the same server. Enter https://apps.example.com in Wildcard Domain under Servers > localhost > General, and Generate Domain then gives each app its own subdomain. Without it, Coolify falls back to sslip.io addresses, which stay on plain HTTP because Let’s Encrypt rate-limits the shared sslip.io zone.

Bind ports 8000, 6001 and 6002 to localhost

Coolify loads /data/coolify/source/docker-compose.custom.yml on top of its own Compose files and keeps it across updates. Create it with the localhost binding from Coolify’s firewall docs:

sudo tee /data/coolify/source/docker-compose.custom.yml > /dev/null <<'EOF'
services:
  coolify:
    ports: !override
      - "127.0.0.1:${APP_PORT:-8000}:8080"
  soketi:
    ports: !override
      - "127.0.0.1:${SOKETI_PORT:-6001}:6001"
      - "127.0.0.1:6002:6002"
EOF

Validate the merged configuration. --quiet prints nothing when the files are valid, so the secrets in .env stay off your screen:

sudo docker compose --env-file /data/coolify/source/.env \
  -f /data/coolify/source/docker-compose.yml \
  -f /data/coolify/source/docker-compose.prod.yml \
  -f /data/coolify/source/docker-compose.custom.yml \
  config --quiet

Apply it with the Compose command from Coolify’s Compose-overrides docs. It recreates Coolify’s own four containers; your apps keep running:

sudo docker compose --env-file /data/coolify/source/.env \
  -f /data/coolify/source/docker-compose.yml \
  -f /data/coolify/source/docker-compose.prod.yml \
  -f /data/coolify/source/docker-compose.custom.yml \
  up -d --pull always --remove-orphans --force-recreate

Coolify’s firewall page applies the file by re-running install.sh instead, but its update page warns that install.sh resets ownership and permissions under /data/coolify on an existing instance, which is why this guide uses the Compose command. Check the result on the server:

sudo docker ps --format 'table {{.Names}}\t{{.Ports}}'

In the coolify and coolify-realtime rows, every published port should start with 127.0.0.1, with no 0.0.0.0 or :: entries left. From your own computer, curl -m 5 http://SERVER_IP:8000 should now fail to connect, while https://coolify.example.com still loads.

What UFW still does on a Coolify server

Keep the checklist’s UFW rules: SSH allowed, everything else denied. UFW still filters SSH and anything that listens on the host itself. It does not need rules for 80 and 443, because Docker publishes those for the proxy, and it will not block a database port you publish later. To filter Docker-published ports by source address, use the DOCKER-USER chain or ufw-docker.

One trap is specific to this server. Coolify reaches its own SSH port from a container, so that connection comes from the Docker address pool the installer set (10.0.0.0/8 by default), not from your IP. If you narrow the SSH rule to your own address, allow that pool as well, or localhost stops validating:

sudo ufw allow proto tcp from 10.0.0.0/8 to any port 22

Keep Coolify updated: the advisory record

Coolify stores SSH private keys and runs commands as root on every server it manages. As of October 3, 2026, its GitHub repository lists 70 published security advisories, 21 of them rated critical, published between January 2025 and July 2026. The affected versions they list are all 4.0.0 or older (the current release is 4.3.23), and 18 of the 21 critical ones describe an attacker who already has a dashboard account. Two habits follow:

• Stay current. In Settings > Configuration > Updates, either enable automatic updates on a schedule, or read the release notes and select Upgrade Now on a fixed day each week. Coolify’s update guide asks for an instance backup first, and deployments running during an update fail.
• Treat every dashboard account as root on your servers. Keep registration disabled, give team members the lowest role they need, require 2FA, and give each integration its own API token with an expiry date.

Deploy your first app from Git

With the server validated, a first deployment takes a project, a source and a build pack. Coolify’s example repository, https://github.com/coollabsio/coolify-examples.git, works for a dry run.

1. Select New Project and name it, then open the project and select Create New Resource.
2. Choose the source: Public Repository for an HTTPS clone URL, or a deploy key or GitHub App for private code (table below).
3. Choose the Build Pack: Nixpacks or Railpack (beta) to detect the framework, Static for files that are already built, Dockerfile, or Docker Compose.
4. Set Ports Exposes to the port your app listens on, such as 3000. Inside the container the app must listen on 0.0.0.0, not localhost, or the proxy returns 502 Bad Gateway.
5. In Domains, enter the full URL with https://, for example https://app.example.com:3000. The :3000 selects the container port; visitors still arrive on 443. For a first test, keep the generated sslip.io address.
6. Add environment variables. Build Variable and Runtime Variable are both on for a new variable; turn Build Variable off for secrets the app reads only at runtime.
7. Select Deploy and watch the build log.

Source	Use it when	Automatic deploys
Public repository	The code is public and clones over HTTPS	Add a manual webhook, then enable Auto Deploy
Deploy key	One private repository needs read-only SSH access	Manual webhook
GitHub App	Private repositories, scoped access and pull-request preview deployments	Webhooks are set up by the app

Rollbacks redeploy an image Coolify kept on the server. They do not roll back a database or uploaded files. Prefer a ready-made app? Coolify’s one-click services include n8n; our n8n self-hosting guide lists the environment variables it needs behind a reverse proxy.

Add a database

From Create New Resource, choose PostgreSQL, MySQL, MariaDB, MongoDB, Redis, Dragonfly, KeyDB or ClickHouse. Coolify generates credentials and a named volume, and the database gets no public endpoint by default. Copy its Internal URL into your app’s environment variables; containers on the same Coolify network reach it by container name.

Common Coolify problems and documented fixes

Symptom	Likely cause	Fix
Installer stops with “Please run this script as root or with sudo”	The script was piped to bash as a normal user	Run it with sudo, as in step 2
Installer says Coolify does not support Docker installed via snap	Docker came from the Snap Store	sudo snap remove docker, then run the installer again
localhost is not reachable or validated	PermitRootLogin no, or Coolify’s key is missing from /root/.ssh/authorized_keys	Set prohibit-password (step 1); Coolify’s OpenSSH page covers the manual key setup
Browser shows a certificate warning on your domain	DNS does not point at the server yet, port 80 or 443 is blocked, the domain was entered with http://, or a generated sslip.io address was switched to https://	Fix the A/AAAA record, enter your own domain with https://, redeploy
502 Bad Gateway on the domain	Wrong Ports Exposes value, or the app listens on 127.0.0.1 inside the container	Match the port; make the app listen on 0.0.0.0
The server becomes unresponsive during a deploy	The build uses up RAM or CPU	Build in CI or on a build server, add swap, or resize (see sizing)
Deploys fail with “no space left on device”	Images and build cache filled the disk	Run Docker Cleanup on the server page; keep volume deletion off
Dashboard unreachable after an update or reboot, with ufw-docker	A rule points at the coolify container’s old IP address	Replace it with a rule for the destination port

How do you back up Coolify on a VPS?

Coolify keeps three kinds of data apart, and each needs its own backup. A rollback restores none of them.

What	Coolify feature	Stored by default in	Restore notes
Coolify itself: projects, settings, credentials	Settings > Backup: a daily instance backup once configured, with an optional S3 copy	Local storage on the Coolify server	Needs the matching APP_KEY from .env
PostgreSQL, MySQL, MariaDB, MongoDB, ClickHouse	Backups on each database: scheduled engine dumps such as pg_dump, with an optional S3 copy	/data/coolify/backups on the database’s server	Coolify’s docs: restore into a disposable database before you trust a backup
Redis, Dragonfly, KeyDB	No scheduled backups in Coolify	Their Docker volume	Use the engine’s own persistence and backup tools
App files in volumes or directory mounts	Backups on the application: scheduled .tar.gz archives, with an optional S3 copy	The deployment server	No restore button; optionally stop containers during the archive for consistency

Every local copy sits on the same VPS it is meant to protect. Turn on the S3 copy for each schedule, pointed at an S3-compatible bucket outside the server, and keep the APP_KEY in your password manager. For files Coolify does not archive, a file-level tool such as restic, sent to the same kind of bucket, covers the rest; our VPS backup guide with restic sets it up.

How much CPU and RAM does Coolify need for builds?

Coolify’s documented 2 GB minimum covers Coolify itself. Builds are what push a small server over: by default Coolify builds each image on the server that runs your apps, and its troubleshooting page is blunt about it:

The docker image build process can overload your server.

Coolify Docs, Server Crash During Build

Its rivals agree: Dokploy sets its 2 GB RAM and 30 GB disk minimum to absorb “the resources consumed by Docker during builds”, and CapRover warns that 512 MB “might not be enough” for builds. Size for the build, not for Coolify at rest:

Your Coolify workload	Starting plan	Monthly cap	Reasoning
Apps deployed from prebuilt images (built in CI), static sites, one database	Quartz Q4: 2 vCPU, 4 GB, 80 GB NVMe	$15.00/month cap	Meets the 2-core minimum with 2 GB to spare. Coolify’s docs show an example server with the same 2 vCPU and 4 GB that runs 16 static sites, 25 Rust services, bots and workers, PostgreSQL and two Valkey databases at 2.6 GB average RAM, 60 to 70% CPU and 32 GB of disk, because its apps are built elsewhere and heavily optimized.
Building from Git on the same server: a few Node, Python or PHP apps plus databases	Quartz Q8: 4 vCPU, 8 GB, 160 GB NVMe	$25.00/month cap	Each build runs next to everything already running. Twice Q4’s RAM leaves room for one build at a time, and 160 GB holds images and build cache between cleanups.
Frequent or heavy builds: large TypeScript monorepos, Rust, many deploys a day	Chrono C8: 2 dedicated vCPU, 8 GB, 100 GB NVMe	$35.00/month cap	A build keeps every core busy for minutes. Dedicated vCPUs give steadier build times under that sustained load; Q8 gives you more vCPUs, but shared.
Builds that still slow down running apps	Coolify server plus a separate build server	Two plans	With Coolify’s build-server feature, another machine builds the image and pushes it to a registry; the app server only pulls. A build server cannot run resources.

Two more ways keep builds off a small server, both from Coolify’s docs: build the image in GitHub Actions, push it to a registry such as GitHub Container Registry, and deploy it as a Docker Image resource; or use the build server above. If you would rather run those CI builds on your own server than on GitHub-hosted runners, an ephemeral self-hosted runner on an hourly VPS bills only for the hours it exists.

On a tight plan, a swap file gives a memory-hungry build somewhere to spill instead of being stopped by the kernel’s out-of-memory killer. It is slower than RAM and no substitute for it (adding swap on Ubuntu 24.04). Disk fills quietly too: Coolify’s Docker Cleanup docs suggest starting with a daily run at midnight and an 80% usage threshold, with Delete Unused Volumes left off, because an unused volume can still hold database data.

Builds download base images and packages whenever the cache misses. Istanbul plans include the monthly traffic allowance listed for each plan, prorated for a server that exists for part of a billing period. For where to put the server, see how to choose a VPS location.

What does Coolify on a VPS cost per month?

Self-hosted Coolify has no license fee, and Coolify’s self-hosted vs Cloud comparison says it includes every current and upcoming feature. You pay for the server. Coolify Cloud, where the Coolify team runs the dashboard for you, starts at $5 per month for up to two connected servers, plus $3 per month for each additional server, and you still pay for those servers (Coolify’s pricing note, checked October 3, 2026).

Want to try Coolify before committing? Four hours on an hourly VPS cost $0.12: install it, deploy one repository and decide. If Coolify stays, keep the same server; there is nothing to switch, because the hourly charges stop at the cap. If it goes, delete the server rather than stopping it. A stopped server is still billed, because its vCPU, memory, disk and IP addresses stay reserved for you; only deleting the server stops billing.

Each new server is ordered with a small initial credit that prepays its hours; how hourly billing works covers it with examples. The hourly vs monthly comparison explains the cap, and the VPS cost calculator prices any other duration.

Quartz Q4 as a Coolify server: a 4-hour trial, a day, a week and an always-on month

Duration	Hours on the meter	Cost $0.03/hour · cap $15.00/month	Note
4 hours	4	$0.12
1 day	24	$0.72
7 days	168	$5.04
30 days	720	$15.00	Capped at the monthly price

Coolify vs Heroku: a small-app example

Heroku‘s pricing page (checked October 3, 2026) lists Basic dynos at $7 per month each with 0.5 GB of RAM, and its smallest Postgres plan, Essential-0, at $5 per month with 1 GB of storage. An app with a web process, a worker and a database comes to $19 per month (our arithmetic) for 1 GB of app RAM. On Coolify, the same three containers share a Quartz Q4’s 4 GB for at most $15.00 per billing period.

Heroku is the better fit when nobody on the team wants to patch servers, watch disks or rehearse restores: OS patching and certificate management come with its price. Coolify fits when you run several apps on one server, need more memory per app, or want the data on a server you control. All plan prices are on the pricing page.

Coolify vs Dokploy vs CapRover

All three turn a VPS into a self-hosted PaaS built on Docker; they differ in proxy, orchestration and how much server they ask for.

	Coolify	Dokploy	CapRover
License	Apache 2.0	Apache 2.0, except code in a /proprietary directory	Apache 2.0
Documented minimum	2 CPU cores, 2 GB RAM, 10 GB disk	2 GB RAM, 30 GB disk	No fixed minimum; warns that 512 MB “might not be enough” for builds
Install	curl -fsSL https://cdn.coollabs.io/coolify/install.sh | bash	curl -sSL https://dokploy.com/install.sh | sh	One docker run of caprover/caprover
Dashboard before a domain	Port 8000 (plus 6001 and 6002)	Port 3000	Port 3000, default password captain42
Reverse proxy	Traefik (default) or Caddy	Traefik	nginx
Orchestration	Docker on each server; Swarm support deprecated and due for removal in v5	Docker Swarm	Docker Swarm
Latest release	v4.3.23, September 18, 2026	v0.30.8, September 29, 2026	v1.15.4, August 30, 2026
GitHub stars	About 62,500	About 37,600	About 15,200

• Coolify fits when you want 300+ one-click templates, a choice of Traefik or Caddy, and plain Docker without Swarm. Budget for its 2-core minimum and its advisory history.
• Dokploy fits teams that want Docker Swarm from the first install, since its installer initializes Swarm.
• CapRover fits the smallest servers and nginx users. It starts with a published default password, so change that before anything else.

Not sure yet? Each installs with one command (CapRover needs Docker installed first), so deploy one test server per platform by the hour, run your own repository on each, and keep the one you like. If you would rather compare the servers themselves, the Hourly VPS Fine-Print Index lists billing rules for 20 providers.