Enterprise capabilities
Capabilities available to enterprise customers rather than on every plan: a dedicated Cloudflare account for tenancy isolation, and Postgres alongside D1 for larger or Postgres-specific workloads.
Most of what Spikefrost does is the same for every customer, and that's deliberate — a platform that behaves differently per account is a platform nobody can reason about. Two capabilities are the exception, because they involve infrastructure provisioned per customer rather than per app.
Enterprise capability
These are enterprise capabilities. Both are provisioned under an enterprise agreement rather than enabled by default on any account, and each is scoped with your team during onboarding. If one is a requirement for you, raise it early so the provisioning work is planned alongside your build.
What's on this tier
| Capability | What it gives you | Status |
|---|---|---|
| Dedicated Cloudflare account | Your apps in an account boundary of their own, rather than shared platform infrastructure | Enterprise agreement |
| Customer-owned account (BYO) | Apps deployed into an account you own and hold the contract for | Enterprise agreement |
| Postgres alongside D1 | A managed Postgres database per app, for datasets or features D1 doesn't fit | Enterprise agreement |
| Data residency | A database in a region you choose | Enterprise agreement |
And for completeness, the enterprise-relevant things that do run today:
| Available now | Where |
|---|---|
| 99.9% uptime SLA with service credits, severity-tiered support | SLAs, limits and quotas |
| SOC 2 Type II, ISO 27001, GDPR data processing agreement | SLAs, limits and quotas |
| Per-app and per-environment isolation of compute and all data | Isolation and tenancy |
| 30-day point-in-time database recovery | Durability and recovery |
| Full commit and deployment audit trail, including every AI action | Observability and audit |
| Role-based access, per-connector permissions, static egress IP | Isolation and tenancy |
| Unlimited environments, branch-based promotion, one-minute rollback | Change management |
That second table matters as much as the first. A surprising share of enterprise requirements are already met by the standard platform, and it's cheaper for both of us to discover that before scoping an engagement.
Start from the constraint, not the capability
The most useful thing you can tell us is why you need something, because the underlying constraint often has a shorter path:
| The constraint | What usually answers it |
|---|---|
| "Our policy forbids shared infrastructure" | Deployment models — and read the isolation model first; per-app isolation satisfies more policies than people expect |
| "Data must stay in a specific country" | A region-selectable database — Postgres alongside D1 |
| "Our dataset is larger than 10 GB" | Postgres alongside D1 |
| "We need Postgres extensions or its SQL dialect" | Postgres alongside D1 |
| "We need to see an audit trail of AI actions" | Already available — Observability and audit |
| "We need an uptime commitment with credits" | Already available — SLAs, limits and quotas |
| "We must hold the cloud contract ourselves" | Customer-owned account, in Deployment models — note the prerequisites |
What these capabilities do not change
Worth stating up front, because it prevents a misplaced expectation later:
- The application model is identical. Same code, same bindings, same deploys, same CLI. An app doesn't know which account it runs in.
- The isolation mechanism is unchanged. Your code still runs in a V8 isolate. A dedicated account moves the account boundary; it does not turn Workers into dedicated hardware. See Isolation and tenancy.
- D1 remains the default. Postgres is an addition for specific needs, not a replacement, and mixing both in one app is normal.
- Nothing here is a migration you perform casually. Moving an existing app between accounts is a re-provision, not a pointer change — the detail is in Deployment models.
Next
- Deployment models — shared, dedicated, and customer-owned accounts compared.
- Postgres alongside D1 — when Postgres is the right call, and what it costs.
- Isolation and tenancy — the isolation you have today, described honestly.
Frequently asked questions
What makes a capability 'enterprise' rather than standard?
Two things: it requires infrastructure or contractual arrangements we provision per customer rather than per app, and it carries a cost floor that only makes sense above a certain scale. These are scoped in an enterprise agreement, not toggled in a dashboard.
Are these available today?
They are provisioned under an enterprise agreement rather than enabled by default on any account. Each is scoped with your team during onboarding, so start the conversation early and the provisioning is planned alongside your build.
Can we get a dedicated Cloudflare account?
That's the deployment-models conversation. The practical default is an account Spikefrost operates for you alone, which gives the same isolation boundary without you taking on Cloudflare entitlements. A fully customer-owned account is possible if you already hold a Workers for Platforms contract.
Should we use Postgres instead of D1?
Usually not. D1 is the right default and covers most applications, including large ones. Postgres earns its place when you exceed D1's 10 GB per database, need Postgres-specific features, or need a database in a region you choose.
How do we start?
Tell us the requirement and the constraint behind it — a data residency obligation, a tenancy clause in your security policy, a dataset size. The constraint determines which capability actually applies, and sometimes the answer is that the standard platform already satisfies it.