Coolify

Open-source, self-hostable PaaS that gives you most of Heroku/Netlify/Vercel — push-to-deploy apps, managed databases, and 280+ one-click services — running entirely on servers you own, billed by your VPS instead of per-seat/usage. Source: coollabsio/coolify, https://github.com/coollabsio/coolify, 2026-06-12

Coolify (by Andras Bacsai / coollabsio) is the most prominent open-source answer to "I want Vercel's DX without Vercel's bill." You point it at any VPS (Hetzner, DigitalOcean, a home server), run a one-line installer after inspection, and get a web control plane that builds from Git, manages SSL, and deploys static sites, full-stack apps, databases, and services as Docker containers. On 2026-08-11, coollabsio/coolify remained Apache-2.0 with 60,386 GitHub stars, 5,248 forks, default branch v4.x, stable release v4.1.2, and active branch commit b12524c. Those popularity and freshness facts support retention; they do not prove production fit. Source: Coolify repository; captured repository state, 2026-08-11

What it does

Why it shows up in Kevin's signal

Coolify is the flagship of the "RIP Vercel bills" / anti-PaaS turn — developers reacting to per-usage cloud pricing by moving back to a single owned box. The bookmarked launch framed it exactly that way ("RIP Vercel bills... runs entirely on your own server"), and the reviewed screenshot preserves the README-era pitch: open-source/self-hostable Heroku/Netlify/Vercel alternative, one-command installer, owned hardware via SSH, no vendor lock-in, 280+ services, and built-in databases. The image's 4.0.0-beta.470 badge is historical evidence, not the current version authority. Source: X/@sentient_agency and local image review, 2026-07-04

The same sentiment recurs across the corpus: builders replacing managed Vercel+Supabase stacks with k3s/Flux CD and self-hosted Postgres, and the BYOC ("bring your own cloud") posture for selling to enterprise. The @BadAINoData reply names the concrete anti-PaaS bundle: a dedicated server, k3s, Flux CD, Envoy Gateway, self-hosted Supabase, CloudNativePG, Redis, and Qdrant replacing small managed Vercel/Supabase plans. The @albert_ thread is the enterprise sales version of the point: be on-prem ready by containerizing, using Postgres behind an ORM, avoiding one-cloud lock-in, and provisioning infra with Terraform. The self-thread adds the important operational boundary: do BYOC, not unmanaged customer self-hosting, so the vendor can still operate the software while the customer keeps it inside their environment. Source: X/@BadAINoData, 2026-04-24; Source: X/@albert_ thread, 2026-05-22

It sits opposite the SaaS Stack 2026 default (Vercel + Supabase + Stripe) on the build-vs-own axis, complements Floci (run AWS-shaped services locally) for offline/integration testing, and overlaps Render Cloud Platform as a managed-deploy alternative — except Coolify hands you the control plane instead of renting it.

In Modern Web VPS Stack, Coolify is optional. Use it when a Hetzner server should feel like a small PaaS for TanStack/Vite apps, databases, services, domains, TLS, env vars, and previews. Skip it when Docker Compose/systemd plus a reverse proxy is simpler and the app does not need a UI control plane. Source: User request, 2026-07-06

Recommendation

Retain and recommend Coolify for the self-hosted-PaaS job. It is the first route when a project explicitly wants server ownership, Docker portability, predictable infrastructure spend, integrated apps/databases/services, and a productized deployment control plane. It is not an automatic replacement for a working Vercel, Cloudflare, AWS, Railway, Render, or other managed route. Compare total cost of ownership: control-plane and resource nodes, operator time, patching, backups and restore drills, monitoring, incidents, capacity, egress, and recovery—not only the provider invoice.

“No vendor lock-in” is qualified. Coolify keeps application/database configuration and running Docker resources on the owned server, so losing the service does not instantly remove the workload. You still lose its automation and must migrate or reconstruct control-plane state, deployment behavior, secrets, domains, backups, and operational procedures. Source: Coolify README; self-hosted versus Cloud usage

Agent-facing control plane

Use interfaces by authority, not convenience:

