Give your agent the brief below to deploy this Energon in your own Cloudflare account. It points to the maintained installation instructions because an agent should not have to infer the setup order or invent cloud configuration from a generic request. Fill in the account, fork, identities, and hostnames before sending it.

Deploy with an agent

Choose the inputs

You need a fork you control, a Cloudflare Workers Paid account, and two distinct hostnames. Short sibling names such as energon.your.co for the hub and share.your.co for content keep shared addresses shorter. The content hostname does not need to sit under the hub hostname. Separate origins keep published active content out of the hub’s authenticated context.

Have the human complete first-time Zero Trust enrollment and configure an identity provider if needed. An existing Google Workspace provider can be reused; selecting email PIN is a separate choice, not a required default. See Deploy an Energon host for credentials and setup order.

Copy this brief

Replace the bracketed fields. The personal policy below is a convenience-oriented starting point; replace it with the team policy below if appropriate.

Deploy my own Energon from my fork. Follow these maintained instructions:
https://docs.getenergon.com/operate/deploy-company-host
Read INSTALL.md in my fork and its linked deployment reference before acting.

Fork: [owner/energon]
Cloudflare account: [account name and ID]
Allowed sign-in email(s): [exact addresses]
Administrator email(s): [exact addresses]
Hub origin: [https://energon.your.co]
Content origin: [https://share.your.co]
Existing Zero Trust team and preferred identity provider: [team and provider]
Unique plugin name: [personal-name]

Personal policy: content never expires by default; allow unlimited retention;
owner-only writes; allow Never for ordinary tokens. Keep content lifetime and
token lifetime separate. Ask me which lifetime to approve for the connection.

I authorize setup and deployment in that account for this Energon. Verify the
active account and resource ownership before creating anything. Use Wrangler
and the documented Access API setup path. Preserve unrelated resources and
stop on conflicts. Do not commit credentials or put them in chat.

Use the maintained guide for exact commands and configuration. Keep migrations
before deployment. Hand human authentication and connection approval to me.
Never automate approval or invent a token. Confirm the chosen sign-in provider,
recognized email and admin access, public API discovery, and content separation.
After I approve a connection, publish disposable HTML and Markdown, load their
returned content URLs, update and reread them, and test password protection.
Record failures, workarounds, evidence, and untested paths. Ask before deleting
anything other than the disposable fixtures created for this verification.

This brief authorizes deployment of the specified fork and resources. It does not authorize deleting an existing installation to resolve a naming conflict. An agent still needs the correct credentials; a prompt cannot grant Cloudflare permissions.

Choose personal or team policy

For personal work where content should remain available until deliberately removed:

ALLOW_UNLIMITED_RETENTION = "true"
DEFAULT_TTL = "never"
MAX_TTL = "never"
WRITE_POLICY = "owner"
ALLOW_UNLIMITED_TOKENS = "true"

Owner-only writes preserve creator boundaries. They do not make published links private. Use share passwords where needed. Allowing Never for ordinary tokens adds that choice; the normal token default remains 90 days. Admin tokens are separate and cannot use Never.

For a trusted team where every token holder should be able to modify shared work, change WRITE_POLICY to org. Keep or change content retention and token choices independently. For temporary material, choose finite retention explicitly rather than assuming personal use requires it. Configure Energon policy describes these controls and their effect on existing content and tokens.

Human handoffs and completion

After deployment, follow Connect an agent. Completion means the hub recognizes the intended human and real published bytes load at returned content URLs. A successful deploy command or health check alone is not that evidence. Keep any failed steps for the operator to review, including tests the agent could not perform.