Use this page to map one Energon onto infrastructure controlled by an individual or organization before provisioning it. The deployment unit includes an operator-owned deployment repository, dedicated D1 and R2 resources, an Access-protected hub, a separate content hostname, and a rendered agent plugin. Keep those pieces together because they isolate this Energon’s data and make the install coordinates agents receive match the Worker they call.
Operate an Energon
This Energon is the isolation boundary
Energon keeps published bytes in R2 and their catalog, owners, tokens, and expiry state in D1. Sharing either resource between independently controlled Energons would mix data and operational failure domains. A dedicated deployment repository also becomes the marketplace from which agents install a plugin already bound to the correct hub and token environment.
The second hostname is equally deliberate. Human hub pages carry a Cloudflare Access session, while published HTML may contain active code and must stay outside that session boundary. The hub origin (PUBLIC_ORIGIN) handles people and /v1; the content origin (CONTENT_ORIGIN) serves only public content URLs for sites and loose files.
Mental model
Each part has one job:
| Part | Responsibility |
|---|---|
| Deployment repository | Deployable source and the installable agent marketplace. |
| Hub origin | Access-protected human pages and bearer-token /v1 routes. |
| Content origin | Public /{handle}/s/{id}/{slug}/ and /{handle}/f/{id}/{filename} links, without Access. |
| D1 and R2 | This Energon’s catalog and byte store. |
| Cron and request checks | Scheduled cleanup plus immediate rejection of expired content. |
The operating loop
Provisioning creates the boundary once. The first deploy uses laptop Wrangler with automatic updates left off. Catching up later merges a published release tag (the update-from-upstream skill when the checkout has it), then migrates and deploys only after you know whether a push to main updates the live Worker. This local check exercises the same schema history and rendered-plugin consistency without touching production:
npm install
npx wrangler d1 migrations apply energon --local
npm run skill:render -- --check
npx wrangler types
npm run typecheckA normal request calls the runtime schema bootstrap before reaching most routes. A scheduled event does the same before selecting expired rows. Cleanup of an expired loose file claims it, removes its R2 bytes and D1 rows, purges the public cache prefix, then releases the storage quota it occupied. An expired site is marked removed first; its versions, staged deployment files, and quota charges are released after in-flight reads end and storage deletion is confirmed.
Check storage and usage
Open Stats on the hub to see You and Organization totals. Your totals cover work you created or last updated; Organization covers this Energon. Files counts both individual uploads and files within sites. The People list can rank by Storage, Files, or Sites. These are stored-content totals, not counts of views or handoffs. Stats also shows platform storage used versus MAX_PLATFORM_BYTES.
Choose your next task
| Goal | Guide |
|---|---|
| Provision isolated resources and take a host live | Deploy an Energon host |
| Set retention, token, write, identity, and capacity defaults | Configure Energon policy |
| Clean up storage, revoke tokens, or offboard a person | Administer Energon |
| Catch up to a published release or recover interrupted cleanup | Upgrade and recover |
| Define RPO/RTO and restore the D1 catalog with R2 bytes | Back up and restore D1 and R2 |
| Review token, Access, and public-link trust boundaries | Security model |
Keep the deployment unit together
Treat the deployment repository, D1 database, R2 bucket, two origins, and rendered plugin as one unit. If one identity value changes, verify the others before deployment. If schema changes, migrate before deploying. If production metadata needs manual repair, stop automation and hand the decision to a human operator.