Deploy to Cloudflare

Agent as a Business can deploy a generated Web surface to Cloudflare Pages while keeping runtime execution, credentials, payment policy, and operational evidence on the managed platform.

Before you deploy

Confirm that the Agent Business has:

• a tested capability and explicit input/output contract;
• an active Capability Release;
• a configured Web surface and visibility policy;
• the intended authentication, billing, and Turnstile settings;
• a Cloudflare project name that belongs to this business.

Provider keys, Stripe secrets, OAuth client secrets, database URLs, and creator credentials must remain in trusted server-side configuration.

1. Configure the Web surface

Open the Agent Business and select Surfaces. Choose the frontend template, locale, presentation settings, and any public runtime options required by the generated app.

Public runtime values may be included in browser code. Secrets may not. The generated surface uses the managed runtime at https://api.agentaab.com/api and remains scoped to one Agent Business.

2. Create a deployment version

Generate a preview or downloadable package from the current surface configuration. A deployment version records exactly which generated assets, runtime configuration, and release references were reviewed together.

Open the preview and test at least one representative runtime request. Also check empty, error, authentication, payment, and narrow-screen behavior when those features are enabled.

3. Approve the version

Approve only the deployment version you inspected. Approval is separate from deployment so a newly generated package cannot replace production without an explicit review boundary.

If configuration changes after review, generate and approve a new deployment version.

4. Deploy to Cloudflare Pages

Enter the Cloudflare Pages project name and choose Deploy to Cloudflare. The console queues the approved version, reports deployment state, and records the resulting URL with that version.

Use Redeploy only when you intend to send the same approved version again. Use a new deployment version when assets or configuration change.

5. Verify the deployed origin

From the deployed *.pages.dev URL or custom domain:

1. load the app without a creator session;
2. perform a real runtime request;
3. verify authentication, quota, payment, and Turnstile behavior if enabled;
4. confirm failures do not reveal secrets or provider payloads;
5. check that the origin is allowed by the Agent Business runtime policy.

Custom domains must use HTTPS. Add or update the runtime origin policy before directing production traffic to a new hostname.

Downloaded package option

If you choose to host the generated package outside the managed deployment flow, the package remains a static frontend. Configure only browser-safe runtime values, build the package, deploy its dist/ directory, and add the final HTTPS origin to the Agent Business policy.

The package README is the source of truth for its build command. Do not replace the managed runtime URL with a creator-console URL or place server credentials in hosting variables exposed to the browser.

Roll back

Deployment history keeps version identity separate from the mutable production URL. Select a previously deployed version and use the rollback action, then repeat the deployed-origin verification.

A rollback restores generated assets and their recorded configuration. It does not undo unrelated DNS, Cloudflare account, provider, Offer, or runtime-policy changes.