Deploy your own Energon by following INSTALL.md in the Energon repository . Follow its ordered procedure from creating a deployment repository to verifying the deployment, because setup instructions need to match the code being installed. Installation is two parts: a first laptop Wrangler deploy, then optional automatic updates. Use this page to understand the phases and find supporting material before you begin.

Deploy an Energon host

Start with the installation guide

You can start without a deployment repository or settled configuration. Use Deploy with an agent for a brief you can copy unchanged, or follow INSTALL.md yourself. Both paths use the same procedure.

Once you have an operator-owned checkout, read its INSTALL.md and linked references. The checkout’s version governs execution. A newer website or upstream release can describe capabilities an older checkout does not yet have; compare versions and update deliberately before using them.

The first deploy (INSTALL steps 1–7) takes the Worker live with Wrangler on the operator’s machine. Leave ENABLE_PRODUCTION_DEPLOY=false so Actions is tests only. After verification, optional automatic updates  can make a later push to main migrate D1 and deploy. That is a separate decision from enabling CI tests.

Private source and agent access

Your agent follows INSTALL.md to create an independent private deployment repository and preserve upstream Git history. You choose the owner and repository name. The creation helper verifies the private destination before its first push; it does not use GitHub’s fork network or the template button. Keep company customizations and non-secret instance settings there. Credentials remain in secret stores.

The generated publish skill is distributed from that repository. Each installing client needs GitHub read access for installation and updates, separate from its human-approved Energon token. From v1.12.0, the content origin also serves the same skill at /.well-known/agent-skills/, so npx skills add <content origin> installs it without repository access; AGENT_SKILLS_DISCOVERY turns that off (see Configure Energon policy). See Connect an agent for authenticated installation and the local-skill or HTTP API fallback. Repository privacy does not make published links private, and public discovery still advertises repository coordinates and runtime policy.

For existing public forks, use the canonical repository migration procedure . It preserves Git history and running Cloudflare resources while accounting for plugin coordinates, permissions, secrets, and automation cutover. Changing a public fork’s visibility is not supported. Copying it does not retract previously public history.

Update an existing installation

Start with Update an existing Energon . If the checkout has update-from-upstream , follow that skill; the INSTALL steps remain the hand procedure. Merge a published release tag, not unreleased main. Do not use GitHub Sync fork.

Preserve this Energon’s account, bindings, origins, policy, Access vars, plugin identity, and token prefix. Inventory-match the deployed Worker and its D1/R2 bindings to this wrangler.toml before any remote command. Use the checked-out version’s Access verification procedure; do not treat different resource names as permission to replace a working sign-in configuration. Record a D1 Time Travel bookmark before any remote migrate. Do not create, delete, empty, or rebind the live D1 or R2.

Ask before landing on main when automatic updates are on or the ENABLE_PRODUCTION_DEPLOY read failed. An explicit repository-level false disables the stock deploy job; a missing variable can inherit an organization value and must be resolved first. Landing still requires authority to accept the code update. Turning automatic updates on later does not deploy the commit already on main. Repeat the installation’s acceptance checks. Upgrade and recover is the Admin How to update landing page.

Understand the phases

The installation starts with the operator’s choices and account ownership. It then aligns the deployment repository’s storage, plugin identity, and hub and content origins. Access setup establishes how people sign in, and deployment makes the configured Worker available. Verification checks the result before the installation is handed over.

Keep those phases in the order given by INSTALL.md. In particular, creating cloud resources and choosing policy are part of installation, while routine development work alone does not authorize changes to a deployed host.

These links open upstream for discovery. Use the corresponding local files after checking out your deployment repository.

Hosting requirements for large sites

Two separate Cloudflare limits decide how large a site this Energon can publish. Check both before raising any size setting.

• Request-body limit. The zone plan caps one request body before the Worker runs: 100 MB on Free and Pro, 200 MB on Business. Every file and every ZIP must fit in one request. On a tested workers.dev endpoint, exactly 104,857,600 bytes were accepted and one more byte received a Cloudflare 413; check other routes and zones yourself.
• Worker CPU limit. Preparing a large ZIP and hashing large uploads use Worker CPU time. This is a property of the Workers plan and the Worker’s configured CPU limit, not of the request size.

Large-ZIP support was qualified on Workers Paid with a 30-second CPU limit ([limits] cpu_ms = 30000). On that profile, a disposable Worker uploaded, prepared, committed, and hash-verified a 100 MiB stored ZIP and a ZIP expanding to five 100 MiB files (500 MiB total), and two concurrent preparations also completed. The highest sampled API Worker CPU was about 9.2 seconds. On Workers Free, the same 100 MiB upload and 500 MiB expansion tests were terminated with Cloudflare error 1102 (exceededCpu). Small atomic publications worked on Free, but the default ZIP limits are not qualified there. On Free, lower MAX_ZIP_IMPORT_BYTES and MAX_ZIP_EXTRACTED_BYTES, or move to Workers Paid. INSTALL.md  already lists Workers Paid as a prerequisite.

These measurements are from the product’s qualification runs on October 7, 2026, recorded in atomic site deployments . They are not a guarantee for every workload. Configure Energon policy covers the size settings and storage headroom.

Keep human handoffs explicit

The installation guide identifies the prerequisites and verification steps. Record any blocked or untested step so another agent can resume without guessing what succeeded. Connect an agent explains the human handoff used during verification. Administer Energon covers ongoing operations.