Deployment models

Enterprise capability

Three models, one application model. Your code, bindings, deploys, and CLI are identical in all three — what changes is the Cloudflare account boundary your apps sit inside.

The three models compared

That last row is the one people skim past. A dedicated account does not change how your code is isolated — it changes which account owns the resources. Workers are V8 isolates on Cloudflare's shared infrastructure in all three models. See Isolation and tenancy for what that actually guarantees.

Shared platform account

How apps run on standard plans, and for most customers the right answer indefinitely.

Each app gets its own worker, database, key-value namespace, object storage, and Durable Object namespaces, separately per environment. There is no addressing path from one app to another's bindings. What's shared is the Cloudflare account that owns those resources and the underlying infrastructure they run on.

For a large share of security policies, per-app and per-environment isolation is what the policy is actually asking for. Read the isolation model before concluding you need an account boundary — it's a shorter path to the same approval.

Dedicated account, operated by Spikefrost

Your apps in a Cloudflare account that contains nothing else. Spikefrost holds the Cloudflare relationship, entitlements, and billing; you get the account boundary.

What changes:

• Account-level blast radius. Account-scoped events and limits affect only your apps.
• Account-scoped observability. Analytics read tokens are account-scoped, so the read surface contains only your data.
• A cleaner audit story for policies that ask about shared cloud accounts.

What has to be replicated per account, which is why this is an engagement rather than a setting: the Workers for Platforms dispatch worker and namespace, the domain-mappings key-value store, the edge cache, the assets workers, the zone and wildcard DNS, the fallback origin, and the logs pipeline. The dispatch binding cannot cross accounts, so the whole edge stack comes along.

We recommend this over a customer-owned account in most cases: identical isolation boundary, and you don't take on eight Cloudflare entitlements or a second cloud bill to reconcile.

Customer-owned account (BYO)

Apps deployed into an account you own, on your Cloudflare contract, on your bill.

The prerequisite that decides feasibility: because Spikefrost deploys into a Workers for Platforms dispatch namespace, and that binding cannot cross accounts, the namespace must exist in your account. Workers for Platforms is an Enterprise/contract add-on. So your account needs:

Plus an API token with edit permission on all of them.

Be clear-eyed about it: if you don't already hold a Workers for Platforms contract, a customer-owned account is usually the wrong shape — the entitlement burden exceeds the benefit over a dedicated account, which gives the same isolation. Where it is right: you already run Workers for Platforms, or a policy requires the cloud contract in your own name.

Migrating an existing app

This is the part worth planning properly, because the intuition is wrong.

Database identifiers, key-value namespace identifiers, and bucket names are account-scoped. Moving an app between accounts is therefore a re-provision, not a pointer change:

Consequences to plan for:

• A maintenance window. Data copies are point-in-time; writes during the copy need to be paused or replayed.
• Secrets are re-entered by hand. They're never readable back — by design. You'll need the source values from your own vault.
• The domain cuts over with a DNS change and fresh certificate issuance, which takes minutes to propagate.
• Durable Object state does not transfer, and has no export path. If an app holds state in Durable Objects, mirror it to the database first — see Durability and recovery.
• Point-in-time recovery restarts. The new database's 30-day window begins at migration.

The cheap version of this problem: decide the model before you build. A new app provisioned directly into the target account skips all of it.

What doesn't change in any model

• The 99.9% uptime commitment and support severities — see SLAs, limits and quotas
• Cloudflare's underlying Workers SLO, including its exclusion of storage bindings — see Failure domains
• The application model: code, bindings, migrations, deploys, environments, rollback
• The isolation mechanism: V8 isolates, per-app and per-environment data separation

Next

• Postgres alongside D1 — the other enterprise capability, and the one that addresses residency.
• Isolation and tenancy — what your current isolation actually guarantees.
• Enterprise capabilities — the full tier, and what already ships.