Panel apps

The Panel apps surface (under Admin → Panel apps) publishes the SpipCP documentation on your own panel — served at its own subdomain, over the panel's own Caddy, with DNS and a certificate handled for you. 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.<your-panel>); change it if you like.
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 your DNS:

• The panel runs your DNS (self-hosted nameservers, or a connected provider account) — the panel writes the record for you (a CNAME from the subdomain to the panel's hostname).
• Your DNS lives elsewhere — the panel shows you the exact record to add; once you add it, 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 your panel

The panel's own “learn more” links resolve to wherever your docs are published — so once you publish, every doc link in the UI opens the right page on your docs site. Move your panel to a new domain and the docs URL (and every in-app link) follow, 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 for you — 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.