Coolify, your own PaaS on your own server

Coolify, your own PaaS on your own server

Coolify is a self-hosted deployment platform: you install it on your own server and get deployments straight from a repository, databases, TLS certificates and preview environments. The coollabsio/coolify repository holds roughly 60.8 thousand stars and an Apache 2.0 licence, and the current stable release carries the number 4.3.9, dated 18 August 2026.

What Coolify does on your server

After installation you get a web panel that manages Docker on one machine or across several at once. You point it at a repository, Coolify builds an image from it, starts a container and wires it into a reverse proxy that issues the certificate itself. That is the entire mechanism, with no magic in it, but plenty of glue you no longer have to write yourself.

The build layer rests on build packs. Your options are Nixpacks, which detects the project's technology on its own, a static mode served by Nginx, your own Dockerfile, Docker Compose for multi-part applications, and a ready image from a registry. The code source can be a public repository, a private repository connected through a GitHub App, or one connected through a deploy key.

Traffic is handled by Traefik or Caddy, whichever you pick. Certificates are issued automatically, provided port 80 is open, since domain verification runs through it. For each application you declare the ports to expose, and the first of them becomes the default port for container health checks.

Beyond applications, Coolify runs databases and ready-made services. Support covers PostgreSQL, MySQL, MariaDB, MongoDB, Redis and several other engines, while the one-click service catalogue counts more than 280 entries according to the repository description. Each of those is simply a prepared Compose file that you can then override with your own.

What Coolify does not do also needs saying plainly. There is no content delivery network, no edge functions, no horizontal scaling that starts itself under load. Nor is there any answer to the fact that your server sits in one place on the planet. If you need content close to users across a dozen regions, Coolify will not replace that, and putting Cloudflare in front of it makes more sense.

Version, licence and project health

The project has existed since January 2021 and moves quickly. The repository carries 5,318 forks and 670 open issues, is not archived, and the last change on the main branch dates from 20 August 2026. Behind all of it stands the Hungarian company coolLabs Solutions Kft.

The version number comes with a small trap that deserves attention when pinning an image. The versions.json file on the main branch lists 4.3.10 for the v4 channel, yet the newest published stable release is 4.3.9. On top of that, 4.4-rc.1 exists and is marked as a prerelease. The number on the main branch therefore runs ahead of what has actually shipped, and if you build automation around that file, check both sources.

# what counts as the current version: main branch versus published release
curl -s https://raw.githubusercontent.com/coollabsio/coolify/main/versions.json

curl -s https://api.github.com/repos/coollabsio/coolify/releases/latest \
  | grep '"tag_name"'

The licence is straightforward, which is rare in this category of tooling. The repository root holds a single LICENSE file with the full Apache License 2.0 text, the GitHub programming interface reports apache-2.0, and there is no separate directory holding code meant for commercial customers. There is also no add-on package whose installation would pull in a proprietary licence. Everything you see in the paid variant lives in that same open source.

That uniformity has a practical consequence: the self-hosted variant is not a cut-down edition. The vendor keeps nothing behind a licence gate, so you do not have to check at every release whether the feature you rely on has moved into a paid directory.

The risk lies elsewhere. The project carries one dominant maintainer and a company of modest scale, while release numbering advances several times a week. An update can change proxy behaviour or the way Compose files are generated, and you will find that out on your own installation rather than on the vendor's staging environment.

Server requirements, installation and ports

The hardware minimum stated in the documentation is two processor cores, 2 GB of memory and 30 GB of free space. The vendor notes that Coolify will probably start on less, but recommends headroom, because your applications and build processes share that same memory. The architecture must be 64-bit, either amd64 or arm64.

The list of supported systems is broad: Debian-based distributions, Red Hat-based ones, SUSE-based ones, Arch Linux, Alpine Linux and 64-bit Raspberry Pi OS. The install script handles automatically only the long-term support editions of Ubuntu, meaning 20.04, 22.04 and 24.04. On Ubuntu outside that list, 24.10 for instance, manual installation remains. On some distributions, AlmaLinux is the one named, Docker has to be installed beforehand. The required Docker engine is version 24 or newer.

# minimum: 2 cores, 2 GB RAM, 30 GB free space, amd64 or arm64
curl -fsSL https://cdn.coollabs.io/coolify/install.sh | sudo bash

# ports required when reaching the panel by the server's IP address
# 8000 panel, 6001 real-time communication, 6002 terminal
# 22 SSH, 80 certificate issuance, 443 HTTPS traffic

# the public key must land on root on every managed server
cat ~/.ssh/coolify.pub >> /root/.ssh/authorized_keys

Port 6002 serves the in-panel terminal and has been required since version 4.0.0-beta.336. Once your own domain points at the panel, ports 8000, 6001 and 6002 can be closed, because traffic will run through the proxy on 443. That leaves 22, 80 and 443.

Closing ports comes with a catch that surprises people used to ordinary servers. Docker writes its own iptables rules based on address translation and can bypass UFW, so a block written in UFW will not behave the way you expect. The documentation recommends a firewall on the cloud provider's side, and where the provider offers none, the community-maintained ufw-docker tool.

