How to Use Coolify: The Beginner's Guide (First Server, First App, Your Own Domain, and the Root-Account Rule)
CodexFuse Team · 2026-10-31T03:57:27.257Z · 14 min read
Learn how to use Coolify: pick a VPS, install it safely, deploy your first app from Git, attach a domain with free SSL, and add a database.
What is Coolify, and why are beginners installing it on a VPS?
Coolify is an open-source, self-hosted platform-as-a-service — a "deploy apps like Heroku" dashboard you run on your own server instead of renting from a cloud platform. If you are learning how to use Coolify, the mental model is simple: you point it at a Git repository, and it builds the app into a Docker container, routes a domain to it, and fetches a free HTTPS certificate, all without you touching Docker commands or a reverse proxy by hand. It is Apache 2.0 licensed, so there is no seat count and no per-app meter running, according to a recent hands-on deployment guide on dev.to.
The reason beginners are installing Coolify now, rather than a year ago, is that version 4 went stable on April 27, 2026 and 4.4.6 followed on October 9, 2026 — the project had roughly 63,000 GitHub stars by mid-October 2026, per the same dev.to guide. That v4 dashboard is what every current tutorial shows, so make sure any guide you follow was written for v4, not v3.
Coolify is not a server manager in the general sense. It assumes the engine underneath is Docker — and if Docker is a new word for you, start with our Docker beginner guide first, because Coolify installs Docker for you but you will debug faster knowing what a container is. Coolify's lane is the deployment workflow: git push in, live URL out, databases one click away. By the end of this guide you will have installed it on a VPS, closed the one security hole a fresh install leaves open, deployed an app from Git, attached a real domain with HTTPS, and added a database.
What server do you need for Coolify?
You need a Linux server with SSH access — a VPS, a dedicated box, a local VM, even a spare laptop — and it should be a fresh machine so nothing fights over ports. The official Coolify documentation sets the minimum at 2 CPU cores, 2 GB of RAM, and 10 GB of free disk on amd64 or arm64, and it explicitly says smaller servers can run it but are not recommended. Supported distributions include Debian, Ubuntu, CentOS, Fedora, RHEL, AlmaLinux, Rocky, SUSE, openSUSE, Arch, and Alpine, plus 64-bit Raspberry Pi OS, per the same official installation docs.
The minimum runs Coolify itself, not your ambitions. Building apps and running them on the same machine is what eats the RAM, and the docs warn that high resource usage can make the server unresponsive when builds and workloads share one box. Pick your size from this table before you provision:
| Workload | CPU | RAM | Disk | Notes |
|---|---|---|---|---|
| Coolify alone, learning the dashboard | 2 cores | 2 GB | 10 GB free | The documented minimum; deploy one small app at a time. |
| First real app + one database | 2 cores | 4 GB | 40 GB | Matches a community production example (2 vCPU / 4 GB) that ran dozens of small services comfortably. |
| Several apps, staging + production | 4 cores | 8 GB | 80 GB+ | Room for parallel builds; Docker images and volumes add up fast. |
| Heavy builds (monorepos, large images) | 4+ cores | 16 GB | 100 GB+ | Consider a separate build server so deploys never starve your apps. |
If you have never rented a server before, our what is VPS hosting guide explains what a VPS actually is and how you get root access to one, and our roundup of cheap web hosting covers the $5-a-month tier that fits the first two rows of this table. Providers like Hostinger and DigitalOcean also ship one-click Coolify images if you would rather skip the manual install entirely.
How do you install Coolify on a VPS?
Learn this rule before you run anything: the first person to open the Coolify dashboard becomes the root administrator. A fresh install exposes the registration page on the open internet, so the moment Coolify is running you must either create your admin account immediately or make sure the dashboard port is not reachable until you do. That is the "root-account rule" every beginner guide should teach first — and it is the single most skipped step in quick-start posts, according to the recent dev.to deployment walkthrough.
The official way to create the root account safely is to pass it to the installer as environment variables, so the registration page is never exposed at all. The official docs list three required variables: ROOT_USERNAME, ROOT_USER_EMAIL, and ROOT_USER_PASSWORD (at least 8 characters with upper, lower, number, and a symbol). Set them in your shell before running the script.
With that understood, installation is one command. The official install script is:
- SSH into your server as root (or a sudo-capable user — the automated path wants root). Ubuntu 24.04 LTS is the most-tested choice.
- Pre-create the root account: export
ROOT_USERNAME,ROOT_USER_EMAIL, andROOT_USER_PASSWORDin your session so no public registration page ever appears, per the official docs. - Run the installer:
curl -fsSL https://cdn.coollabs.io/coolify/install.sh | bash. To pin a known-good release instead of latest, append the version, for examplecurl -fsSL https://cdn.coollabs.io/coolify/install.sh | sudo bash -s 4.4.6, as demonstrated in the dev.to guide. - Wait 5–10 minutes. The script installs Docker, the Traefik reverse proxy, and Coolify itself, then prints its next steps in your terminal — follow them.
- Open the dashboard at
http://YOUR-SERVER-IP:8000and log in. If you skipped step 2, whoever opens this URL first becomes root — so open it yourself, now. - Firewall check: port 8000 serves the dashboard, port 80 and 443 serve your apps and their certificates, and 22 is SSH. Leave the rest closed; the official docs ask you to confirm SSH access and the required ports before installing.
Two housekeeping notes for the day-one install. First, Coolify updates itself every night by default — turn automatic updates off in the settings if you want to stay on the version you tested, a tip from the dev.to walkthrough. Second, if you installed with the public registration open even briefly, check Settings for unexpected admin accounts; the clean fix is a reinstall with the root variables pre-set.
How do you deploy your first app from Git?
Deployment in Coolify follows a fixed shape: a project holds environments (production is the default), and environments hold resources — applications, databases, and services. Your first deploy creates one project, opens the production environment, and adds an application resource pointing at a Git repository.
- Create a project. In the dashboard, start a new project and select your server — "localhost" (this machine) is pre-configured and is the right choice for your first deploy, per the official quick-start flow.
- Add an application resource. Open the project's production environment and add a resource of type Application. For a public repo you need no credentials at all: choose "Public Git Repository" and paste the URL. For private repos, Coolify offers a deploy key or a GitHub App — the resource picker itself describes the GitHub App option as the one with automatic webhooks and pull-request previews, per the dev.to walkthrough.
- Check the build settings. After checking the repository, Coolify reads the default branch and detects the framework. In v4.4.x the default build pack is Railpack, which detects the language and builds an image with no Dockerfile; pick the Dockerfile or Docker Compose build pack instead if your repo ships one, per the same guide.
- Set the port correctly. This is the number-one first-deploy failure: the port is the one your app listens on inside the container (3000 for many Node apps), not the dashboard port. Get it wrong and the build succeeds while the domain returns errors, per the dev.to guide — so check your app's listen port before clicking deploy.
- Click Deploy and watch the logs. A small app builds in under a minute; the dashboard streams the build so you can see exactly which step fails if it does.
Once the deploy is green, Coolify hands you a generated test domain (a .sslip.io address, per Vultr's Coolify documentation) so you can click through the app before attaching your own domain. That test domain is also the fastest way to confirm the port setting was right.
How do you add a custom domain and free SSL?
Coolify provisions HTTPS automatically through its built-in Traefik reverse proxy and Let's Encrypt — you only have to point DNS at the server and ask for it. The trigger is the https:// prefix: when a domain is entered with that scheme, Coolify requests the certificate and Traefik renews it on its own, with no cron jobs or manual renewal, according to DigitalOcean's Coolify documentation.
- Create the DNS record. In your domain's DNS settings, add an A record pointing your hostname at the server's IP — for example
app.yourdomain.com → your-server-ip. A wildcard A record (*.yourdomain.com) also enables automatic subdomains for future apps and preview deployments, per MassiveGrid's 2026 Coolify guide. - Set the instance domain (recommended). In the dashboard go to Settings → Configuration and update the instance FQDN to your dashboard domain; Coolify provisions its own certificate through Let's Encrypt via Traefik, per the same guide.
- Add the domain to the app. Open the application, find the Domains field, and replace the test domain with your custom domain including the
https://prefix — that prefix is what triggers automatic certificate provisioning, per Vultr's documentation. - Redeploy. Save, then redeploy the app so Traefik picks up the new domain and certificate.
- Verify. Open the domain in a browser and confirm the padlock; the whole certificate flow typically completes in a few minutes once DNS has propagated.
Port 80 must be reachable from the internet during certificate issuance — Let's Encrypt validates over HTTP — so if you locked the firewall down hard in the install step, confirm 80 is open before you redeploy. DNS propagation is the usual reason a first domain attempt fails; wait out the TTL rather than re-saving repeatedly.
How do you add a database in Coolify?
Databases are resources, just like applications, and adding one takes about a minute. Open your project, add a resource of type Database, and pick PostgreSQL, MySQL, MariaDB, MongoDB, Redis, or the other supported engines. Coolify provisions the database container and — the part beginners love — automatically injects the connection string (for example DATABASE_URL) into the applications in the same project, per the dev.to walkthrough, so there is no copy-pasting credentials between screens.
Two practices to adopt from day one. First, turn on automated backups for any database you care about; Coolify supports scheduled backups to local disk or S3-compatible storage, and a database without a backup schedule is a future incident report. Second, keep databases in the same project as the apps that use them — that is what makes the automatic environment-variable injection work, and it keeps staging and production credentials from ever crossing.
If you are comparing this to a managed database service, the honest trade is cost versus convenience: Coolify's database costs you nothing beyond the VPS, but updates, backups, and restores are your job, whereas a managed service charges a premium to own those for you.
Coolify vs Vercel vs Portainer: which should you use?
These three get compared constantly, but they sit at different layers, and beginners pick wrong when a comparison pretends they are interchangeable. Coolify and Vercel are both deployment platforms with git-push workflows; Portainer is a container manager that shows you what is running but does not give you the Heroku-style "push to deploy" pipeline. Here is the honest breakdown:
| Coolify | Vercel | Portainer | |
|---|---|---|---|
| What it is | Self-hosted PaaS: git push → build → deploy → domain + SSL | Hosted PaaS: same workflow, on Vercel's cloud | Container manager: start/stop/inspect Docker containers via a UI |
| Where it runs | Your VPS or server | Vercel's infrastructure | Anywhere Docker runs |
| Pricing shape | Free (Apache 2.0); you pay only the server | Free tier, then per-seat/per-usage billing | Free community edition |
| Databases | One-click, same dashboard, auto-injected credentials | Separate products (Postgres, KV) with their own billing | You deploy the database container yourself |
| Best for | Developers who want Vercel's workflow with fixed, predictable cost | Teams that want zero server responsibility | Admins managing Docker hosts, stacks, and volumes visually |
| Biggest gotcha | You own uptime, updates, and backups | Costs scale with traffic and team size | No built-in git-push deployment pipeline |
The practical rule: if you want the Vercel experience without the meter, choose Coolify. If you already run Docker workloads and just want a better dashboard than the command line, our Portainer beginner guide is the one to read. And if you need someone else to own the servers entirely, stay on a hosted platform — self-hosting is a trade, not a free lunch.
How do you turn on automatic deployments?
Automatic deployment is the payoff of the whole setup: push to your repository and Coolify rebuilds and redeploys without you touching the dashboard. For public repositories you configure this manually; for private GitHub repositories connected through the GitHub App, Coolify sets up webhooks that fire on every push, with pull-request previews available, per the dev.to walkthrough.
After connecting the repository, find the automatic-deployment toggle in the application's settings and enable it — Coolify shows you the webhook URL it listens on. Push a small change (a comment in the code is enough for the first test) and watch the deployment queue: a new build should start within seconds. If it does not, the usual culprit is the webhook secret or a repository permission scope, not the app code.
One caution before you enable this on a production app: every push to the tracked branch goes live. Most teams point auto-deploy at main only after a pull-request review, or they keep a separate staging environment with auto-deploy on and promote to production manually.
Sources
Coolify official documentation, "Install Coolify (Self-hosted)" (fetched October 30, 2026) — the 2 CPU core / 2 GB RAM / 10 GB free disk minimum, the official install command, the ROOT_USERNAME / ROOT_USER_EMAIL / ROOT_USER_PASSWORD pre-creation variables, the supported Linux distributions, the fresh-server recommendation, and the firewall/SSH prerequisites. https://coolify.io/docs/installation
DeployLark, "Install Coolify on a VPS and Deploy Your First App" (dev.to, updated ~October 16, 2026, fetched October 30, 2026) — the ~63,000 GitHub stars, v4.0.0 stable April 27 2026 and 4.4.6 October 9 2026, the version-pinned install command, the dashboard on port 8000 with first-opener-becomes-root, the Public Git Repository resource, the Railpack default build pack on 4.4.6, the container-port gotcha, automatic DATABASE_URL injection, GitHub App webhooks with pull-request previews, and nightly self-updates. https://dev.to/deploylark/install-coolify-on-a-vps-and-deploy-your-first-app-4pf8
DigitalOcean documentation, "Coolify 1-Click Application" (updated ~October 22, 2026, fetched October 30, 2026) — deployment from Git repositories, Docker images, or Dockerfiles; automatic SSL/TLS via Let's Encrypt with automatic renewal; automatic deployments on git push; and the deploy flow (public repository or connected provider, auto-detected build settings, domain, deploy). https://docs.digitalocean.com/products/marketplace/catalog/coolify/
MassiveGrid, "How to Install Coolify on a VPS (Step-by-Step Guide for 2026)" (fetched October 30, 2026) — the wildcard A-record pattern for automatic subdomains, updating the instance FQDN under Settings → Configuration, and Traefik's automatic certificate provisioning and renewal. https://massivegrid.com/blog/how-to-install-coolify-on-vps/
Hostinger support, "How to use the Coolify VPS template at Hostinger" (fetched October 30, 2026) — the preinstalled "Ubuntu 24.04 with Coolify" VPS template, first-access admin account creation at http://your-vps-ip:3000, and the project/resource deployment flow. https://www.hostinger.com/support/9615197-how-to-use-the-coolify-vps-template-at-hostinger/
Frequently asked questions
Is Coolify really free?
Yes — Coolify is open-source under the Apache 2.0 license, so the software itself costs nothing and there is no per-app or per-seat billing, per the dev.to walkthrough. You still pay for the server it runs on (a small VPS starts around $5 a month), and you are responsible for updates and backups, which is the real cost of self-hosting.
What happens if someone opens my Coolify dashboard before I create an account?
The first person to open the dashboard becomes the root administrator — that is the documented behavior the dev.to guide warns about. If that happens on a public IP, assume the instance is compromised: reinstall and this time pre-create the root account with the ROOT_USERNAME, ROOT_USER_EMAIL, and ROOT_USER_PASSWORD variables from the official docs, so the registration page is never exposed.
Does Coolify work with private GitHub repositories?
Yes. Beyond public repositories (which need no credentials), Coolify supports a deploy key or a GitHub App for private repos, and the GitHub App route gives you automatic webhooks and pull-request previews, per the dev.to guide.
Can Coolify replace Vercel or Heroku for my side project?
For the core workflow — push code, get a live URL with HTTPS — yes, and that is exactly the comparison every guide makes. The difference is operational: Vercel owns uptime, scaling, and security patching while billing per usage, whereas Coolify gives you a fixed server cost and hands you the pager. For a side project with predictable traffic, Coolify is usually cheaper; for spiky traffic you would rather not think about, a hosted platform earns its fee.
How do I update Coolify itself?
Coolify updates itself automatically every night by default, and you can disable that in the settings if you prefer to update on your own schedule, per the dev.to walkthrough. Before any manual update, back up your databases and snapshot the server — a failed self-hosted update with no snapshot is the one mistake you only make once.