Coolify v4.0.0 Is Here: A Sovereign Deployment Platform Beyond Heroku and Vercel

Managed Coolify on your own infrastructure — WZ-IT operates Coolify on Hetzner servers in German data centers: with patch management, backups, monitoring and CVE tracking. You deploy, we keep the platform secure and up to date. Schedule a free consultation

In late April 2026, after almost two years in beta, Coolify officially released version 4.0.0 (release notes on GitHub). The timing is anything but coincidental: Heroku switched into "sustaining engineering mode" in February 2026, Vercel bills routinely blow up mid-market budgets during growth phases, and the pressure toward sovereign infrastructure is rising — driven by NIS2, GDPR and a growing skepticism toward US cloud platforms.

Coolify is not the only project trying to fill this gap — but with over 52,000 GitHub stars, more than 280 one-click services and a production history at thousands of companies, it is the clear market leader in the open-source self-hosted PaaS segment. What the new version means technically and strategically, when the switch pays off, and where the honest limits lie — that is what this article is about.

Table of Contents

• Coolify v4: The End of the Beta Phase
• What the New Version Actually Delivers
• The Real Trigger: Heroku in Sustaining Mode
• Cost Comparison: Vercel and Heroku Against Coolify on Hetzner
• Sovereignty and Compliance: GDPR and NIS2
• When Coolify Is the Right Choice and When It Is Not
• From Vercel to Coolify: The Migration in 10 Steps
• Our Approach at WZ-IT
• Further Reading

Coolify v4: The End of the Beta Phase

Coolify is an open-source platform that turns a Linux server into a Heroku-, Netlify- or Vercel-like deployment environment. It takes over the tasks developers used to solve manually with Docker, Traefik, Let's Encrypt and cron jobs — and puts them behind a graphical interface.

In concrete terms: a developer connects a Git repository, hits "deploy", and Coolify handles the rest. Build via Nixpacks or a custom Dockerfile, reverse proxy via Traefik, automatic SSL certificates via Let's Encrypt, database provisioning for PostgreSQL, MySQL, Redis or MongoDB, preview deployments per branch, and backups to S3-compatible storage. All of it on servers the customer owns — not in a cloud whose bill surprises you every month.

The project was started by Andras Bacsai and has grown over the past two years into the most widely used self-hosted PaaS solution in the open-source space. Thousands of companies have been running Coolify in production for one to two years already — formally, however, in beta the entire time. With v4.0.0 that changes. The maintainer's release note reads accordingly soberly: "This does not mean it has no bugs, it has many, but we fix them every day." That is not modesty — it is the most honest description of a maturity statement you could imagine.

That is the core of the story: v4.0.0 is not a technical major leap, but a maturity signal. For developers already using Coolify, little changes on day one. For enterprise customers, on the other hand, who treated the "beta" label as a compliance showstopper, a formal hurdle disappears — and at the strategically most favorable moment imaginable.

What the New Version Actually Delivers

v4.0.0 bundles the features that emerged during the long beta phase and officially declares them stable. Four areas are relevant for companies.

Docker Compose as the Single Source of Truth

The Docker Compose build pack now fully supports docker-compose.yml as the central definition file for a deployment. Anyone who already describes their application as a Compose stack can have that file pulled directly from the Git repository — Coolify builds and operates the entire stack from it. The official Coolify documentation on Docker Compose describes the supported annotations in detail.

Two of them solve classic Docker pain points: with is_directory: true, Coolify creates a directory instead of a file for bind mounts — a frequent stumbling block in manual setups. And the content annotation allows file contents with dynamic environment variables to be defined directly in the Compose file.

Magic Environment Variables

Available since v4.0.0-beta.411 and officially matured with the stable release: the "magic environment variables" for Compose-from-Git sources. Coolify automatically generates consistent URLs, FQDNs, passwords and random strings — across service boundaries. A database password created in one container is available in the dependent container under the same name, without having to be passed through manually. For multi-service stacks, that is the difference between "works on the first try" and "three hours of env-variable debugging".

Multi-Server, Docker Swarm and the v5 Outlook

Coolify has supported multi-server setups for some time: one Coolify master manages N worker servers via SSH. For clustering, Docker Swarm is available — deliberately limited, with no native Kubernetes path.

The interesting part is the outlook Bacsai gives directly in the v4.0.0 release note: the biggest feature of v5 will be "full scalability in the core" — cloud infrastructure behavior on your own servers. Important for investment security: v4 will continue to be maintained in parallel ("doing v5 does not mean we won't continue to support v4"). Choosing v4 today does not lead into a dead end.

Postgres 18 and Security Hardening