The connection to every managed server runs over SSH with key authentication, and the public key has to land in the root user's authorized_keys file. Coolify can generate a key pair from the panel. You may also keep the instance and the applications on one machine, but the documentation advises against it, since build load can take the panel down at the moment you need it most.

With several servers, one thing has to be understood to avoid losing hours on DNS diagnosis. Every connected server runs its own proxy and handles traffic for its own applications. The main server provides only the panel, makes the SSH connections and performs health checks, and does not forward traffic onward. You therefore point the domain at the address of the server the application runs on, not at the Coolify instance.

Repository deployments, variables and preview environments

Deploying on every push works only for repositories connected through a GitHub App, because only then does Coolify receive webhooks. The same dependency applies to preview environments started automatically: the switch exists in that mode alone and is off by default. With a public repository or a deploy key, what remains is triggering a deployment manually for a chosen pull request.

The preview environment address is built from a template, {{pr_id}}.{{domain}} by default. A pull request numbered 123 on the domain example.com therefore lands at 123.example.com, which calls for a wildcard DNS entry and a certificate covering subdomains. When a resource has several domains, the first one goes into the template.

Environment variables carry two independent switches: availability during the build phase and availability in the running container. Both are on by default. The panel offers a developer view where you edit the whole set as a plain key-and-value file.

# developer view: the whole variable set in .env format
NODE_ENV=production
DATABASE_URL=postgres://app:$DB_PASSWORD@postgres:5432/app_production

# a variable predefined by Coolify, the revision the image was built from
NEXT_PUBLIC_COMMIT=$SOURCE_COMMIT

# shared variables: team, project, environment
SMTP_HOST={{team.SMTP_HOST}}
SENTRY_ENVIRONMENT={{environment.NODE_ENV}}

Two fields can save you an evening. The Literal switch turns off reference expansion, so a password containing a dollar sign stops being read as the name of another variable. The Multiline switch preserves line breaks for private keys and certificates, and a multiline value is wrapped in single quotes at deployment time, which blocks shell interpretation. Multiline values and locked secrets are editable only in the normal view.

Build-phase secrets are a separate matter. By default build variables go through as --build-arg, their values stay in the image metadata and show up in docker history. The Docker build secrets option switches that to --secret id=KEY,env=KEY, requires BuildKit and a Docker engine from version 18.09, and Coolify adds the syntax directive and the mounts itself.

# syntax=docker/dockerfile:1
FROM node:22-alpine
WORKDIR /app
COPY package.json package-lock.json ./
RUN --mount=type=secret,id=NPM_TOKEN npm ci
COPY . .
RUN --mount=type=secret,id=NPM_TOKEN npm run build
CMD ["node", "server.js"]

Within a given step the secret value is visible as an environment variable and leaves nothing in the image layers. Coolify derives a digest from the secrets, stored as COOLIFY_BUILD_SECRETS_HASH, and uses it to invalidate the build cache only once a secret has actually changed. If BuildKit is missing on the build server, the mechanism quietly falls back to --build-arg, so verify it explicitly when sensitive tokens are involved.

Publishing a port on the host costs you rolling updates, since two instances cannot hold the same port at once. Rolling back works only on images available locally. Health checking is on by default for every container, and Traefik will not route traffic to a container that defines a check and fails it. That is the most common cause of a 502 right after the first deployment.

Backups, updates and being on call

This is the heart of the choice between Coolify and a managed service. The panel automates database dumps and can ship them to any S3-compatible storage, but you configure the schedule, you watch the space and, more importantly, you verify that a restore actually works. A backup nobody has ever restored is a backup in name only.

# a custom-format dump, exactly what Coolify runs for PostgreSQL
pg_dump --format=custom --no-acl --no-owner --username postgres app_production

# restoring on a different machine
pg_restore --verbose --clean -h localhost -U postgres -d postgres \
  pg-dump-postgres-1697207547.dmp

# the equivalents for the other engines
mysqldump -u root -p"$MYSQL_ROOT_PASSWORD" app_production
mariadb-dump -u root -p"$MYSQL_ROOT_PASSWORD" app_production
mongodump --authenticationDatabase=admin --uri="$MONGO_URI" --gzip --archive=dump.gz

The custom format in PostgreSQL is not an SQL file, so you restore it through pg_restore rather than psql. Put a quarterly restore onto a test machine in your calendar, because that is the only way to learn about a problem before the day of the outage.

Instance updates can be left automatic or run by hand. Either way the responsibility is yours: nobody will roll back a failed release for you, nobody picks up the phone when the proxy stops renewing a certificate, and nobody notices that the disk filled up with layers of old images. That last one happens often, which is why Coolify ships a separate Docker cleanup mechanism that has to be switched on deliberately.

Then there is your dependence on the server provider. When the only machine in the only data centre goes down, the application stays unreachable until somebody brings it back. Managed vendors spread that risk across many regions and price it in. With Coolify you pay less, and you are that risk spreading.

