Open source, yourself
- You want to update Coolify or something like it yourself.
Self-hosted PaaS: keep the servers without becoming Coolify
Self-hosting usually means installing a panel. Then the panel is the job: updates, restore, the upgrade that will not boot. We run the control plane. Docker and data stay on your machines.
- SSH stays yours. We set up Docker, proxy, SSL and backups.
- The pipeline file lives in the repo. No hidden deploy button.
Run the panel or only the containers
Self-host only the apps
- Containers and data on your hardware. Control plane not.
Docker
Databases
Reverse proxy
SSL
Backups
Firewall
- Coming soon
Kubernetes
- Coming soon
Monitoring
Self-hosted PaaS sounds like independence. Often it just means you caught a second application that also must not go down. The cleaner split is: your apps on your machines, the control plane as a service.
A self operated PaaS tool next to the Application Platform
This describes everyday life with a self installed open source tool compared with a supported platform that works on your servers.
| Criterion |
Application Platform
|
Self operated PaaS tool
|
|---|---|---|
| Deploying to your own infrastructure | Fully covered: Your own server over SSH or a managed server, access stays with you | Fully covered: The core idea, everything runs on your machine |
| Installing the platform | Fully covered: Not needed, the control plane is operated for you | Not offered: You install and configure the tool yourself |
| Updates and security patches | Fully covered: Handled for the platform, server baseline is maintained | Not offered: Your responsibility, including breaking changes between versions |
| Outages and troubleshooting | Fully covered: Support for platform operations, with a team in Cologne | Partly covered: Community forums and your own on-call willingness |
| Server baseline | Fully covered: Docker, databases, reverse proxy, SSL, firewall and backups are set up | Partly covered: Partly covered depending on the tool, the rest stays manual |
| CI/CD pipelines | Fully covered: GitLab CI for test, build, publish and release, configuration in the repository | Partly covered: Usually deployment only, CI has to be wired up separately |
| Mobile apps and store releases | Fully covered: Flutter, Expo and native projects through to App Store, Play Store and Microsoft Store | Not offered: Not part of the tool |
| Development environments | Fully covered: Ubuntu workspaces with VS Code, JetBrains, RDP and VNC. iOS builds on the pipeline’s macOS machines | Not offered: Not part of the tool |
| Roles, permissions and evidence | Fully covered: Organisations, roles, audit log plus a data processing agreement and TOMs as documents | Partly covered: Basic user management, evidence is something you assemble yourself |
| Control over the platform itself | Partly covered: You control projects and servers, not the source code of the control plane | Fully covered: Open source, adaptable if needed and free of licence cost |
Green means fully covered, amber partly, grey not offered. The right column does not describe a single vendor but the usual picture with self installed open source tooling.
As of 9 September 2026. This comparison describes typical workflows and can differ from project to project. Logos are trademarks of their owners and are used only to identify the product.
The honest cost
- Control of the control plane A self-installed panel is fully yours. In return, you are operations.
Pricing model
You pay your servers plus the platform. There is no hidden runtime rent on someone else’s dynos.
Setting up your self hosted stack
Four steps from an empty server to a first deployment.
-
Connect a server
Add your own server over SSH or book a managed one. The platform validates the access and starts the setup.
-
Let the baseline run
Docker, databases, reverse proxy, SSL, firewall and backups get configured. You do not write server scripts for that.
-
Create the project
Pick your stack in the wizard. Repository, project structure, GitLab CI pipeline, domain and SSL are created with it.
-
Deploy and keep going
A push triggers the pipeline. Environment variables and credentials live centrally in the project instead of in files on the server.
Frequently asked questions
Is the Application Platform itself self hosted?
Partly. Your applications run on servers with SSH access for you, the control plane – web interface, GitLab, automation – is operated by us. That covers data residency; for avoiding any external control plane, open source is the fit.
What speaks in favour of a self operated open source tool?
Quite a lot: no licence fees, readable source, no dependency on a vendor. For teams with operations experience and willingness to handle updates, that is a sound decision – the effort does not disappear, it just never appears on an invoice.
Can I keep using my existing server?
Yes. You store the SSH credentials, the platform sets up Docker, databases, reverse proxy, SSL, firewall and backups, then connects the server to the pipeline. The hosting provider does not matter as long as SSH access exists.
What happens if I want to leave again?
Repositories and the description of your environments are readable and can be transferred, with full code ownership. If the project runs on your own server, that machine stays yours regardless.
Are Kubernetes and monitoring included?
Both are underway. You can already store cluster access under Connections. Deploying onto the cluster comes later; today the platform runs on Docker, with databases, reverse proxy, SSL, firewall and backups around it. Error tracking with Sentry is ready once you connect your Sentry account under Connections.
Try the middle ground on one project
Register for free, connect a server and compare the effort with your current installation.