A Coolify VPS is your own Heroku-style platform: you push code or point at a Git repository, and Coolify builds it, runs it in Docker, puts a reverse proxy and a Let's Encrypt certificate in front, and schedules database backups. The software is free and open source. What you pay for is the server, so sizing it correctly is most of the job.
This post covers what a Coolify VPS needs, the one-command install and the steps right after it, the firewall ports and the Docker trap that catches most people, how builds change the sizing, a plan table with real prices, and what to back up. Requirements and ports come from the Coolify documentation, checked against v4.6.0, released on 2 November 2026.
What does a Coolify VPS need?
The self-hosted install guide gives a short version: 2 CPU cores, 2 GB of RAM and 10 GB of free disk, on amd64 or arm64. It also lists what runs, on any Linux server with SSH access:
- Operating system. Debian and Ubuntu (LTS releases for the script; non-LTS Ubuntu needs the manual install), plus the Red Hat family, SUSE, Arch and Alpine. Ubuntu, Debian, Rocky and AlmaLinux are all on our image list.
- A fresh server. The docs recommend one, because the installer sets up Docker and takes ports 80 and 443 for its proxy.
- Root access. The automated script expects the root user; the manual path covers non-root and existing Docker installs.
- Room to grow. The 10 GB is for Coolify itself. Docker images, volumes and backups come on top, and they grow with every app you add.
The docs also say Coolify can start on 1 core and 1 GB if cost is the concern, then move up as the server slows. That works for trying it out. For anything you build on the same box, plan from the 2-core, 2 GB minimum and add memory for the apps themselves.
Coolify itself is a set of containers: the dashboard, its own PostgreSQL and Redis, a realtime service for live updates and the web terminal, and the proxy (Traefik by default, Caddy as an option) that routes traffic for every app you deploy.
How do you install Coolify on a VPS?
On a fresh Debian or Ubuntu image, log in as root and run the installer from the docs:
curl -fsSL https://cdn.coollabs.io/coolify/install.sh | bashThe script installs Docker, pulls the Coolify containers and prints the next steps. Then, in this order:
- Open
http://<server-ip>:8000and create the admin account straight away. Until an account exists, whoever reaches the page first can register it. The docs list this step as "as soon as possible" for that reason. - Save the
APP_KEY. It lives in/data/coolify/source/.envand encrypts the credentials and private keys Coolify stores in its database. Without it, a restored database cannot read its own secrets. Copy the line into a password manager, off the server. - Give the dashboard a domain. Point an A record such as
coolify.example.orgat the VPS, set it as the instance domain, and Coolify's proxy fetches a certificate. After that you can close 8000, 6001 and 6002 to the public. - Set up email. Coolify can mail deployment and backup notifications through SMTP or Resend, configured under Settings, Email. For SMTP, use a relay or transactional provider on its authenticated submission port, 587 or 465, rather than sending directly from the server. Our email hosting page explains why we recommend a relay for outbound mail.
Updates are one click in the dashboard, or automatic if you leave auto-update on. Coolify can take a database backup before each update, and a failed backup stops the update from starting, which is the safe default.
Which ports does Coolify need?
The firewall page lists these for the server that runs Coolify:
| Port | Used for | Open to |
|---|---|---|
| 22/tcp | SSH. Coolify also manages its own host over SSH | Your IP, keys only |
| 80/tcp | HTTP and certificate issuance through the Coolify proxy | Everyone |
| 443/tcp | HTTPS for the dashboard (once on a domain) and every app | Everyone |
| 8000/tcp | Dashboard by IP | Your IP, or closed once the domain works |
| 6001/tcp | Realtime dashboard updates by IP | Your IP, or closed once the domain works |
| 6002/tcp | Web terminal by IP | Your IP, or closed once the domain works |
A second server that Coolify deploys to only needs 22/tcp from the Coolify server's IP, plus 80 and 443 if it serves public traffic.
The Docker and UFW trap
Docker writes its own iptables rules for published container ports, and those rules are evaluated before UFW's. A database you started with a public port mapping stays reachable from the internet even after ufw deny. The Coolify docs warn against relying on plain UFW and suggest a network firewall in front of the server, or the community ufw-docker tool, which makes UFW rules apply to Docker ports. The simpler habit: never publish a database port at all. Apps reach their database over the internal Docker network, and you reach it over an SSH tunnel.
Every Noded VPS includes 100 Gbps of always-on Layer 3/4 DDoS protection, which filters floods before they reach the proxy. Rate limits and app-level abuse are yours to handle in the proxy or the app.
How much does building on the same server cost?
More than running. A Node.js, Rust or Java build can use every core and several gigabytes of RAM for a few minutes, while the apps already deployed keep serving traffic on the same box. The docs put it plainly: if Coolify and your builds share a server, watch resource usage, because a busy build can make the server unresponsive.
The docs include a real example from one of the maintainers: a 2 vCPU, 4 GB server running Coolify plus 16 static sites, 9 API services, 5 full-stack apps, 4 Discord bots, 7 workers, 2 Valkey databases and a PostgreSQL database, averaging 2.6 GB of memory and 32 GB of disk. The catch is in the footnote: all of those apps are built somewhere else and pushed as images. Three ways to get the same effect:
- Build in CI and deploy an image. GitHub Actions or a CI runner builds the image, pushes it to a registry, and Coolify only pulls and runs it. Our self-hosted Docker registry guide covers keeping that registry on your own server.
- Use a second server for apps. Coolify connects to additional servers over SSH. The dashboard box stays small and the app box takes the load.
- Prefer static output where it fits. A static site costs almost nothing to serve once built; see our static sites on a VPS post.
Disk fills quietly with old images and build cache. Coolify's server settings include an automated Docker cleanup, on a schedule or at a disk-usage limit; it can be CPU-heavy, so run it off-peak, and check docker system df now and then.
Which Noded plan fits a Coolify VPS?
The workload descriptions are our estimate for planning, starting from the documented minimum of 2 cores and 2 GB; your apps decide the real number. Prices are monthly, in euros, excluding VAT, from our live catalogue.
| Use (estimate) | Plan | vCPU / RAM / SSD | Network | Bucharest | Amsterdam |
|---|---|---|---|---|---|
| Extra app server managed by Coolify, no dashboard on it | VPS I | 1 / 2 GB / 20 GB | 100 Mbps | €4 | €5 |
| Coolify plus a few small apps, images built in CI | VPS II | 2 / 4 GB / 40 GB | 140 Mbps | €6 | €8 |
| Coolify with builds on the box, one database | VPS III | 2 / 8 GB / 60 GB | 180 Mbps | €10 | €14 |
| Several apps and databases, parallel builds | VPS IV | 4 / 16 GB / 80 GB | 220 Mbps | €16 | €24 |
| Team platform before splitting into more servers | VPS V | 6 / 24 GB / 100 GB | 260 Mbps | €30 | €42 |
Extra disk is €4 a month per 50 GB, up to 150 GB, which is usually what a Coolify box runs out of first. Network figures are a symmetric per-VM ceiling with unmetered traffic. Bucharest deploys straight away; Amsterdam, Frankfurt and Vienna take preorders with about 14 days' delivery, and checkout shows current stock. Each VPS gets one dedicated IPv4, plus IPv6 in Romania, the Netherlands and Germany. Coolify needs nothing from us beyond root and a clean image.
What should you back up?
Two different things, and Coolify only covers one of them by default. The instance backup saves Coolify's own database: projects, settings, deployment history. It does not include your apps' data, databases or volumes, and it does not include the APP_KEY. A manual dump from the terminal looks like this:
mkdir -p /data/backups
docker exec coolify-db pg_dump --format=custom --no-acl --no-owner \
--username=coolify coolify > /data/backups/coolify-db.dmpFor the apps, add a backup schedule to each database you create in Coolify (PostgreSQL, MySQL, MariaDB, MongoDB, ClickHouse and SQLite are supported; Redis-type stores are not) and upload copies to S3-compatible storage. Back up persistent volumes separately. Keep every copy off the server: a second VPS in another location works well as a restic or Borg target, as our backup target post describes. Test a restore once, including the APP_KEY, before you rely on it.
Questions people ask
How much RAM does Coolify need?
The docs set the minimum at 2 GB with 2 CPU cores and 10 GB of disk. That covers Coolify itself; add memory for each app and database, and more if you build on the same server. By our estimate, 4 GB is a comfortable start when images are built elsewhere, and 8 GB when they are built on the box.
Is Coolify free to self-host?
Yes. The self-hosted edition is open source with no paid tier required. Coolify also sells a hosted dashboard, Coolify Cloud, that manages servers you bring; either way the servers are yours to pay for.
Why can I still reach a container port after blocking it with UFW?
Docker's iptables rules for published ports bypass UFW. Do not publish ports you want private, put a network firewall in front, or use ufw-docker as the Coolify firewall docs suggest.
Can Coolify deploy to more than one server?
Yes. Add servers over SSH from the dashboard; each needs port 22 open to the Coolify server and 80/443 if it serves traffic. This is the usual way to keep builds and apps off the dashboard box.
Should I put Coolify and production apps on the same VPS?
For side projects and small teams it is fine. When a failed build or a noisy app could take the dashboard down with it, move apps to a second server and keep Coolify on a small one.
Running Coolify on Noded
Coolify gives you the deploy experience of a hosted platform; the server underneath decides where your apps and their data live. Pick Bucharest and the VPS stays in the EU under GDPR, operated by an EU company on our own network, AS60982. For a product with paying customers, our SaaS hosting page shows how to grow from one VPS to several and then to dedicated servers in the same account. To start, order VPS II or VPS III from the VPS hosting page, run the installer, and create the admin account before you do anything else.