SEC.01
The playbook
The run starts read-only: the recon probes decide what happens next. The steps that follow are adapted to the distribution and state found — a real machine is rarely clean.
- 01recondistro and version: apt (Debian/Ubuntu) or dnf (RHEL/Fedora/Rocky/Alma)?
- 02reconCoolify already installed and its containers healthy? (yes → verify and skip, upgrade from the UI)
- 03reconDocker present? a snap Docker is incompatible (report it, the user must remove it)
- 04reconports 80, 443, 8000, 6001, 6002 free? (an existing nginx/Apache will conflict with the Coolify proxy)
- 05reconfree RAM, CPU and disk: Coolify wants ≥ 2 cores, 2 GB of RAM and 10 GB of free disk (official minimum); a dedicated server is recommended
- 06reconis a firewall (ufw or firewalld) active?
- 07actDownload the official installerverify
- 08actRun the Coolify installerdestructiveverify
- 09actResponds over HTTPverify
- 10actOpen the Coolify ports (only if a firewall is active)verify
SEC.02
What it verifies
Each step ships its own check. The run only moves on when the check passes, so what the recipe reports as done is what is actually on the server.
- 01verifyDownload the official installerVerified by
head -1 /root/coolify-install.sh - 02verifyRun the Coolify installerVerified by
docker ps --filter name=coolify --format "{{.Names}} {{.Status}}" - 03verifyResponds over HTTPVerified by
curl -s -o /dev/null -w '%{http_code}' --retry 30 --retry-delay 5 --retry-connrefused http://127.0.0.1:8000/ - 04verifyOpen the Coolify ports (only if a firewall is active)Verified by
ufw status 2>/dev/null | grep ALLOW; firewall-cmd --list-ports 2>/dev/null; true
SEC.03
Guardrails
Non-negotiable instructions the run must respect, whatever it finds on the server.
The official installer changes Docker and networking (destructive): snapshot first, a dedicated server preferably. Never run the installer through curl | bash: download it, then run it. Coolify manages its own reverse proxy and TLS: if a domain is provided, tell the user to point its DNS to this server and then enter it in the UI Settings. Create the admin account on first access: the first user to sign up becomes admin with root access. Back up /data/coolify/source/.env.
SEC.04
Variables
What you choose before launching — the recipe fills in the rest.
| Name | Meaning |
|---|---|
| ${domain} | Domain (optional, enables HTTPS) |
SEC.05
How a recipe runs in Servor
Servor is zero-knowledge: the platform cannot execute anything on its own. When you launch this recipe, a run reads the reconnaissance, plans the steps and asks for your approval. Each approved command is signed by your browser — with a key the server never sees — then relayed verbatim to the agent, which verifies the signature locally before executing.
search by intent — type “firewall”, get ufw
- 01Read-only reconnaissance before any change
- 02Every command signed by your browser, approved by you
- 03Each step verified before the run moves on, every run kept in the history
SEC.06
Deploy on Servor button
Maintain Coolify or a project that needs it? Put this button in your README or on your site: one click and your users install it on their own server.
Dark background
Light background[](https://servor.app/deploy/install-coolify)SEC.07
More self-hosted recipes
- 01VaultwardenVaultwarden password manager (Bitwarden-compatible) via Docker Compose, over HTTPS when a domain is provided.
- 02GiteaLightweight Gitea Git forge via Docker Compose (SQLite), web on localhost, Git SSH on a dedicated port.
- 03Uptime KumaUptime Kuma 2 uptime monitoring via Docker Compose, over HTTPS when a domain is provided.
- 04NextcloudNextcloud (file cloud) via Docker Compose: PostgreSQL, Redis, cron, admin created automatically.
- 05JellyfinJellyfin media server via Docker Compose, media folder mounted read-only, HTTPS when a domain is provided.
Verified recipe
Run this recipe on your server
Connect a server, launch the recipe, and approve each step as Servor executes and verifies it. Free plan, no card required.