Use this page to map one Energon instance onto infrastructure controlled by an individual or organization before provisioning it. The deployment unit includes an operator-owned fork, 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 the instance’s data and make the install coordinates agents receive match the Worker they call.
Operate an Energon instance
The instance 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 instances would mix data and operational failure domains. A dedicated fork 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 |
|---|---|
| Operator fork | Deployable source and the installable agent marketplace. |
| Hub origin | Access-protected human pages and bearer-token /v1 routes. |
| Content origin | Public /{handle}/s/ and /{handle}/f/ links, without Access. |
| D1 and R2 | The instance’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. Routine operation then becomes a short loop: validate the fork, apply migrations, deploy the Worker, and let runtime schema checks plus expiry sweeps maintain it. 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 first claims an expired object, removes its R2 bytes and D1 rows, purges the public cache prefix, then releases the storage quota it occupied.
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 instance policy |
| Preserve migration order 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 fork, 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.