Plugin Deployment

Bundled plugins ship with their calling Worker. Dynamic plugins use a separately published bundle and policy, then tenant installations select the published version.

Bundled distribution

Source files or a package dependency must be imported, registered, and built into the appropriate Worker. Installing an npm package alone does not change the deployed service. Match the library version to the Authrim source you deploy and test the actual caller.

Dynamic Worker requirements

Setup’s features.pluginDynamicWorkers.enabled enables the dynamic execution feature and requires R2 to be enabled. The deployment needs Plugin Runner, its database and keys, a PLUGIN_LOADER binding, and PLUGIN_BUNDLES storage. Availability and billing of Cloudflare Dynamic Workers should be checked for the target account.

Manifest discovery

Setup looks for authrim.plugin-worker-capabilities.json in the project root and under plugins/ and packages/, with bounded discovery. It skips build/dependency directories and hidden entries. A package hidden only inside node_modules is not discovered automatically.

The manifest declares the plugin ID, backend, tenant scope, visibility, capabilities, host interfaces, resources, credentials, outbound hosts, and a relative Worker bundle path. Paths must stay inside the project. The authrim.extension-capabilities.json extension format is separate; it is not a replacement name for a plugin manifest.

Publication

For a configured environment, inspect the deployment using:

pnpm run setup deploy --env dev --dry-run

Then deploy the reviewed configuration:

pnpm run setup deploy --env dev

The publication implementation validates bundle bytes and uploads them under plugins/{pluginId}/{codeSha256}.json. It records the code digest, capability-manifest digest, and policy-derived version in the Runner database. The Runner checks the R2 object digest before loading it.

The version changes when relevant policy changes even if code bytes remain unchanged. Do not overwrite a released version’s meaning by editing stored rows manually.

Activation and resources

Publication is not tenant enablement. Configure required credentials and resource selections, then enable the tenant installation. D1/KV/R2 plugin resources may require provisioning and deployment finalization before execution is available. An accepted request can therefore return an in-progress state.

Raw infrastructure credentials stay with the setup/control operation. Custom plugin code receives the approved interfaces and scoped resource wrappers, not Cloudflare provisioning tokens.

Updating and uninstalling

Use the platform rollout operation for approved dynamic versions when updating existing installations. Observe per-tenant progress and failures; publishing a new artifact alone does not prove every installation has moved.

Disable and uninstall are separate. Uninstall can require resource cleanup/finalization. Check completion and the relevant resource policy instead of assuming an immediate deletion of all stored data.

See Admin UI for tenant controls and Configuration for secrets.