Since v4.0.0-beta.463, Coolify ships native support for PostgreSQL 18 including pgvector 18 — relevant for anyone who wants to self-host vector search or AI-adjacent workloads. On top of that comes a series of security improvements that are stable with v4.0.0: an upgrade of the hash method for email verification, HMAC signature verification for webhooks, protection against data loss when deleting services, and fixes to the S3 backup endpoints. This is complemented by an API-first architecture with an improved REST API and a Coolify CLI that integrates AI assistance for debugging via natural language.

Anyone running Coolify in production should take the security aspect seriously: the platform had several critical CVEs in 2025/2026. The details, and why consistent patch management is mandatory, are summarized in our Coolify CVE overview 2025/2026.

The Real Trigger: Heroku in Sustaining Mode

The technical content of v4.0.0 only explains half the attention. The other half comes from the market.

Heroku, which defined the PaaS market more than a decade ago, switched into "sustaining engineering mode" in February 2026 — a euphemistic term for: no more new features, only bug and security fixes. For thousands of companies that have relied on Heroku for years, that is a clear strategic signal. The platform is not dying overnight, but it is no longer evolving. That triggers a migration wave.

In parallel, Vercel keeps fueling viral cost discussions. The best-known example is the creator platform Cara, which after a growth surge of 650,000 users was confronted overnight with a Vercel bill of around 95,000 US dollars. That is an extreme case — but the underlying pattern is everyday reality: bandwidth overages and function-invocation costs are the invisible pain points that make a Vercel bill unpredictable during growth phases.

The economic inflection point can be quantified: once the Vercel or Heroku bill regularly exceeds 50 to 100 euros per month, it is worth running the numbers on the self-hosted alternative. Above 300 euros per month, the answer is almost always clear — the only remaining question is whether to operate it yourself or have it operated.

Cost Comparison: Vercel and Heroku Against Coolify on Hetzner

The following table is based on a typical mid-market workload: a production web application with around 500,000 visits per month, an attached PostgreSQL database, a Redis cache and three staging environments for preview deployments. The Vercel and Heroku figures come from public price lists and real-world reports; the Coolify figures are based on Hetzner list prices. All figures are orders of magnitude, not quotes.

A vendor-independent cost comparison by MassiveGRID arrives at around 601 US dollars per month for Vercel versus roughly 90 US dollars for Coolify on Hetzner for a comparable workload — a saving of about 85 percent.

The raw number, however, is only half the truth. The important question behind the cost is: what does your own self-hosting effort cost? Anyone running Coolify entirely themselves saves on the cloud bill but pays with their own time — regular updates, reacting to security CVEs, monitoring setup, backup verification, disaster-recovery tests. And the infamous "2 a.m. incident" when the server falls over because of a full Docker build cache.

This is exactly where a managed service makes sense: the saving compared to Vercel stays substantial — typically 70 to 80 percent instead of 85 to 90 — but the operational effort moves to the service partner.

Sovereignty and Compliance: GDPR and NIS2

The cost advantage is what convinces decision-makers first. Strategically, what lies underneath is often more important.

Data location. Coolify on Hetzner means data residency in Falkenstein, Nuremberg or Helsinki — not in a US cloud. That is GDPR-compliant without the usual construction of standard contractual clauses and transfer impact assessments. And it places the data outside the reach of the US CLOUD Act. Coolify is not tied to Hetzner — the platform runs on any Linux server with SSH access — but the recommendation for Hetzner comes from the Coolify project itself, and Coolify is available as a pre-installed app in the Hetzner Cloud Console.

NIS2. A self-hosted platform is more auditable than a black-box PaaS. Anyone running Coolify on their own infrastructure can document patch levels, access paths and the supply chain — exactly what the NIS2 risk-management obligations (Art. 21) require. A managed PaaS can often only provide this evidence in a limited way.

Anti lock-in. Coolify stores all configurations directly on the customer's server. Bacsai puts it like this: "All configurations for your applications/databases/etc are saved to your server. So, if you decide to stop using Coolify, you could still manage your running resources." There is no migration hell like leaving Heroku or Vercel — you lose the automation and convenience, not the running workloads.

When Coolify Is the Right Choice and When It Is Not

Coolify is not the only self-hosted PaaS, but by far the largest. The following overview places the serious open-source alternatives.

Three reasons make Coolify the pragmatic default unless a very specific requirement speaks against it: the size of the community (three to four times as many stars as the next self-hosted competitors), the service template catalog (over 280 one-click services, more than any other open-source alternative), and the official Hetzner integration.

Just as important for an honest assessment is when Coolify is not the right choice:

• Multi-region failover: Real failover across multiple regions needs external load balancers and is not Coolify's strength. Anyone who strictly needs it should evaluate managed Kubernetes.
• Built-in observability is missing: Coolify does not ship web analytics, error tracking or session replay. These tools must be added — as self-hosted services (Uptime Kuma, Plausible, Sentry) or as additional SaaS subscriptions.
• Self-hosting means responsibility: Updates, backups, CVE monitoring and disaster-recovery tests need to be communicated honestly. Anyone who does not want to handle that themselves needs a managed service partner.
• Kubernetes-native patterns: Anyone who needs service mesh, real auto-scaling across dozens of nodes or specific K8s operators is better served by a Kubernetes platform.

From Vercel to Coolify: The Migration in 10 Steps

This checklist accompanies the migration of a typical Next.js or Node.js web application from Vercel to Coolify on Hetzner. It is deliberately pragmatic and covers the points that cost time in practice.

1. Inventory. Document the complete Vercel configuration: all environment variables (including in preview and development environments), custom domains with DNS settings, active integrations, edge functions, middleware patterns, cron jobs and build settings.
2. Identify Vercel specifics. Edge functions, incremental static regeneration and Vercel-specific middleware do not run one-to-one on Docker. Assess these points before the migration and replatform where necessary.
3. Server sizing. For most mid-market workloads, a Hetzner CCX instance as a Coolify worker plus a small separate instance for Coolify itself is enough. Higher loads scale vertically or via additional worker servers.
4. Coolify installation. On Hetzner, selecting the pre-installed Coolify image during server creation is enough. Then create an admin account, enable MFA, verify the first server connection.
5. Set up Git connection. Create a dedicated GitHub app in Coolify and link it to the target repository — do not use a personal token, which avoids permission conflicts.
6. Test deployment. Before the real cut, set up a staging environment: create a project, select the repository, choose the build pack (Nixpacks for standard frameworks, Dockerfile for custom setups), transfer environment variables, deploy on a subdomain.
7. Plan database migration. Keep the external database and use Coolify only for the app — or migrate the database to Coolify as a one-click service as well. With the second option, test the transfer via pg_dump/pg_restore on staging first.
8. Prepare DNS. 24 to 48 hours before the cut, lower the DNS TTL of the production domains to 300 seconds. That significantly shortens the later switchover window.
9. Production cut. Outside peak traffic hours, switch the DNS A record. Coolify creates the SSL certificate automatically. Test all critical user flows, watch logs for 30 minutes — and keep the Vercel deployment running in parallel for at least 48 hours in case a rollback becomes necessary.
10. Cleanup and observability. After 48 to 72 hours of stable operation, archive the Vercel project. On the Coolify side, add the observability that Vercel brought along (monitoring, analytics, error tracking), configure backups and define a patch strategy.

Most migrations fail not on the technology but on incomplete documentation of the existing configuration and on Vercel-specific code that only surfaces during the migration process. A realistic window for a standard migration is one to three working days plus a week of observation.

Our Approach at WZ-IT

Coolify v4.0.0 is an excellent platform — but self-hosting means responsibility. We take exactly this operational part off companies' hands, without sacrificing the sovereignty and cost advantage.

1. Assessment instead of gut feeling. We run the numbers on the concrete workload: how high is the current Vercel or Heroku bill, which platform features are actually in use, and at what point does the switch pay off? If the bill is below the threshold, we say so.

2. Infrastructure on Hetzner. We set up Coolify on dedicated Hetzner servers in German data centers — in the two-server structure recommended by the project: one server for Coolify management, one (or more) for the applications.

3. Migration as a service. We do the move from Vercel or Heroku once, properly — from inventory through test deployment to the production cut with rollback safety.

4. Managed operations. Patch management, CVE tracking, automatic backups, monitoring and 24/7 readiness are part of operations. The Coolify CVE history shows why this is not an optional extra.

5. No lock-in trap. Because Coolify stores all configurations on the customer's server, the infrastructure remains transferable at any time. For us, managed service means relief, not dependency.

Whether as Managed Open Source in a complete package or as targeted support around Coolify expertise — the platform runs on European infrastructure, the operation stays in European hands.

Further Reading

• Coolify: Deploy a Next.js App in 4 Steps — the practical entry point to the platform
• Coolify CVE Overview 2025/2026: Vulnerabilities and the Need to Update — why patch management is mandatory
• GitHub Actions Pricing Change 2026: Open-Source Alternatives — the same pattern in CI/CD
• Managed Open Source at WZ-IT — self-hosted software, fully operated
• Coolify Expertise at WZ-IT — consulting, setup and operations

Watching your Vercel bill, but no team for self-hosting? We run the numbers on your workload honestly and take over migration and operation of Coolify on sovereign infrastructure. Talk to us about Managed Coolify

As of May 2026. Version details and feature states refer to the Coolify release v4.0.0 from late April 2026. Open-source projects evolve quickly — for the latest details, check the official release notes.