Choose a setup
Four ways to run SpipCP — pick who serves DNS and how the panel gets installed, then follow one walkthrough end to end.
SpipCP doesn't force one architecture. Two independent choices define the setup:
- Who serves DNS? — self-hosted nameservers, or an external provider (Cloudflare, Bunny, …).
- How does the panel get installed? — cloned from a git host, or pulled from a registry.
Pick a row, follow its walkthrough, ignore the rest. The panel's offerings switchboard (Networking → Providers) turns OFF whichever DNS posture isn't in use, so the team never even sees the other path's screens.
The fastest way in: start a guided journey
Each scenario below maps to a guided journey on the Set up surface (Networking ▸ Domains → Set up). Rather than reading the whole walkthrough up front, starting the matching journey follows a resumable checklist that reads its progress from the live fleet — the scenario prose here is the depth behind each step. Scenario A → Self-host nameservers; B/C → Connect a managed provider; the do-nothing path → Bring your own DNS.
The scenarios
| Scenario | DNS records live… | Best for | Walkthrough |
|---|---|---|---|
| A · Self-hosted DNS | on dedicated PowerDNS nameserver boxes, managed entirely in the panel | Maximum sovereignty — becoming a self-hosted Cloudflare equivalent. No third party holds a single record. | No domain yet / self-hosted DNS |
| B · External DNS — Cloudflare | at Cloudflare, written via its API | Fastest start; already using Cloudflare | External DNS/CDN |
| C · External DNS — deSEC / Hetzner / Bunny / Gcore | at that provider, written via its API | EU-first sovereignty without running nameservers | External DNS/CDN (same flow, pick the provider tab) |
| D · Registry install | any of A–C | Teams with CI + a registry (Forgejo, GHCR, GitLab, Harbor) — the box only ever pulls | Installation |
A and B/C are both first-class
Self-hosted DNS (A) is the sovereignty path — the panel runs the nameservers and its records editor replaces the provider dashboard entirely. External DNS (B/C) is the fast path — the panel writes records through the provider's API and everything else (sites, certs, deploys, backups) works identically. Starting on B/C and migrating to A later is supported: create the zone on dedicated nameservers, re-create the records (the editor's Paste many exists for exactly this), then re-delegate at the registrar.
What each scenario needs
A — Self-hosted DNS
- Start the Self-host nameservers journey (Set up) — it sequences box → box → glue → zone → records → DNSSEC-off → delegate → attach as one resumable checklist, with a Check now on the glue and delegation steps
- 2 small extra VPSes (1–2 GB) that become
ns1/ns2— enrolled from the panel in one wizard each - One-time registrar steps: glue records for the in-domain nameservers + delegation
- Full walkthrough: Installation without DNS covers panel-on-IP → nameservers → zone → delegation → hostname cutover in order
B / C — External DNS
- Start the Connect a managed provider journey (Set up) — pick a provider, then take the automate with a token fork (or the records-by-hand one, for holding no credential)
- An API token from the provider (exact scopes are shown per provider in the panel)
- A provider account added under Networking → Providers
- The domain delegated to that provider at the registrar (usually already true)
- Full walkthrough: External DNS/CDN
D — Registry install
- A container registry the box can pull from (GHCR today; a self-hosted Forgejo/Harbor once one is running)
- The deploy files from any git host —
install.sh --repo <url>fetches exactly what it needs - Full walkthrough: Installation (the quick install is this scenario)
What happens automatically (every scenario)
These used to be manual steps — they aren't anymore. On every install and upgrade:
- The database migrates itself — a one-shot
migrateservice runs before the panel; seeing it asExited (0)indocker compose psis correct, not an error. - Roles & permissions seed themselves — the admin/operator/developer grants reconcile on every boot.
- Agent releases are baked in and auto-published — the image carries signed agent binaries (amd64 + arm64); the first node enrollment never requires compiling or uploading anything.
If the panel asks for a manual agent release, or the nav renders empty after login, the box is running an image from before these fixes — updating the panel resolves both.