Domains & SSL

Attaching a domain gives a site a real hostname with automatic HTTPS. You give the site a hostname and point one DNS record at the node. SpipCP routes the traffic, issues the TLS certificate, and proves https://yourdomain actually serves the site before marking it green. A domain that doesn't pass that check is never shown as working — it's failed with a fix to apply.

📷A site's Domains tab — attach a hostname and watch its certificate issue.img/sites-domains.avif

The one thing you do in DNS

SpipCP asks for exactly one DNS record, and never anything else:

An A record: yourdomain → your node's IP (shown to you when you attach).

That's the whole DNS setup. Once that record resolves to the node, the attach continues on its own — verify DNS, issue the certificate, test HTTPS, go green. You don't create challenge records, upload anything, or click "activate."

What the wizard tells you before you attach

As soon as you type a valid hostname, the wizard resolves its authority tier and shows a banner — before you commit — so you know what will happen:

• Hosted — "zone example.com is on your nameservers; the DNS record will be created automatically."
• Connected — "zone found in a provider account you hold (e.g. Bunny); the record will be created automatically." If your cascade's default account doesn't hold this zone, the banner warns of a mismatch and suggests a per-domain override so the attach doesn't fail at record-write time.
• External — "no connected account holds this zone (detected nameserver dns1.registrar.com); you'll get the exact records to create by hand." This sets the expectation up front instead of surprising you at the DNS-verify gate. When the detected nameserver is one SpipCP recognises (e.g. Cloudflare), the banner also offers the fix as a cross-link — "Want automatic records and wildcards? Connect Cloudflare →" — which deep-links into the managed-provider journey with that provider preselected. On an unrecognised nameserver it links the bring-your-own-DNS journey instead.

📷The attach wizard resolves the hostname's authority tier before you commit — here, records will be created automatically. On an External tier the banner offers a 'Connect <provider> →' cross-link into the guided journey.img/sites-domain-attach-preflight.avif

The pre-flight is advisory: the real record write at attach time is always the source of truth. It just turns a late failure into an up-front expectation.

Attaching a domain

If a domain fails (wrong record, still proxied, DNS not propagated yet), fix the record and press Retry attach on the domain row — it re-runs the whole flow from the DNS check. No need to detach and start over.

The SSL dashboard

Networking → SSL is a certificate dashboard — one row per domain, so you always know what you're running and when it expires:

A summary strip at the top counts what's secured, what's expiring within 21 days, and what needs attention. The same certificate detail also appears inline on each domain's row in the Domains sub-tab.

Automating DNS with provider accounts

To let SpipCP create the record for you, connect a named DNS account under Settings → DNS providers — a reusable credential you set up once and assign to many domains. SpipCP supports Cloudflare (US), Bunny (EU), Hetzner (German), deSEC (EU, DNSSEC by default), and Gcore (EU). Each account holds the provider's token, scoped to edit DNS records; the token is encrypted, write-only, and never reaches a node. See DNS providers for where to get each token and the EU/GDPR/free-tier notes.

The DNS-account cascade

You don't pick an account per domain by hand every time — a DNS account cascades node → instance → domain, exactly like git accounts:

A level left blank inherits from the one above, and the most-specific value wins: a domain override beats the instance default, which beats the node default. Change a node's default and every domain that never overrode follows automatically — no re-attach. Delete an account something pointed at and that reference falls back to "inherit the level above," never a broken pointer.

Wildcard subdomains and the Caddy DNS module

A wildcard certificate for *.example.com is issued over a DNS-01 challenge — the node's Caddy proves control of the domain by writing a TXT record through your provider's API. That needs the matching caddy-dns/<provider> module built into the Caddy on the node serving the site. A single hostname (no wildcard) uses the simpler HTTP-01 challenge and needs no DNS module.

If you request a wildcard and the node's Caddy lacks the right module, SpipCP doesn't fail silently — the wizard names the missing caddy-dns/<provider> module, so you know exactly what the node needs before the wildcard can issue.

Choosing a certificate issuer

Let's Encrypt is the default — free, automatic, nothing to configure. For operators who need an alternative, the issuer is selectable (an advanced choice in the attach wizard) and cascades node → instance → domain just like the DNS account:

ZeroSSL and Actalis need an EAB issuer account (a Key ID + HMAC key from the provider's dashboard), and Custom needs a PEM account (the certificate chain + private key). You add both under Settings → SSL issuers, where each secret is encrypted at rest and never reaches a node. Like the DNS account, the issuer account cascades — set a default per node or instance, override it per domain — and a chosen issuer with no account fails the attach with a remedy rather than going green.

→ Full guide: SSL issuer accounts.

What you can manage

How it works

The node's reverse proxy (Caddy) routes the hostname to the site's port on its instance, issues and auto-renews the certificate, and a certificate-expiry check warns you long before one lapses. The test before going green means "green" always means "actually serving."

→ Routes detail: Sites → Networking. · Certificate alerts: Monitoring. · DNS accounts: Settings → DNS providers. · Self-hosted DNS: DNS → Self-hosted. · Issuer accounts: Settings → SSL issuers.