Themes and plugins

Themes change how your site looks; plugins change what it does. Both are signed packages that install at runtime — no redeploy, no editing the Worker — and both come and go from the admin. This guide is about installing and managing them. Building your own is covered in the extending section.

Themes

The Themes screen lists every theme available to your deployment. Cusp ships Aurora, the built-in default compiled into the Worker — it is always present, needs no install, and renders whenever no other theme is active. Alongside it are four installable first-party themes bundled with the Worker: Twenty Twenty-Six, Spring 2027, Quarto 2027, and Almanac. The example-site seed installs them so you have something to switch between out of the box.

Choose Install theme to add one. The dialog has two tabs: Browse bundled lists the first-party themes shipped with your Worker for a one-click install, and Install by URL takes a signed package from anywhere you host it. Once a theme shows the ready state, Activate makes it live. Activation asks for confirmation, because your public site switches to the new theme on the very next request — visitors see it immediately. Use default reverts to Aurora at any time, so a known-good look is always one click away.

Activating a theme does not touch your content — only its presentation. To adjust a theme's colours, type scale, or spacing without rebuilding it, use the Customise screen (/admin/customise), which overlays design tokens as versioned settings. The settings and navigation guide covers that overlay in full.

Plugins

The Plugins screen is administrator-only. It works like the Themes screen: Install plugin opens a dialog with Browse bundled and Install by URL tabs, and installed plugins list with their version and install state. Two example plugins ship bundled — Cloudflare Web Analytics, a configuration-only plugin that surfaces a beacon token your theme reads, and a webhook sender that illustrates the lifecycle-hook and capability contract. Community and self-built plugins install by URL.

A plugin that declares a configuration schema gets a Configure action on its row. It opens a form generated from the plugin's own schema — a text box for the webhook's URL and signing secret, a token field for the analytics beacon — that you fill and save. The values are stored as versioned settings, so a plugin's configuration time-travels and restores with the rest of your site. Uninstall removes the plugin together with the data, settings, and storage it created; the action cannot be undone.

Signing, trust, and the capability model

Themes and plugins install through one workflow, InstallPackage, which verifies an Ed25519 signature and a per-file integrity manifest before anything is written. A package that fails verification is rejected; a failed install never changes your live site. The first-party packages are signed with keys committed to the Worker's registry, and installing your own means signing it with your own key.

There is no hosted marketplace in v1. The trust model is the WordPress one: an administrator decides what to install, the package is verified at install time, and the host enforces what it is allowed to do. A plugin declares its capabilities — which hostnames it may reach, whether it gets storage, whether it can send mail — in its manifest. The host grants exactly what was declared and nothing more, so a plugin cannot reach a binding it did not declare, and an upgrade is held to its own version's declared set. A consent step that spells out the declared capabilities in the install dialog, and an upgrade re-prompt for newly-requested ones, are planned for a later release.