Sovereignty is easy to declare and expensive to operate. Last spring we built Fortitudex, the collectible card app for the Fortitude Group Convention: three deployable units, a few hundred concurrent users, and a fixed date on the calendar.
The quickest route was three American SaaS platforms and a weekend of setup. We took a slower one instead, and ran the whole project on a self-hosted PaaS, on infrastructure we control.
The gap between a policy and a git push
The Fortitude Group has been explicit about digital sovereignty as a strategic position: autonomy and control over where workloads run, without giving up innovation speed. That conversation usually happens at the level of critical systems, the ones that get audited, mapped and put in front of a compliance committee.
Dependency tends to accumulate somewhere else. It builds up in the internal project that nobody audits: the demo, the small internal tool, the event app. Nobody writes a data-residency assessment for those. Somebody opens a laptop, connects a repository to a hosting platform, and by the end of the afternoon the code, the build logs, the database and the outbound email of a company project sit on three vendors in two jurisdictions, under a click-through agreement.
Do that for every side project in an engineering organisation and the result is your actual posture, which no policy document describes.
What we were not willing to give up
We did not set out to “go on-premise”. We set out to keep the developer experience that made those SaaS platforms the default in the first place, and to change only where it runs.
The list is short, and we treated it as non-negotiable:
- A preview environment for every pull request, on its own URL
- Deploy on push, with no manual step
- Certificates and DNS handled by the platform rather than by a person
- Rollback that takes less time than explaining the incident
This matters more than it sounds. A sovereignty strategy that slows the team down does not survive first contact with a deadline. It gets quietly bypassed, and the organisation ends up paying the infrastructure bill and keeping the shadow IT anyway. For the strategy to hold, the sovereign option has to be the easier one at the moment a developer chooses.
Preview environments are the clearest case. On a metered platform every pull request carries a price, teams start to feel it, and they open fewer of them. On a machine you are already paying for, one more preview costs nothing, so the practice gets used the way it was meant to be. The billing model stops making engineering decisions for you.
Why a platform, and not just a server
Owning the hardware is the easy half. We could have taken the same machine, installed Docker, written a reverse proxy configuration by hand, scripted the certificate renewals and wired up a deploy hook. Every step of that is well documented and none of it is hard.
It is also how a team ends up with a server that only one person can safely touch. The configuration lives in that person’s head and in files on that host. Onboarding a colleague means booking a walkthrough. Preview environments never get built, because each one is manual work that somebody has to want to do.
A self-hosted PaaS gives you the shape of a managed product on a machine you control: a web interface, containers, automatic TLS, git-triggered deploys, a preview environment per pull request. The property we were really buying is that a second person can operate it without a handover meeting. On a project with a fixed date and more than one contributor, that decided it.
Coolify or Dokploy?
Two projects dominate this space, and they are solving slightly different problems.
| Coolify | Dokploy | |
| First release | 2022, mature with a large community | April 2024, young and fast-moving |
| Licensing | Open source, self-hosted free with no feature limits | Open source, self-hosted free |
| Scope | Broad: 280+ one-click services, multi-server, native MCP server since v4.0 (May 2026) | Deliberately narrow: Docker-first, minimal surface |
| Interface | Feature-dense, more to learn | Cleaner and faster to read |
| Preview environments | Per-pull-request previews, first-class | Present, less developed |
| Recent trajectory | Structural releases | Incremental |
| Best fit | A substitute for a managed platform | The thinnest usable layer over Docker |
We chose Coolify for two reasons, neither of which was a feature count. Per-PR preview environments were on our non-negotiable list, and Coolify’s implementation of them was the more complete one. The second reason was maturity, which in self-hosted software is a proxy for something specific: when the platform breaks, your support channel is other people who have hit the same thing. A four-year-old project with a large community can answer questions a newer one has not been asked yet.
That is a judgement about fit for our case. A team that wants a small, legible layer over Docker Compose and nothing more would be right to pick the narrower tool, and the smaller surface area is a real advantage when you are the person on call for it.
What it cost us in surprises
What you take on here is a set of standing obligations, and they need an owner with a name. Backups, patching, certificate renewals and capacity headroom become recurring items on somebody’s calendar. If nobody owns them, they have not gone away; they have moved onto a risk register that nobody reads.
None of the following appears in the documentation, and all three would change how we set this up a second time.
Configuration drifts out of the repository. The platform’s own state, meaning services, environment variables and routing, lives in its web interface and not in your git history. For a team used to keeping infrastructure next to code, that is a step backwards: the application is versioned and the platform is not. We can live with it at this size. At ten times the size we could not.
Deploys are less isolated than they look. Production, the development environment and every open pull request share one host and one entry point, which makes them neighbours. A deploy in one of them can be briefly visible in another. On a demo that is a shrug. It is also the reason we would not put anything with an availability commitment on this setup as it stands today.
Every managed service you drop becomes a standing obligation. We started on a managed database and later moved to self-hosted Postgres on the same platform. The migration was ordinary work and took an afternoon. What changed permanently was the accounting: backup verification and upgrade windows belong to us now, and they will still belong to us in three years.
Conclusions
The finding worth reporting from Fortitudex is not really about Coolify, which is good software but replaceable. It is that the trade-off most organisations assume (sovereignty on one side and developer experience on the other) did not apply at our scale. We kept preview environments per pull request, deploy on push and automatic TLS, and we moved the whole thing onto hardware we control, inside a project that lasted a few weeks.
None of this is a recommendation. It is one project, with a small team, an internal audience and a deadline we controlled, and those properties did most of the work. The operational load is the part we did not escape. Digital sovereignty is not a purchase that completes. It is a capability that has to be staffed and kept staffed, and the machine is the least demanding part of it. Where we have seen this go wrong, the machine was planned for and the time to look after it was not.
Main author: Andrea Mazza, Senior Front-end Developer @Bitrock
FAQ
Is a self-hosted PaaS suitable for production workloads?
It has been for ours: internal tools, demos and services where a few minutes of downtime cost us nothing. We have not run anything under a contractual availability guarantee on it, and we would want a conversation with our platform engineering colleagues before we did.
Setup takes a few days. The recurring load is small but it does recur: patching, backup verification, certificate and capacity checks.
The signals we watch for are deploys interfering with each other, maintenance that no longer fits in the time allocated to it, and the first request for an availability guarantee. Any of those stops being a tooling question and becomes a platform engineering one, which is different work rather than a bigger version of this.
Coolify if you want a broad substitute for a managed platform, with mature previews and a large community behind it. Dokploy if you want a thin, legible layer over Docker and you value a surface small enough to understand completely