What is SpipCP?
A self-hosted control panel for running your own servers, instances, and websites — all from one place.
SpipCP is a self-hosted control panel for Linux servers. You run it on your own infrastructure. It handles the work you'd otherwise do by hand: onboarding servers, creating isolated environments on them, and launching real websites with domains, TLS, databases, backups, and git deploys.
Your servers and their data stay under your control. The panel talks to your servers directly, with no cloud service in between.
Our philosophy: open, sovereign, EU-first
Self-hosting is only half the story. The other half is who you depend on for the services around your servers. So wherever SpipCP asks you to trust a third party — your DNS, who signs your TLS certificates, where your code is hosted — it lists open-source and EU/non-US options first, and treats the big US platforms as a deliberate fall-back you can always switch away from.
This is about resilience. Open, self-hostable components can be inspected, forked, and run by you if a vendor disappears or changes terms. EU-based providers keep your records under GDPR, off US infrastructure. And spreading DNS, certificates, and code across independent, swappable providers means no single company can hold your whole operation hostage. The provider pickers in Settings reflect this: deSEC/Hetzner/Bunny/Gcore before Cloudflare for DNS, ZeroSSL before Let's Encrypt for SSL, and Gitea/GitLab before GitHub for git. See Recommendations for the full reasoning and how to move off US services.
What it does
| Nodes | Bring a server under management — enroll it once, harden it, keep it converged. |
| Instances | Isolated VMs or containers on your nodes — the home your sites run in. |
| Sites | Real websites — WordPress, PHP, static, Node, or Python — with domains and TLS. |
| DNS | A managed EU provider or your own nameservers — keep DNS off US-hosted infrastructure. |
| Deploys | Ship straight from a git repository, with rollback and webhooks. |
| Backups | Encrypted, offsite, and proven by restore — not just by existing. |
| Monitoring | Uptime and certificate alerts — the fleet watches itself. |
How it fits together
A server you own → a node → instances on it → sites in themYou add a node (a server). On it you create instances (isolated environments). In an instance you launch sites (websites). Each layer is managed from its own workspace in the panel.
What makes it different
- Self-hosted, no lock-in. Your infrastructure, open-source components, direct connections.
- Own your DNS, off US soil. Use a managed EU provider (deSEC, Hetzner, Bunny, Gcore) or run your own nameservers — the GDPR path for moving off US-hosted DNS.
- Sovereign by default. EU-first picks for DNS, SSL, and git; US platforms are a fall-back, not the default. → Recommendations
- Isolation as a feature. Sites run in isolated instances (VMs by default), so one compromised site can't reach its neighbors. → Security
- Honest by design. A failed launch, deploy, or backup tells you so, with a fix — never a green light over something broken.
- Simple foundations. One database, no extra services to run. → How SpipCP is built
Start here
New to SpipCP? Getting started walks you from a fresh panel to a live website in a handful of steps.