Every plan runs the whole stack in your own cloud account. Plans differ by how much platform capacity they cover — never by which applications you're allowed to run.
Capacity is one pool of vCPU-hours per month, measured from the nodes actually running your platform. It exists so the price tracks the size of what we operate — not so it can be used against you.
These are measured shapes, taken from real production platforms rather than from a sizing spreadsheet.
The number of applications you run does not predict the size of your platform. One platform we measured runs a single application at 36 vCPU; another runs two at 32. Size comes from how the node pools are sized — which is exactly why we never gate applications by tier.
Support ladders on response time, not on whether you're allowed to ask. The in-product messenger reaches us from every plan.
| Commitment | Starter | Team | Business | Enterprise |
|---|---|---|---|---|
| In-product support | Included | Included | Included | Included |
| First response | 1 business day | 8 business hours | 4 business hours | 1 hour for P1, 24x7 |
| Escalation | Support queue | Support queue | Named engineer | Named engineer, quarterly review |
| Shared Slack channel | — | — | Included | Included |
| Contractual SLA | — | — | — | Yes, with credits |
The line is labor, not capability. The subscription operates the platform. Building what runs on it is an engagement, priced separately — included at Enterprise, an add-on everywhere else.
BYOC. SSO included. No per-row billing, ever.