Skip to content

Tenant-Deployed Cloudflare SaaS

Status: Authored as Tenant-Deployed Cloudflare SaaS v1

A SaaS product deployed as isolated tenant instances or tenant environments on Cloudflare deployable surfaces. This stack treats deployment topology, tenant isolation, promotion, preview exposure, resource ownership, and operational evidence as part of the product contract.

Full rubric

Tenant-Deployed Cloudflare SaaS v1 is the judgeable rubric. Use it when a repository operates tenant-scoped Cloudflare deployment surfaces.

Reference implementation

vibecodeqa/ref-cloudflare-saas. This repo is one product-neutral fixture, not the definition of the stack. It combines React, Pages Functions, D1, a Worker MCP surface, SDK/CLI packages, CI, runbooks, and a tracked VCQA report so the standard can be inspected against a working example. Real repositories can omit the frontend, MCP surface, SDK, CLI, or D1 if their tenant deployment boundary is expressed through other Cloudflare resources. Use the rubric as the source of truth for judgment.

Score evidence Value
Repository vibecodeqa/ref-cloudflare-saas (published)
VCQA report A 91/100
Verification self-reported
Assessed commit 41eb243
Assessed on 2026-07-23
CI run success (2026-07-23)
Independent assessment None published yet. The score above is the reference repo's own claim, not third-party proof.
Catalog entry last verified 2026-08-08

The rubric has stable rule IDs across:

  • suitability and deployment shape
  • tenant resource manifests
  • tenant/environment bindings and secrets
  • preview URLs, aliases, custom domains, and indexing posture
  • promotion gates, data-resource state, rollback, and fix-forward
  • tenant provisioning and deprovisioning runbooks
  • tenant-aware observability, audit, and incident evidence

Reference template map

The reference repo is intentionally richer than the minimum stack. It shows one complete composition so teams can inspect code, config, runbooks, and evidence together. The standard does not require every repository to have each package or surface shown here.

Evidence Where to look What it proves
Example app/API surface app/ One deployable app surface shows static assets, same-origin API routes, tests, migrations, and deployment config together.
Example data migrations app/migrations/ Schema change history is versioned and can be applied in CI/deploy workflows for the tenant data resource used by the template.
Example Cloudflare bindings app/wrangler.toml Cloudflare project, environment, and resource binding shape are explicit.
Example automation surface packages/mcp-worker/ Tenant operations can expose a remote Worker/MCP surface without mixing it into the frontend.
Example typed automation packages packages/sdk/, packages/cli/ Contracted automation has typed package boundaries rather than ad hoc scripts.
Tenant manifest docs/tenant-manifest.example.json Tenant resources, environments, and deployment ownership can be named and reviewed.
Tenant runbooks docs/runbooks/ Provisioning, promotion, rollback/restore, and incident response are operational controls in the repo.
Quality gates .github/workflows/ci.yml Tests, builds, and VCQA evidence run before changes are trusted.
Score evidence docs/vcqa-report.md The template carries a tracked VCQA score and visible gaps.

Variants this standard covers

Tenant-deployed Cloudflare SaaS is about tenant-scoped deployable surfaces, not one prescribed product shape.

Variant Covered when
White-label customer app Each tenant has its own project, route, custom domain, Access policy, or environment binding.
Regulated tenant environment Customer data, credentials, databases, storage resources, or deployment approvals are isolated per tenant or tenant environment.
Enterprise single-tenant deployment One customer receives a dedicated production surface with separate promotion, rollback, and incident evidence.
Regional or data-residency tenant Tenant placement affects Cloudflare resources, database/storage selection, secrets, domains, or observability.
Tenant-specific admin/automation plane Workers, queues, MCP servers, CLIs, or SDKs operate tenant resources and must prove scoped permissions and auditability.
Shared app with tenant deploy controls The application artifact is shared, but tenant resource manifests, bindings, domains, secrets, databases, or storage resources vary by tenant.

The standard does not require React, MCP, a CLI, or an SDK. Those appear in the reference repo because they are common adjacent surfaces in a sophisticated Cloudflare SaaS, and because they show how cross-stack standards compose.

What this teaches

Choose this stack when each customer or customer environment needs its own deployable Cloudflare surface: separate projects, Workers, routes/domains, databases, storage resources, secrets, Access policies, or environment bindings. It fits white-label SaaS, regulated customer deployments, tenant-specific release windows, regional data placement, and products where a tenant incident must be contained without taking every customer down.

