Panel apps

The Panel apps surface (under Admin → Panel apps) publishes the SpipCP documentation on the panel — served at its own subdomain, over the panel's own Caddy, with DNS and a certificate handled automatically. The docs ship with the panel, so publishing them is one click: choose the subdomain, and they go live.

Publish the docs

1. Open Admin → Panel apps.
2. Click Publish docs. The subdomain is pre-filled with a sensible default (docs.<panel-domain>); change it if needed.
3. Click Publish.

That's it. The panel serves the documentation it shipped with at that subdomain, and every “learn more” link inside the panel now points to it. There's nothing to build, package, or upload.

Domains and certificates

The docs live at a subdomain (like docs.example.com). The record it needs depends on who runs the DNS:

• The panel runs the DNS (self-hosted nameservers, or a connected provider account) — the panel writes the record automatically (a CNAME from the subdomain to the panel's hostname).
• DNS lives elsewhere — the panel shows the exact record to add; once added, nothing else is needed.

Either way, the certificate issues automatically once the subdomain resolves to the box. If a cert looks pending, it's almost always DNS still propagating.

In-app documentation links follow the panel

The panel's own “learn more” links resolve to wherever the docs are published — so once published, every doc link in the UI opens the right page on that docs site. Moving the panel to a new domain moves the docs URL (and every in-app link) with it, because they're derived from where the panel lives, not hardcoded. When docs aren't published, those links simply hide — never a dead link.

How publishing works (and why it's safe)

Publishing renders a Caddy site block into a shared area and a privileged helper validates it, then reloads the panel's edge:

• It takes a few seconds, not milliseconds (the helper polls for work).
• A bad render is rejected: if the generated config fails validation the reload is refused and the previous config keeps serving. A panel restart during that window still boots the last-known-good config.
• The panel never touches its own Caddy or the Docker socket directly — it renders and signals; the helper (the same one that runs panel self-updates) does the privileged part.

What this deliberately doesn't do

• Host arbitrary apps — the panel box has no container runtime. A changelog, a status page, or a tool belongs inside an app (or as a page in these docs), not co-hosted on the panel. Heavy apps belong on a node as a real site, where the panel manages the whole lifecycle.
• Need packaging or uploads — the docs are baked into the panel image; publishing just serves them.

Apps that serve their customers' domains

Any app hosted on a site — not just the ones co-hosted here — can drive the Custom hostnames API to serve its own customers on their own domains. SpipCP is one provider of that capability among several: the reference consumer (SpipUptime) keeps a provider interface with SpipCP, Cloudflare for SaaS and a manual path behind it, and works against a panel that predates the probe call. The panel makes no claim on an app's other DNS or TLS back-ends, and asks nothing of an app beyond the calls that page documents.