Recommendations
How SpipCP orders provider choices — 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 a stack lives. Wherever a third party has to be trusted — the DNS records, who signs the certificates, where the 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 the ordering is this way
Running self-hosted infrastructure means no single platform can revoke, inspect, throttle, or geo-restrict what gets built on it. The same logic applies to every external service in the path:
- Data residency. Many default providers are US-based. For EU operators, that puts 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 independently 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 the 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. The sovereign/open choice is simply the default path, with the centralised one requiring an explicit opt in.
DNS
Where DNS records live decides who can see and control how domains resolve. Start at the Set up surface (Networking ▸ Domains → Set up): its "Recommended for this case" logic turns this ordering into a guided journey — picking Connect a managed provider leads with the EU-first provider cards below, or Self-host nameservers for the strongest option. For 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. 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 the records — the fall-back, not the default. |
The strongest option isn't on that list at all: run self-hosted nameservers with PowerDNS. That puts both DNS layers — delegation and records — on hardware fully owned by the operator. It's more work (two nameserver boxes), but it's the only path that trusts no third party for DNS.
Moving off Cloudflare DNS
Migrating off Cloudflare is real but routine: create the zone at an EU provider (or self-hosted nameservers), copy the records, then change the nameservers at the registrar (Layer 1). The orange-cloud proxy is the one Cloudflare-only feature this gives up — a real need for it is a legitimate reason to stay; otherwise it's just moving records.
SSL / certificates
A certificate authority signs proof of identity. 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. The list below only matters 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 — 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 a PEM for a cert issued elsewhere. Does not auto-renew. |
Why SSL has no Cloudflare option
Cloudflare's origin CA is deliberately not offered as an issuer. Its origin certificates are only trusted by Cloudflare's edge — they are not publicly browser-trusted, so they only make sense once traffic has already been handed to Cloudflare's proxy. That's the dependency this ordering steers away from, so it isn't a choice here. Every issuer SpipCP lists produces a real, publicly-trusted certificate.
Git
Where source code lives is where the 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 fully owned by the operator. Top pick. |
| 2 | Codeberg | A free, EU-hosted public Forgejo instance (codeberg.org) run by the same non-profit — open hosting without running a 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 for a hosted option. |
| 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 the 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 GitHub is picked in the Connect account dialog (or a GitHub account is already connected). The open providers 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 the servers it manages free of any cloud middleman. The provider picks above are that same principle, one layer out. A self-controlled panel, pointed at trusted providers, keeps the centralised conveniences a deliberate, reversible choice — never a default 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 self-hosted nameservers, the strongest option.
- Settings → DNS providers · SSL issuers — set the accounts up.
- Deploys — connect a git account and ship from a repo.