Recommendations
How SpipCP suggests you choose providers — DNS, SSL, and git — and the reasoning behind it. The short version: prefer open, self-hostable, EU/sovereign options; keep US-based platforms as a fall-back, not a default.
SpipCP is opinionated about where your stack lives. Wherever you have to trust a third party — your DNS records, who signs your certificates, where your code is hosted — the panel lists the options it recommends first, and the convenient-but-centralised ones last. This page explains that ordering, so it never looks arbitrary in the UI.
Why we recommend what we do
You run your own servers so that no single platform can revoke, inspect, throttle, or geo-restrict the thing you built. The same logic applies to every external service in the path:
- Data residency. Many default providers are US-based. For EU operators, that puts your records, metadata, and sometimes content under foreign jurisdiction and its legal regimes.
- Open over proprietary. Open-source, self-hostable components can be inspected, forked, and run by you if the vendor disappears or changes terms. Proprietary platforms can't.
- No single point of leverage. Spreading DNS, certificates, and code across independent, swappable providers means no one company can hold your whole operation hostage.
- The wider movement. This mirrors the broader push toward European digital sovereignty and away from sole reliance on US hyperscalers — for resilience, not hostility.
None of this is a ban
The US-based options still work and are still one click away. We simply make the sovereign/open choice the default path, and ask you to opt in to the centralised one.
DNS
Where your DNS records live decides who can see and control how your domains resolve. Start at the Set up surface (Networking ▸ Domains → Set up): its "Recommended for your case" logic turns this ordering into a guided journey — pick Connect a managed provider and the provider cards lead with the EU-first options below, or Self-host nameservers for the strongest option. Prefer the concepts first? The Networking overview lays the three postures (managed / self-hosted / manual) side by side with a live demarcation matrix. SpipCP's DNS providers picker lists the managed options in this order:
| Order | Provider | Why here |
|---|---|---|
| 1 | deSEC | EU non-profit (Berlin), free, DNSSEC by default, no commercial agenda. Our top pick. |
| 2 | Hetzner DNS | German, GDPR-native, free DNS Console API. |
| 3 | Bunny DNS | EU-headquartered (Slovenia), free, fast anycast. |
| 4 | Gcore DNS | Luxembourg-based, free tier, global anycast. |
| 5 | Cloudflare | US-based. Excellent product, but a US company holds your records — the fall-back, not the default. |
The strongest option isn't on that list at all: run your own nameservers with PowerDNS. That puts both DNS layers — delegation and records — on hardware you own. It's more work (two nameserver boxes), but it's the only path that trusts no third party for DNS.
Moving off Cloudflare DNS
If you're on Cloudflare today, the migration is real but routine: create the zone at an EU provider (or your own nameservers), copy the records, then change the nameservers at your registrar (Layer 1). The orange-cloud proxy is the one Cloudflare-only feature you'd give up — if you actually need it, that's a legitimate reason to stay; if you don't, you're just moving records.
SSL / certificates
A certificate authority signs proof of who you are. Every guided setup journey ends with an optional issuer step whose default is "Let's Encrypt is configured and needs nothing" — so for most operators the recommendation is simply do nothing. You only reach for the list below when a policy or a private CA demands it. SpipCP's SSL issuers and the per-domain issuer picker recommend:
| Order | Issuer | Why here |
|---|---|---|
| 1 | ZeroSSL | Free, generous limits, EU/Austria-based. ACME with EAB — our top pick. |
| 2 | Actalis | EU (Italy) browser-trusted CA over ACME with EAB. |
| 3 | Let's Encrypt | The zero-config default — needs no account, works everywhere. A perfectly good fall-back. |
| — | Custom (bring-your-own) | Upload your own PEM if you have a cert from elsewhere. Does not auto-renew. |
Why SSL has no Cloudflare option
We deliberately do not offer Cloudflare's origin CA as an issuer. Its origin certificates are only trusted by Cloudflare's edge — they are not publicly browser-trusted, so they only make sense if you've handed your traffic to Cloudflare's proxy in the first place. That's the dependency we're steering away from, so it isn't a choice here. Every issuer SpipCP lists produces a real, publicly-trusted certificate.
Git
Where your source code lives is where your deploy pipeline starts. SpipCP's git accounts picker recommends:
| Order | Provider | Why here |
|---|---|---|
| 1 | Forgejo | Community-governed (Codeberg e.V., non-profit), copyleft, self-hostable — git you fully own. Our top pick. |
| 2 | Codeberg | A free, EU-hosted public Forgejo instance (codeberg.org) run by the same non-profit — open hosting without running your own server. |
| 3 | Gitea | Open-source and self-hostable. The project Forgejo forked from; still a solid choice. |
| 4 | GitLab | Open-core and self-hostable (Community Edition), or gitlab.com if you prefer hosted. |
| 5 | GitHub | Microsoft-owned, US-based, proprietary. Works great; sits lower for the same reasons as above. |
| 6 | Bitbucket | Atlassian-owned, US-based, proprietary. |
Forgejo and Codeberg use the same API as Gitea, so the panel talks to all three the same way. Codeberg
comes pre-pointed at codeberg.org; Forgejo and self-hosted Gitea ask for your instance's API base URL.
Because GitHub sits lower, its one-click OAuth sign-in is hidden by default — the GitHub OAuth setup card only appears once you pick GitHub in the Connect account dialog (or already have a GitHub account connected). For the open providers you connect with a scoped access token. Either way, the token is encrypted in the panel and never sent to a node — each site pulls with its own read-only deploy key.
…and the panel itself
The same logic is why SpipCP exists: it's self-hosted, built from open components, and keeps the path between the panel and your servers free of any cloud middleman. The provider picks above are that same principle, one layer out. Run the panel you control, point it at providers you trust, and keep the centralised conveniences as a deliberate choice you can reverse — never the default you drifted into.
Where to go next
- Set up (guided journeys) — start a posture as a resumable checklist.
- DNS: the two layers — the mental model behind the DNS recommendation.
- Self-hosted DNS — run your own nameservers, the strongest option.
- Settings → DNS providers · SSL issuers — set the accounts up.
- Deploys — connect a git account and ship from a repo.