What is SpipCP?
A self-hosted control panel for running servers, instances, and websites — all from one place.
SpipCP is a self-hosted control panel for Linux servers, run on infrastructure the operator controls. It handles the work otherwise done by hand: onboarding servers, creating isolated environments on them, and launching real websites with domains, TLS, databases, backups, and git deploys.
Servers and their data stay under the operator's control. The panel talks to servers directly, with no cloud service in between.
Philosophy: open, sovereign, EU-first
Self-hosting is only half the story. The other half is who the operator depends on for the services around a server fleet. So wherever SpipCP calls for trusting a third party — DNS, who signs TLS certificates, where code is hosted — it lists open-source and EU/non-US options first, and treats the big US platforms as a deliberate fall-back that can always be switched away from.
This is about resilience. Open, self-hostable components can be inspected, forked, and run by the operator if a vendor disappears or changes terms. EU-based providers keep records under GDPR, off US infrastructure. And spreading DNS, certificates, and code across independent, swappable providers means no single company can hold an 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 each node — the home sites run in. |
| Sites | Real websites — WordPress, PHP, static, Node, or Python — with domains and TLS. |
| DNS | A managed EU provider or self-hosted 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
An owned server → a node → instances on it → sites in themA node (a server) is added to the panel. On it, instances (isolated environments) are created. In an instance, sites (websites) are launched. Each layer is managed from its own workspace in the panel.
What makes it different
- Self-hosted, no lock-in. Owned infrastructure, open-source components, direct connections.
- DNS off US soil. A managed EU provider (deSEC, Hetzner, Bunny, Gcore) or self-hosted 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 reports itself, 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 from a fresh panel to a live website in a handful of steps.