1. Observe through MCP. Start with coolify_help, infrastructure overview, unhealthy resources, projects, and filtered inventories. Use a team-scoped, expiring read token; keep read:sensitive off. MCP metadata still exposes server IPs, domains, application names, and environment-variable names to the chosen AI client.
2. Plan with stable identifiers. Resolve team, project, environment, server, application/database/service UUID, current status, deployment history, backup state, and rollback target before proposing a mutation.
3. Mutate through the official CLI or API. The official CLI supports contexts, JSON output, application/database/service operations, deployments, backups, and cancellation. Use a separate short-lived deploy token for approved lifecycle actions and write only for an approved resource/configuration change. Never reuse an ambient root token.
4. Prove the transition. Record frozen inputs and target UUIDs, deployment ID, health and logs, DNS/TLS reachability, backup/restore evidence when data is involved, rollback/cancel result, and the canonical project writeback.

The current MCP documentation is internally inconsistent: it labels the server “currently read-only,” then documents start, stop, restart, deploy, and cancel tools gated by the deploy ability. Fail closed on the tool table. A default MCP connection gets only read; lifecycle tools require a separately authorized run even if a client exposes them. Source: Coolify MCP Server; API authorization; Coolify CLI, checked 2026-08-11

Deployment admission

Before production use, require:

• a fresh supported 64-bit Linux host with at least the documented 2 CPU, 2 GB RAM, and 30 GB storage baseline, plus measured workload headroom;
• explicit acceptance that Coolify reaches managed servers over SSH and the default setup authorizes its key for root-level server management;
• separate control-plane and resource nodes when resource saturation could take down the management plane;
• ingress, firewall, DNS, TLS, API allowlist, token rotation/revocation, secret custody, and update owners;
• off-host database and Coolify-state backups with a tested restore, plus application-level data recovery where database dumps are insufficient;
• a canary deploy, preview behavior, health/log evidence, restart/rollback test, capacity and cost envelope, monitoring/alert path, and a documented escape to plain Docker operations.

Source: installation requirements; server architecture; database backups

The tradeoff

Self-hosting moves cost from a usage meter to a flat VPS bill and removes vendor lock-in, but you own the operational surface: OS patching, Coolify upgrades, uptime, and security are now yours. Coolify also offers a paid Cloud (a managed control plane that still deploys to your servers) for teams that want the DX without hosting the Coolify instance itself. Pick it when predictable cost and data ownership beat zero-ops; stay on managed PaaS when ops time is the scarce resource. Source: coollabsio/coolify, 2026-06-12

The repository is retained as an install candidate, but nothing in this review installed it or changed a server. Pin an admitted version, inspect the installer and release delta, then use the deployment-admission contract above.

---

Timeline

• 2026-08-11 | Replayed the complete bookmark and image against current repository, CLI, OpenAPI, MCP, authorization, installation, usage, backup, and application sources. Retained Coolify as the recommended self-hosted-PaaS route; added agent interface hierarchy, least-privilege tokens, operational admission, and proof requirements. The historical beta image remains evidence, not version authority. Source: replay manifest
• 2026-07-06 | Linked Coolify into Modern Web VPS Stack as the optional PaaS/control-plane layer for Hetzner-hosted TanStack/Vite apps. Source: User request, 2026-07-06
• 2026-07-04 | Deep-reviewed the X bookmark image and refreshed source status. Screenshot preserved the anti-PaaS positioning and historical 4.0.0-beta.470 README badge; GitHub source check moved the current authority to v4.1.2, branch HEAD e7dff30, Apache-2.0, 57,839 stars, and 4,912 forks. Source: X/@sentient_agency, GitHub, local image review, 2026-07-04
• 2026-07-04 | Source-reviewed @albert_'s BYOC/on-prem readiness thread. Promoted it as enterprise deployment posture evidence: be portable enough for customer-owned infrastructure, but avoid unmanaged customer self-hosting when BYOC lets the vendor keep operational control. Source: X/@albert_ thread, 2026-05-22
• 2026-07-04 | Added the @BadAINoData self-host stack reply as concrete anti-PaaS evidence: dedicated server plus k3s/Flux/Envoy/self-hosted Supabase/CloudNativePG/Redis/Qdrant as the named alternative bundle. Source: X/@BadAINoData, 2026-04-24
• 2026-04-07 | @sentient_agency surfaced Coolify ("RIP Vercel bills… free, open-source PaaS, one-command install, 280+ one-click services, Postgres/Redis/MySQL/MariaDB built-in"). 220 likes, 245 bookmarks. Source: X/@sentient_agency, 2026-04-07
• 2026-06-12 | Dedicated page created from dev-tools bookmark absorption; researched repo (coollabsio/coolify, Apache-2.0, ~57K stars). Anchored the recurring anti-PaaS / self-hosting theme (BYOC, k3s/Flux). Source: x-bookmark-absorb, 2026-06-12