Do not choose this stack for a normal single-production SaaS, a purely row-keyed multi-tenant app with no tenant-level deployment operations, or a product that cannot fund tenant provisioning, migration, secret rotation, observability, and incident response per tenant. If tenant identity is only an application column and all tenants share one deployable artifact, use lower-level Cloudflare app/API, data-resource, and web-security standards instead.

Architecture flow

Step Boundary What VCQA expects
1 Commit or tenant change Change starts from a tracked commit, tenant request, or manifest update.
2 GitHub Actions gates CI proves build, tests, migrations, deploy config, and VCQA evidence.
3 Tenant manifest Tenant resources, environments, aliases, domains, and owners are named.
4 App/API deployable Pages, Workers, Pages Functions, or another Cloudflare deployable moves as a known artifact.
5 Tenant data resource D1, KV, R2, Durable Objects, or an external database binding has explicit tenant ownership.
6 Worker or automation surface Background, admin, MCP, queue, CLI, or SDK automation uses tenant-scoped bindings and permissions.
7 Access, domains, and aliases Preview, staging, production, and custom domains share the intended auth and indexing posture.
8 Tenant smoke tests Smoke tests prove the deployed tenant surface, not only local code.
9 Deployment and audit evidence Promotion, rollback, incident, and mutation evidence can be reviewed after the fact.

The standard judges whether tenant identity is visible in deployable resources, not only in application rows. A tenant deployment should leave evidence for the artifact, bindings, database state, access perimeter, smoke tests, and rollback path.

Decision matrix

Need Better fit
One production app serving every customer from shared deployables Cloudflare app/API standards plus data-resource and web-security standards.
Row-level multi-tenancy inside one database and one deployment Data-resource standard plus authorization and tenant data checks.
White-label, regulated, or customer-specific deployment surfaces Tenant-Deployed Cloudflare SaaS.
Tenant-specific MCP/admin automation Tenant-Deployed Cloudflare SaaS plus Cloudflare Worker MCP Server when the automation is exposed through MCP.
Customer-specific release windows, rollback, domains, or Access policy Tenant-Deployed Cloudflare SaaS.
No operational budget for per-tenant provisioning and incident response Do not choose tenant-deployed topology yet.

Scope

  • Tenant-deployed SaaS on Cloudflare Pages, Workers, Pages Functions, or related Cloudflare deployable surfaces.
  • Per-tenant or per-tenant-environment data resources, bindings, secrets, routes, aliases, custom domains, Access policies, or deployment environments.
  • CI/CD promotion from preview to staging to production using GitHub Actions and Wrangler or Cloudflare-managed deployments.
  • Tenant provisioning, deprovisioning, rollback, fix-forward, observability, and audit evidence needed to operate the stack safely.

Not in scope

  • Single-production SaaS with one shared deployment lifecycle.
  • Generic SaaS product management, billing, customer success, or packaging.
  • Generic Cloudflare account administration that is not tied to tenant deployment isolation.
  • Non-Cloudflare deployment targets.

Upstream references

D1 references apply when the tenant data resource is D1. Equivalent backup, restore, migration, and isolation evidence is expected for KV, R2, Durable Objects, or external database bindings used as tenant data resources.

Composes

VCQA-owned rule surface

  • Tenant instance isolation and resource ownership.
  • Staging/production promotion gates and branch controls.
  • Preview deployment safety for URLs, data, secrets, and indexing.
  • Per-tenant data resource, migration, backup, and restore expectations.
  • Per-tenant and per-environment secret and binding boundaries.
  • Deployment alias, custom-domain, and Access/auth perimeter.
  • Tenant provisioning, deprovisioning, and change documentation.
  • Rollback and fix-forward expectations for code, config, and data state.
  • Tenant-aware observability, audit trails, and incident evidence.

Detection signals

  • Multiple Cloudflare Pages projects, Workers, routes, custom domains, or aliases named by tenant or tenant environment.
  • wrangler.toml, wrangler.json, or generated deployment config containing [env.<name>], [[d1_databases]], vars, secrets, routes, or Pages project names that vary by tenant.
  • GitHub Actions workflows that deploy to Cloudflare with tenant, staging, preview, or production environment names.
  • Cloudflare Access policies, preview URL settings, branch deployment controls, or custom preview aliases.
  • Tenant provisioning docs, tenant manifests, account mapping docs, customer-specific runbooks, or release notes.
  • Data migration commands, tenant database/storage IDs, export/restore scripts, or Time Travel/runbook references.
  • Logs, audit events, alerts, or trace metadata that include tenant_id, deployment alias, environment, actor, commit SHA, or Cloudflare deployment/version ID.

