SpipCP

Choose your setup

Four ways to run SpipCP — pick who serves your DNS and how the panel gets installed, then follow one walkthrough end to end.

SpipCP doesn't force one architecture. Two independent choices define your setup:

  1. Who serves your DNS? — your own nameservers, or an external provider (Cloudflare, Bunny, …).
  2. 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) lets you turn OFF whichever DNS posture you don't use, so your 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, you can start the matching journey and follow a resumable checklist that reads its progress from your 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

ScenarioYour DNS records live…Best forWalkthrough
A · Self-hosted DNSon your own PowerDNS nameserver boxes, managed entirely in the panelMaximum sovereignty — you are your own Cloudflare. No third party holds a single record.No domain yet / self-hosted DNS
B · External DNS — Cloudflareat Cloudflare, written via its APIFastest start; you already use CloudflareExternal DNS/CDN
C · External DNS — deSEC / Hetzner / Bunny / Gcoreat that provider, written via its APIEU-first sovereignty without running nameserversExternal DNS/CDN (same flow, pick your provider tab)
D · Registry installany of A–CTeams with CI + a registry (Forgejo, GHCR, GitLab, Harbor) — the box only ever pullsInstallation

A and B/C are both first-class

Self-hosted DNS (A) is the sovereignty path — the panel runs your 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. You can start on B/C and migrate to A later: create the zone on your own nameservers, re-create the records (the editor's Paste many exists for exactly this), then re-delegate at your 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 your provider, then take the automate with a token fork (or the records-by-hand one, if you'd rather hold no credential)
  • An API token from your provider (exact scopes are shown per provider in the panel)
  • A provider account added under Networking → Providers
  • Your domain delegated to that provider at the registrar (usually already true)
  • Full walkthrough: External DNS/CDN

D — Registry install

  • A container registry your box can pull from (GHCR today; your own Forgejo/Harbor when you run one)
  • 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 migrate service runs before the panel; seeing it as Exited (0) in docker compose ps is 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 asks you to compile or upload anything.

If you see the panel asking for a manual agent release or the nav renders empty after login, the box is running an image from before these fixes — update the panel and they resolve themselves.

On this page