Skip to main content
Cloudflare hosting is an advanced operator path, not a one-command local setup. It needs an intended account/domain, authenticated tooling, Docker for runner images, paid runner capacity where required, provider apps and reviewed identity/security policy.

​
Understand the boundaries

Each tenant has distinct Worker/storage/queue/container bindings, keys and Access configuration. The broker separately owns provider app credentials and its signing material. Access reachability does not replace Worker OAuth/token checks or tenant membership. Browser profiles and encrypted test-account credentials remain private.

​
Prepare your own private configuration

The distributable tree contains generic templates in examples/operations/, not actual deployment manifests. Keep reviewed resource claims and recovery material outside the repository. Select them explicitly:
The first directory must already exist and contain your reviewed tenants/<id>.json and broker/manifest.json when commands need them. Absolute out-of-repository paths are required. Unreplaced templates deliberately fail validation. Recover existing signing keys from managed storage; generating a new key is not recovery.

​
Render and check before mutation

With a complete reviewed manifest, pnpm tenant:config -- <tenant-id> renders configuration locally. pnpm exec tsx scripts/tenant.ts release-check <tenant-id> checks release policy without provider contact. These checks do not establish live resource ownership, Access enforcement, applied migrations or deployment readiness. Provisioning commands such as tenant:create, tenant:provision, tenant:onboard, tenant:access and broker setup can mutate remote state. They are not contributor smoke checks. The root Wrangler file is a local development template, not a production target.

​
Release an exact candidate

Use the deployment runbook for operator preparation, manifest preservation, release policy, migration-only exceptions and candidate uploads. The reviewed release path requires exact commit identity, encrypted backups, canary observation and bounded tenant rollout. A production deploy requires clean main matching fetched origin/main and an observed canary on that commit. Do not substitute low-level migrations or a dashboard upload for a reviewed upgrade. A versions upload does not promote traffic, migrate data, update Containers or change Access policy. Held deployments remain held until their actual exit evidence is reviewed.

​
Verify capabilities after deployment

Exercise human identity, membership/roles, token expiry/revocation, finding/artifact access, browser profile isolation and runner health. Verify served source/image identities, alerts and restore. Test webhook reachability separately. The broker supports an explicit githubWebhook manifest binding for one registered installation/tenant and forwards unchanged signed bytes through a service binding to the tenant verifier. Use that reviewed path when browser Access would intercept provider delivery; do not weaken the tenant browser policy. See the deployment runbook for configuration and verify live deliveries after release. The configuration reference, upgrade guide and existing tenant architecture remain companion references. No infrastructure is provisioned by these docs.