Designing Cloudflare account boundaries

Designing Cloudflare account boundaries
  • Design
  • Operations

How deployment permissions, budgets, and incident response shaped the boundary between our domain and application.

Account boundaries

Domain and application boundaries

The existing account handles public ingress and email sending. The dedicated account runs the application.

Who should be able to change what?

If every website release required access to company DNS and email settings, a leaked credential or a configuration mistake could affect more than the website. The OCR demo also brings usage-based costs. We created a dedicated Cloudflare account for the website and kept company domain management in the existing account.

The existing account owns DNS, the public entry Worker, the sending domain, and outbound notifications. The dedicated account owns site deployment, inquiry storage and notification processing, OCR, and previews for review.

Deployment permissions and usage limits

The application’s CI credentials are scoped to deployments and application resources, with no DNS editing permission. The job that updates the public entry point still needs credentials for the existing account, so we keep those separate from the application’s credentials. Production forwarding, preview access, and CI deployments each have their own authentication. The account boundary gives us a place to enforce separation, and credential scopes determine which operations are allowed. Cloudflare account roles

The application enforces a daily OCR request limit, while AI Gateway budget rules track estimated AI usage costs by purpose. We review the overall bill separately, including Workers subscription fees and email sending. We also check how each Cloudflare product applies its quotas, since their scope varies by product.

Responsibilities that still cross the boundary

Because the public domain stays in the existing account, its entry Worker forwards requests to the application over authenticated HTTPS. The public path depends on both Workers and their authentication. During incidents, we check the entry point and application separately. Credential rotation requires coordinating settings on both sides.

The dedicated account accepts inquiries and retries notification jobs. Cloudflare Email Sending belongs to the account that holds the sending domain’s DNS zone in this setup. The application therefore calls the existing account’s send API. We check inquiry storage and inbox delivery separately. Email Service domain configuration

When an account boundary makes sense

Separate accounts are useful when projects need independent owners for deployment permissions or budgets. When ownership and budgets are shared and only processing or deployment needs to be separate, Workers within one account can communicate through Service Bindings. At PixelCat, separating domain administration from site deployment was worth the extra forwarding hop and the dependency on the existing account for email sending. Cloudflare Service Bindings

Back to Articles & news Discuss your project