It pays to count this cost in hours before counting it in money. If you keep a dozen of your own projects running, an hour a month on updates and reviews is an excellent price. If you serve one client in production and have nobody covering for you during a holiday, that same hour is sometimes a bad one.

Pricing and the managed variant

The self-hosted variant is free forever, with no feature restrictions and no cap on deployments, teams, users or connected servers. You pay only for the server it sits on.

Coolify Cloud costs 5 dollars a month as a base price covering two connected servers, plus 3 dollars a month for each additional server. Annual billing takes 20 percent off the bill. What you buy in that variant is only the panel running on the vendor's infrastructure: you bring your own application servers, from any provider, and applications still deploy onto your machines.

The differences come down to operations. In the cloud the vendor maintains the panel, performs its updates and backups, provides the app.coolify.io address without configuring a domain of your own, and sends email alerts without you standing up an SMTP server. On servers connected to the cloud variant, opening ports 22, 80 and 443 is enough. One limit is stated outright in the vendor's own table: the number of teams is unlimited, but each additional team requires a separate subscription.

A point that matters for risk assessment: the cloud is built on that same open source, so cancelling the subscription does not take the tool away from you. You are left with the same containers on the same servers and can stand the panel up yourself. That is a very different position from closed platforms, where leaving means rewriting the deployment configuration from scratch.

Coolify against the alternatives

The choice is really a decision about what you would rather pay with. Under steady, predictable load a single server at a dozen or so dollars a month will carry a dozen applications that would cost a multiple of that with a managed vendor. Under spiky traffic, and with a team that has nobody on infrastructure, usage-based billing and somebody else's on-call rota are worth their price.

There is also a third route, useful before you put anything on a server at all. Showing a client a work-in-progress build from your laptop needs no more than a tunnel such as Portless, with nothing permanent to stand up.

The closest relative is Dokploy, which solves the same problem but splits its licence differently. The core is Apache 2.0, so reselling hosting to clients is allowed, while directories marked proprietary fall under a source-available licence of their own, and production use of what sits inside them, meaning single sign-on, SCIM, the audit log and custom roles, requires a commercial agreement. The second thing worth noting during an audit: the licence file there is named LICENSE.MD in capitals, so a tool looking for LICENSE or LICENSE.md simply will not find it.

Common mistakes

The first is installing Coolify on a machine that already runs something. The documentation recommends a fresh server, because the installer adds Docker, a proxy and its own networks, and a conflict on port 80 or an existing Nginx configuration can block certificate issuance.

The second is relying on UFW. Docker writes iptables rules with address translation that bypass UFW, so a port blocked in UFW can still be reachable from the network. Use the provider's firewall or ufw-docker.

The third is pointing DNS at the main server in a multi-server setup. The machine holding the panel does not forward traffic to applications running elsewhere, so the record has to name the target server.

The fourth is expecting automatic preview environments on a repository connected by a deploy key. That feature, like deployment on push, works only through a GitHub App connection.

The fifth is keeping tokens in build variables without Docker secrets. Values passed as --build-arg remain in image metadata and can be read by anyone with access to the image.

The sixth is configuring backups without a single restore attempt. A PostgreSQL dump in custom format is restored through pg_restore rather than psql, and it is better to learn that on a quiet Tuesday than during an outage.

The seventh is skipping Docker cleanup. Old images and build layers grow until they fill the disk, and then everything stops at once, including the panel you would use to fix it.

FAQ

Is Coolify genuinely free?

Yes. The self-hosted variant is free forever, with no feature restrictions and no cap on servers, deployments or users. Only Coolify Cloud is paid, meaning the panel maintained by the vendor, at 5 dollars a month for two connected servers plus 3 dollars for each additional one. The application servers are yours in both variants.

What server is enough to start with?

The documentation gives a minimum of two cores, 2 GB of memory and 30 GB of space, on amd64 or arm64. The vendor recommends headroom above that minimum, because build processes share the same memory. For anything serious, separating the panel machine from the application machines makes sense.

Will Coolify replace Vercel?

For repository deployments, certificates and preview environments it behaves similarly. It will not replace a content delivery network, edge functions or presence in several regions at once, because the application sits on your server in one location. Spreading content geographically needs an extra layer.

What happens if I cancel the cloud subscription?

The cloud is built on the same open source under Apache 2.0, and applications run on your servers the whole time. You can install the panel yourself and carry on running the same resources. You do not lose access to the tool along with the subscription.

Can Coolify run on a Raspberry Pi?

Yes, on 64-bit Raspberry Pi OS. The arm64 architecture is supported and the documentation carries a dedicated setup guide. Keep the minimum memory requirements in mind, and remember that a memory card is a poor medium for a database serving production.

Which ports do I have to open?

Reaching the panel by IP address needs 8000 for the panel, 6001 for real-time communication, 6002 for the terminal, plus 22, 80 and 443. Once your own domain points at the panel, the first three can be closed. Servers connected to Coolify Cloud need only 22, 80 and 443.

Documentation lives on the Coolify site, the terms of the managed variant on the pricing page, and the source code in the GitHub repository.