What Is Coolify? A Technical Guide to Architecture, Features, and Server Requirements

Most teams do not leave a managed platform because it stopped working. They leave because the invoice stopped tracking the value of the workload and started tracking the traffic instead, and a successful launch and a scraper hammering an API endpoint produce the same billing event. Coolify exists for teams that have decided the deployment experience is worth keeping, and the metered bill is not. This guide covers how its internals work, what each feature does and where it stops working, what to buy to run it properly, and where it still loses to Heroku and Vercel.

What Is Coolify and How Does Its Architecture Work?

What Is Coolify? (Core Definition)

Coolify is an open-source, self-hosted platform-as-a-service, licensed under Apache 2.0, that deploys applications, databases, and services as Docker containers on servers you own or rent. It reproduces the parts of Heroku, Netlify, and Vercel that developers value most, namely Git push-to-deploy, automatic TLS, managed databases, and a web dashboard, and runs them on your own infrastructure instead of a vendor’s.

The current stable release is v4.1.0, published in May 2026, and the project carries roughly 55,900 GitHub stars alongside more than 3,600 paying customers on its hosted control plane. It ships with 280 or more one-click services, connects to GitHub, GitLab, Bitbucket, and Gitea, and provisions eight database engines from the dashboard.

One distinction deserves stating early, because most definitions blur it. Coolify is a control plane, not a host. Even the paid Coolify Cloud tier does not run your applications; it runs the management interface and connects over SSH to servers you supply. What you self-host or subscribe to is orchestration, and the compute is always yours, which is precisely why the server underneath Coolify carries more weight than it does on a managed platform.

Why Choose a Self-Hosted PaaS Over Heroku or Vercel?

The cost argument is usually made badly, as a vague claim that self-hosting is cheaper. The specific version is more persuasive. One modest production application on Heroku means a Standard-1X dyno at $25 per month plus a Standard-0 Postgres instance at $50 per month, which is $75 before a background worker, a cache, or a second environment exists. Vercel Pro is $20 per seat per month with a $20 usage credit, after which edge requests, data transfer, function invocations, and active CPU time all meter separately. Both figures are defensible for what they deliver, but they are a function of traffic, so the platform costs most at the exact moment a product starts working. Flat-rate infrastructure inverts that relationship, because capacity is purchased in advance and the marginal cost of the tenth application deployed onto a server that already has headroom is effectively zero.

Data ownership is the second argument, and for Canadian organizations it is frequently the deciding one. Contractual obligations, provincial privacy legislation, and public-sector procurement rules often require that customer data remain in Canada, and running your own platform on Canadian infrastructure removes the question rather than answering it with a vendor’s regional setting. Vendor lock-in deserves the same precision: Coolify produces standard Docker containers and Compose files, and its documentation notes that your configuration remains on your server even if you stop using Coolify, so the exit path is running docker compose up on a different machine.

The counterweight belongs here rather than buried at the end. Choosing Coolify trades a metered invoice for an unmetered time commitment, because kernel patching, disk management, backup verification, and incident response all become your team’s responsibility. If nobody on that team is comfortable at a Linux shell prompt at two in the morning, the saving is not real.

How Coolify’s Architecture Works Under the Hood

Coolify is best understood as five layers, each with a practical consequence for how you size and operate the server beneath it.

The control plane is a Laravel application written in PHP, with a Blade, Livewire, and Tailwind front end, running in Docker alongside its own PostgreSQL state database, a Redis instance, and a Soketi WebSocket service that drives live build logs. This layer stores configuration and issues instructions, and it does not sit in the path of your application traffic. If the Coolify dashboard is down, your deployed applications keep serving.

The connection layer is plain SSH with key authentication, because Coolify installs no agent on managed servers. It adds a public key to the root user’s authorized_keys file and issues Docker commands over that connection, which explains the platform’s most-questioned requirement: root access is expected and non-root operation is not yet fully supported. It also defines the security posture you are accepting, since the control plane holds a key granting root on every server it manages.

The build layer is where operational surprises originate. Nixpacks, the default build pack, inspects a repository, infers the language and framework, and produces a container image without requiring a Dockerfile; alternatives include static sites, custom Dockerfiles, Compose stacks, and pre-built registry images. The consequence competing guides omit is that these builds execute on the target server by default, so compiling an application and extracting image layers compete for CPU, memory, and disk I/O with the containers already serving production traffic on that host.

The routing layer is Traefik, currently v3, configured automatically from container labels as resources deploy. It discovers new containers, creates routes, requests Let’s Encrypt certificates, and renews them without manual intervention. Caddy is selectable as an alternative but is thinly documented and not the recommended path, and Nginx remains unimplemented, so Traefik is the only fully supported proxy.

The multi-server topology carries the clearest purchasing consequence. Proxy state is held per server, so each connected server runs its own Traefik instance and serves its own applications directly rather than routing traffic through the Coolify host. The control plane is therefore not in the data path and need not be sized for aggregate traffic, so a small, inexpensive node can manage a fleet of much larger application servers. Running one application across several servers is a different problem, and it still requires a load balancer you provide yourself.

