Set up (guided journeys)
The Networking "Set up" surface turns each DNS posture into a resumable checklist whose progress is read from your live fleet — leave for your registrar, come back days later, and it shows exactly where you are.
Every other Networking page organises the nouns — the Domains inventory, the Providers accounts, your Nameservers, the Edge routes, the SSL issuers — and each one opens with a table. Set up organises the verbs: "I want this domain on Cloudflare and my site to just work." It sequences the scattered steps (connect → test → attach → delegate) into one guided, resumable path so you never have to hold the order in your head.
Reach it from the Set up button in the Networking ▸ Domains header — it's always there, not just on an empty install. It is a page, not a sixth nav item; you can ignore it entirely if you already know the system, and every direct path (add an account, enroll a box, attach a domain) still works exactly as before. The guided layer is additive and opt-in.
What the Set up surface is
Pick what you want to do, and the panel shows a checklist for that posture. Each step's done-ness is read from your live fleet, never stored: an account row exists and tested green, a zone-list is cached, a nameserver box is healthy, glue resolves to the declared IP, the apex is delegated to your boxes, a domain is attached. The only thing SpipCP remembers is your intent — which journey, which provider, which domain — one small settings entry. Everything else is recomputed each time you open the page.
That single design choice is why the page is resumable by construction. Stop halfway to go add glue records at your registrar, come back three days later, and the checklist shows precisely the steps still outstanding — no "where was I?", no stale progress that drifted from reality. Delete the stored intent and restart the same journey and you get the identical checklist, because it was never a saved sequence of ticks — it's a live reading of your fleet.
One teaching home, tables everywhere else
Set up is the one page that teaches. The management pages (Providers, Nameservers, Edge, SSL) stay lean tables — a property of the 2.2 prose diet. The depth that a summary sentence in the panel leaves out lives here and in the linked reference pages, so the checklist stays a one-sentence-per-step list.
The four journeys + the issuer tail
The chooser offers four journeys, one per posture, plus an optional issuer step that every journey grows a tail for. Which cards appear depends on your offerings switchboard — close a posture and its journey drops out.
1 · Connect a managed provider
A DNS provider (deSEC, Hetzner, Bunny, Gcore, Cloudflare) serves your records. This is the fast path. First you pick the provider — the journey lays the EU-first cards side by side with their capability matrix and "where to get a token" guidance, so "which one do we go to?" is answered by comparison before you commit. Then the journey forks, asked in the provider's own name ("How should SpipCP work with Cloudflare?"):
The two forks are a genuine, honest trade-off — not a right answer and a lesser one:
| Automate with an API token (recommended) | I'll manage records myself | |
|---|---|---|
| Credential in SpipCP | A DNS API token (encrypted, write-only, never sent to a node). | None. SpipCP holds nothing. |
| Who writes records | The panel, through the provider's API. | You, by hand, at the provider — SpipCP shows the exact record to paste. |
| Certificates | HTTP-01 or DNS-01. | HTTP-01, per host. |
Wildcard cert (*.example.com) | ✅ — DNS-01 writes the _acme-challenge TXT for you. | ❌ — no credential means no way to write the TXT the wildcard proof needs. |
| Detected tier | Connected — the panel sees a matching zone in your account. | External — "NS at cloudflare.com (detected); records managed by you." |
| Creates in Networking | A provider account + cached zone list. | Nothing. That's the point of the fork. |
The no-token fork is the posture that was previously invisible: the UI led with Add DNS account → API token field, so "nameservers at Cloudflare, records by hand" read as token-or-nothing. It is now a first-class, named choice — pickable by provider name, asking for zero credentials, ending with a working attached domain. Full detail of the tier it lands in and the wildcard/HTTP-01 trade lives on The External tier.
The token fork's steps
add the account (the Add-account dialog, provider preselected) → auto-test ✓ → zone list cached ✓ → (optional) set the account as a node/instance cascade default → attach your first domain → the optional issuer tail. The no-token fork collapses to: attach with the manual driver → the record resolves ✓ → done.
2 · Self-host nameservers
Run your own PowerDNS boxes — full ownership, DNSSEC, wildcard certs. This is the longest journey because it owns both DNS layers (delegation and records), and its whole value is sequencing steps that today live across two tabs, the registrar, and prose banners. The full order, as one checklist:
Box 1 enrolled and healthy — the Add-a-nameserver wizard opens inline; the step goes done when the box reports healthy.
Box 2 in a second location — two boxes are the point (the second is the backup). A single box shows an amber accept-risk affordance rather than a green tick — you can continue with one box knowingly, but the panel never pretends it's redundant.
Glue records at the registrar — the copy-paste values from the glue wizard, plus Check now (see below): the panel resolves ns1.…/ns2.… from outside and compares against each box's declared public IP.
Create the zone — the Create-zone dialog inline, apex preseeded; done when the zone is active.
Add your records — before delegating — the migration order matters (see the callout below). Paste the records the domain needs while the old provider is still authoritative, so the switch is dark-for-nobody.
DNSSEC decision — turn it off at the old provider first; register the DS record only after your boxes answer. Detail: DNSSEC.
Delegate at the registrar + Check now — point the apex's nameservers at your boxes; the check does an NS lookup and set-compares against your nameserver hostnames.
Attach your first domain — then the optional issuer tail.
Records first, then delegate — never the other way round
The single rule that governs go-live: records must exist on your boxes before delegation points at
them. Delegate first and, hours later, cp.example.com can go dark because you never added its record.
The checklist enforces the order by putting add records ahead of delegate. Full walkthrough:
Delegate a domain.
Some ccTLDs won't register glue (.eu) — name your NS under a gTLD
Registrars create glue (host records) for generic TLDs like .com/.net, but some ccTLDs — .eu
(EURid) is the notable one — disable the registrar's glue/Hosts screen entirely. If your served domain
is a .eu, you cannot name your nameservers ns1/ns2.example.eu. Name them under a glue-friendly
domain you own instead — a .com like spipdns.com — register the glue once there, then delegate every
domain (.eu included) to ns1/ns2.spipdns.com. See Setup.
3 · Bring your own DNS
The legitimised do-nothing path. Keep DNS wherever it is today, attach with the manual driver, paste the one record the panel shows you, and a per-host certificate issues over HTTP-01. It creates nothing in Networking — and the checklist says so, on purpose. It exists so the chooser is exhaustive and so "no account needed" is a stated answer, not an absence you have to infer. Same honest trade-off as the managed no-token fork, minus the provider name: no credential means no wildcard, per-host HTTP-01 only.
4 · Front IPv6-only origins
The edge-proxy journey. When your origin (the panel, docs, or a v6-only site) has no public IPv4, stand a public-IPv4 edge box in front of it. The journey derives its preconditions (are there v6-only nodes? shown, not asked) → an edge box present (it rides your PowerDNS boxes, the 1.8 co-location guidance) → create the fronted route (the edge-route dialog inline) → the fronted hostname resolves to the edge's public v4 ✓ and health goes green ✓ (read from the existing multi-A failover health). It joins the chooser because it's the same "confusing order" problem in miniature.
The issuer tail
Every journey grows one optional trailing step for the certificate issuer, and its default state is already done: "Let's Encrypt is configured and needs nothing." Let's Encrypt is the zero-config answer for the 90% who never leave it. The step only becomes actionable when your posture wants more:
- Wildcard over manual DNS → you need a DNS-01 credential (which is really the managed-token fork, or self-hosted nameservers — a wildcard is impossible with no credential to write the TXT).
- Org policy / an EU CA → add a ZeroSSL or Actalis account (both ACME with EAB).
- A private CA / a cert from elsewhere → upload a custom PEM (does not auto-renew).
When it upgrades, the step inline-opens the existing SSL issuer dialog, so the journey never grows a parallel form. Depth: SSL/TLS certificates.
"Check now" honesty
The glue and delegation steps are the ones the panel can't do for you — they happen at your registrar — so they each get a Check now button that does a short-timeout, cached, panel-side lookup and reports what it saw, with a timestamp. It is honest about its own limits:
- Advisory, never a gate. A check never blocks the next step. DNS propagation lies, resolvers cache, and you may know better than the panel what you just changed.
- A red check means "not yet visible from here," not "you did it wrong." Delegation can take minutes to hours to propagate; the panel resolves from one vantage point at one moment. A failing check is a display that hasn't caught up, never a wrong action.
- Cached, with an explicit refresh. The result and its
checkedAttimestamp are shown so you know how fresh it is; clicking Check now again busts the cache and re-resolves.
This is the same posture the authority-tier detector and the attach pre-flight already take everywhere else: present what detection sees, store nothing, and let the real operation (the record write, the ACME exchange) be the source of truth.
The tiers get human subtitles
Wherever a tier badge renders — the Domains inventory, the attach wizard's pre-flight banner — it now carries a plain-language subtitle spending the detected nameserver: "External — NS at cloudflare.com (detected); you manage records there." The internal vocabulary (Hosted / Connected / External) stays frozen; the subtitle is the human translation. And on an External row whose nameserver SpipCP recognises, the attach banner offers the fix as a cross-link — "Want automatic records and wildcards? Connect Cloudflare →" — which deep-links straight into the managed journey, provider preselected.
Where to go next
- Domains: the three tiers — the inventory the journeys populate, and the detected-tier model.
- The External tier & CDN caveats — the no-token / BYO trade-off in full.
- Run your own nameservers — the self-hosted posture end to end.
- SSL/TLS certificates — the issuer tail and the certificate matrix.
- Choose your setup — the scenario-level overview each journey deepens.
Docker site type
A site type that runs a containerized app from a compose file inside an instance — each app with its own directory, port, and route — served and managed like any other site.
DNS in SpipCP: the two layers
Learn the one model that prevents most DNS confusion — delegation (the nameservers, set at your registrar) versus the records (A/CNAME/TXT, inside whoever is authoritative) — then pick a posture.