Coolify

What Coolify actually is

Coolify (github.com/coollabsio/coolify) is a control plane for servers you own. You point it at a machine over SSH — a VPS, bare metal or a Raspberry Pi, in the project's own words — and it takes care of the distance between a git repository and a running service: building the image, running the container, issuing the certificate, attaching the domain, and keeping databases and one-click services alongside it. Reading the LICENSE file rather than the badge confirms the licence is a clean, unmodified Apache 2.0 with no addendum and no split between a free core and a paid directory, which is the open-core arrangement several of its neighbours use instead. A paid cloud version exists, and the repository's own note is that the project intends to keep every feature out from behind the paywall — what the cloud sells is high availability, notifications, support and somebody else doing the maintenance.

The claim worth reading carefully is the one about lock-in. The README says your configuration is written to your own server, so if you stopped using Coolify you could still manage what is running — and then adds, in its own words, that you would lose the automations. That is an unusually straight way to put it, and it is the right mental model: what you keep is the containers and the configuration, what you lose is the machinery that rebuilt and redeployed them for you. It is still a much better answer than most managed platforms give to the same question, which is an export button or nothing.

The bill you are actually comparing

The headline comparison is easy and misleading. A managed platform charges you monthly for something two small servers can approximate, so the arithmetic looks settled before you have started. The real comparison is not the invoice, it is the invoice plus the hours — and the hours are the half nobody estimates honestly at the beginning, because they arrive later and in small pieces.

None of that is an argument against self-hosting. It is an argument for doing it deliberately. It is a good trade when your time costs less than the bill, when you have several services to run so the fixed cost of a control plane gets shared, and when you would rather hit a limit you can see than one somebody else set for you. It is a poor trade in the month you are trying to find your first customers, because every hour it takes is an hour not spent on getting anyone to visit the thing at all.

What we learned running our own fleet on a managed platform

We do not run Coolify, so this page claims nothing about operating it. What we can speak to first-hand is the decision on the other side of it: we run a container per customer workspace on a managed platform, and three things surprised us that are worth knowing before you choose either way.

The first is that a managed platform's limits are somebody else's numbers, and they can surface to your users. Ours caps how many services a single project may contain. We reached that ceiling, and the failure did not arrive as an alert — it arrived as a customer, part-way through signing up, being shown the platform's own quota message, naming our vendor and pitching an upgrade aimed at us rather than at them. A limit on hardware you rent yourself is at least a limit you can watch approaching. That is a real point in Coolify's favour, and of everything here it is the one we would weigh most heavily.

The second is architectural. Our fix was to stop giving every customer their own service and instead bind customers to a pool of generic ones as they arrive. If you are planning a container per customer on any platform, managed or self-hosted, find out what the ceiling is before you design around it rather than after.

The third is about the saving itself. Letting idle machines scale to zero is real money, and the hard part is not getting them to sleep — it is keeping them asleep. Every wake-up we chased turned out to be a background timer nobody thought of as traffic: a health check, a status poll, a dashboard left open in another window. One forgotten logged-in browser tab, refreshing quietly on its own, kept a single workspace awake almost permanently while the rest of the fleet was asleep for the large majority of the day, so the saving on that one workspace was nil. Before you add any periodic job to a self-hosted setup, ask what it does to a machine that is supposed to be asleep.

That is the honest shape of the choice. Coolify moves the deploy button onto hardware you control and hands you the pager along with it. Whichever way you go, shipping is the start of the problem rather than the end of it: the thing you just deployed still has to be found by somebody, and that is a different discipline from the one that got it running. The self-hosted pieces founders most often end up running next to it are PocketBase for the backend, OpenStatus to find out when it is down, and Meilisearch once the search box starts to matter.