Combination-born guidelines

  • Tenant boundaries must be deployable boundaries. A tenant deployment must map to named Cloudflare resources, and shared resources must be called out explicitly with the compensating isolation model.
  • Preview is not staging. Cloudflare Pages and Workers preview URLs are useful for PR validation, but their URL behavior and bindings must be treated as exposure decisions.
  • Tenant secrets and data resources must not be shared across preview, staging, and production unless the repo documents the shared-infrastructure design and tests the authorization boundary.
  • Promotion must move known artifacts forward: commit, Worker version, deployment, migration set, tenant manifest, and approval evidence.
  • Deployment aliases and custom domains are part of the auth perimeter. They need the same access, indexing, DNS, and data-safety review as the underlying deployment.
  • Data rollback is a product runbook, not just a platform feature. Code rollback and data restore/fix-forward need separate decisions and evidence.
  • Provisioning docs are operational controls. Resource creation, bindings, secrets, Access policies, migrations, DNS, smoke tests, and audit setup must be reproducible.
  • Observability must be tenant-aware. Logs and audit trails should include tenant, environment, actor, deployment/version, and data target.

Rule highlights

  • R-FIT-1: Tenant deployment boundary is justified.
  • R-RESOURCE-1: Tenant manifest lists Cloudflare resources.
  • R-ENV-1: Bindings are scoped by tenant and environment.
  • R-PREVIEW-1: Preview deployments are access-controlled or public-safe.
  • R-PROMOTE-1: Promotion gates name tenant, environment, and artifact.
  • R-DATA-1: Tenant data-resource isolation is the default; D1-backed variants apply the D1-specific rubric.
  • R-ROLL-1: Rollback and fix-forward cover code and data state separately.
  • R-PROV-1: Tenant provisioning is repeatable.
  • R-OBS-1: Logs carry tenant and deployment context.
  • R-AUDIT-1: Mutating tenant operations create audit evidence.

Limitations

  • Tenant isolation is judged from declared topology and its enforcement points. A manifest plus per-tenant bindings is evidence of a model; it is not proof that no request can cross a tenant boundary.
  • Most of the surface lives outside the repository. Cloudflare projects, custom domains, Access policies, and per-tenant secrets are configured in the platform, so the rubric asks for repo-visible declarations and CI evidence and falls back to evidence-only where a repo cannot show them.
  • The reference repo is deliberately richer than the minimum. Do not read its React, MCP, SDK, or CLI packages as required composition; each is judged by its own standard.
  • Provisioning and deprovisioning are judged as runbooks. VCQA can require the procedure to exist and name its evidence; it cannot verify it was followed for a given tenant.
  • Cost, quota, and noisy-neighbour behaviour are out of scope for v1, even though they are real operational risks of tenant-per-deployment topologies.

Anti-patterns

  • Treating tenant isolation as a naming convention while all tenants share one production database/storage resource, secret set, or integration credential.
  • Letting PR previews use production secrets, production data bindings, production webhooks, or production tenant API credentials.
  • Publishing preview URLs or readable aliases without Cloudflare Access, app auth, or explicit public/noindex review.
  • Running tenant production deploys from a local laptop with no CI approval, deployment record, or reproducible artifact.
  • Promoting by rebuilding from a branch instead of referencing the tested commit, deployment/version, migration set, and tenant manifest.
  • Assuming a code rollback also rolls back schema or data.
  • Leaving tenant provisioning as an ad hoc checklist outside the repo or customer operations docs.
  • Logging request data without tenant context, or logging tenant secrets and tokens while trying to make operations auditable.

Benefits

  • Defines when tenant-deployed Cloudflare is the right architecture rather than a default SaaS deployment shape.
  • Raises preview URLs, aliases, bindings, secrets, and data state to first-class production-readiness concerns.
  • Gives Cloudflare SaaS repositories a reusable path to tenant-safe provisioning, promotion, rollback/fix-forward, observability, and auditability.

Maintenance

Maintenance Value
Latest edition Tenant-Deployed Cloudflare SaaS v1
Pin reports and scans to /standards/tenant-deployed-cloudflare-saas/v1/
Last reviewed 2026-07
Next review due 2027-07
Edition targets cloudflarePagesFunctions latest, cloudflareD1 latest, cloudflareWorkers latest, mcp 2025-11-25
Lifecycle active
Errata none
Composes cloudflare-workers, github-actions, web-security, docs-kb

Editions are cut on material change, not on a calendar. A review that finds the edition still correct moves Last reviewed forward without a new edition. Metadata lives in standards/registry.json.

Independent Assessment