Figure 1: The Coolify deployment and request path, from git push to live container.

What Are Coolify’s Core Features and How Do They Work?

Git Push-to-Deploy and Automated Builds

The deployment cycle begins with a webhook. A push to the tracked branch fires a repository webhook; Coolify pulls the commit, selects the configured build pack, builds an image, starts a new container, and moves traffic to it. Pull requests can additionally trigger preview deployments on their own URLs, generated from a template that defaults to {{pr_id}}.{{domain}}, with full automation available for repositories connected through a GitHub App rather than a deploy key.

Zero-downtime deployment is where accuracy matters more than enthusiasm. Coolify performs rolling updates by starting the replacement container, waiting for it to pass a health check, and only then stopping the previous one. That behaviour requires four conditions to hold at once: a defined, passing health check, Coolify’s default container naming scheme, a deployment that is not Docker Compose-based, and no port mapped directly to the host. Compose is how a large share of self-hosted stacks are deployed, and it uses static container names that prevent two instances from coexisting, so many Coolify users believe they have zero-downtime deployments and, because of that one condition, do not.

Rollback carries a similar caveat, since Coolify can redeploy a previous version only from Docker images still present locally on the server. Once an image has been pruned to reclaim space, that version is no longer a rollback target, which makes your cleanup configuration and available disk capacity the real definition of your recovery window.

One-Click Database Provisioning

Coolify provisions eight database engines directly: PostgreSQL, MySQL, MariaDB, MongoDB, Redis, DragonFly, KeyDB, and ClickHouse. Anything outside that list still runs as an ordinary container, so the limit is on dashboard convenience rather than capability. Each provisioned database is reachable by application containers over Docker’s internal network, with connection details injected as environment variables, so a production database never needs a publicly exposed port.

Automated backups run on a schedule to any S3-compatible storage target, with one-click restore from the dashboard. The phrase “S3-compatible” does important work there, because the destination is your decision rather than the platform’s. Send backups to storage physically separate from the server holding the database, since a backup written to the same disk protects you from a bad migration and from nothing else.

Multi-Server Orchestration and Role-Based Access Control

A single Coolify installation manages many servers, each added by pasting an IP address and authorizing an SSH key. Because every server carries its own proxy and workloads, this is the mechanism for separating concerns that should not share a host, and the pattern worth adopting early is a small control-plane node, application servers sized to their traffic, and a separate build server so compilation never competes with production containers.

Access control operates at the team level, where teams own projects and environments, and members receive roles that determine what they can view and change. That is adequate for an agency separating client work or a startup separating engineering from contractors, but it is not a fine-grained policy engine. A browser-based terminal, a REST API, and notification integrations complete the operational surface.

Automated SSL, Backups, and the 280+ One-Click Service Catalogue

TLS is handled end to end. Traefik requests Let’s Encrypt certificates for any domain pointed at the server and renews them automatically, including wildcard configurations, and auto-generated sslip.io hostnames are available for testing before DNS is ready. For most teams, this removes the last recurring manual task in the deployment process.

The catalogue of more than 280 one-click services is the feature that converts evaluators into users, because self-hosting n8n, Supabase, Plausible, Ghost, or Uptime Kuma becomes a form submission rather than an afternoon of debugging Compose files. Monitoring deserves a realistic description alongside that: Coolify reports container health and server resource usage and sends notifications when something fails, which covers availability, but it is not an observability platform and does not replace metrics, tracing, or log aggregation.

What Server Do You Need to Run Coolify, and Why Does Infrastructure Choice Matter?

Minimum vs. Recommended Server Specs for Coolify

Coolify’s documented minimum is 2 CPU cores, 2 GB of RAM, and 30 GB of free disk, on AMD64 or ARM64, with Docker Engine 24 or newer. Supported operating systems are broad, covering Debian and Ubuntu, RHEL-family distributions including CentOS, Fedora, AlmaLinux and Rocky, plus SUSE, Arch, Alpine, and 64-bit Raspberry Pi OS. The automated installer, a single curl command piped to sudo bash, officially targets Ubuntu LTS 20.04, 22.04, and 24.04, and Docker installed through snap is explicitly unsupported.

That 2 GB minimum is the most quoted and least useful number in the Coolify ecosystem, because it describes the control plane sitting idle rather than a Nixpacks build installing a dependency tree, compiling assets, and writing image layers on the same host at once. A 2 GB server will run a modest Node application without complaint and still fail to build it, and adding swap converts that failure into build times measured in many minutes. Disk is the second underestimated line, since image layers, build caches, and volumes accumulate steadily, and because rollback only works against locally stored images, free disk space is not comfort but the length of your recovery history.

The tiers below are sized against what Docker builds consume rather than what the software will technically start on. For teams that want to test a tier before committing, N6 Cloud’s hourly-billed Cloud Server plans make it inexpensive to run a realistic build on the exact specification you are considering and then destroy it.