Plans & pricing

This page answers the practical questions: what does each plan include, how the pool of included compute works, and what happens when you hit a limit. It's written for both humans and the agents driving DeployMill. When a tool returns an upgrade_required or pool_exhausted error, this is the page that explains what to do about it.

The lineup is Explore (no card) → Builder (card) → Studio (card) → Enterprise (contract). Builder and Studio are the same relationship at different capacity — a card unlocks the same envelope on both; only the included pool and ceilings differ. The marketing-facing pricing cards live at /pricing. This is the operational reference.

The headline: a flat monthly price, a prepaid pool of awake compute, never a usage invoice

Builder is $19/mo flat and Studio is $79/mo flat. There is no meter and no second line item — that price is the whole bill, every month, regardless of how your apps behave. What it buys is a pool of awake compute: 2,000 GB-hours/month on Builder, 10,000 on Studio. A DeployMill app sleeps when it's idle and wakes on the next request; a sleeping app draws nothing from the pool. An awake app draws RAM-GB × hours — a 512 MB app awake for an hour draws 0.5 GB-hours. Run the pool out and apps sleep, not bill: see "Running out of pool" below.

The short version

Agents never consume a seat, and seats are free and unlimited on every plan. The enforced numbers come from the billing catalog, and the values above are the launch defaults — an operator can raise an individual org's pool or storage limits through an entitlement override, but there's no self-serve slider for either.

The pool: how it's spent, and what happens when it runs out

• Only awake time counts. A sleeping app or a stopped preview draws nothing from the pool, no matter how long it's been provisioned. Storage (volumes, objects, database bytes) is a separate, plain included limit (see below) — it doesn't draw from the compute pool.
• The draw rate is your app's RAM tier. A 512 MB app draws 0.5 GB-hour for every hour it's awake; a 1 GB app draws 1.0 GB-hour/hour. At 2,000 GB-hours (Builder), that's roughly five 512 MB apps running truly 24/7 all month; at 10,000 (Studio), about 27 — or many more apps that spend most of their time asleep.
• A preview is an app. An awake preview draws from the pool exactly like a prod app, but previews sleep much faster by default (≈20 min idle) and are reaped on a TTL, so a forgotten preview doesn't eat much pool.
• The pool resets on the 1st of the calendar month, UTC. Usage accrues from the 1st to the end of the month and the pool refills at 00:00 UTC on the next 1st. Your live usage against the pool is always visible (get_account, or the billing dashboard) — there's no surprise, because there's never a bill beyond your flat monthly price to begin with.

The idle window is your pool dial

How long an app stays awake after its last request before it sleeps is your pool dial. Sleep aggressively (a short window) and your apps barely touch the pool. Keep an app always-on (never sleep) and it draws the pool continuously all month. Paid apps tune this per-app or with a workspace default. Free apps are pool-governed like every other tier, but the dial is fixed: a 30-minute window they can't tune, plus a daily awake-minutes ceiling — which is exactly what makes 150 GB-hours last a month on real low-traffic use.

Running out of pool (pool_exhausted)

Because an agent drives the awake compute the pool measures, the pool — not a dollar cap — is the guardrail against a runaway loop. Running it out is a product event, not a billing event: nothing is ever charged beyond your flat monthly price.

• At 80% and 100% of the pool, the org's admins are notified.
• At 100% (pool exhausted): creating a new app and waking a sleeping app or preview are refused with the coded error pool_exhausted, and the maintenance sweep sleeps previews and other idle apps to reclaim headroom. A running production app is not stopped at this point — it keeps serving (its admins are notified) so an agent operating it never sees a silent outage.
• At 125% of the pool (the hard ceiling): the grace above 100% is exhausted, so any still-running prod app is finally slept too, keeping the org's draw bounded.
• Recovering: the pool refills automatically on the 1st of the next month, or an operator can raise the org's pool through an admin-set entitlement override — there is no self-serve "raise my pool" control. In the meantime, sleeping idle apps/previews frees headroom immediately.

Storage: a plain included limit, not a meter

Volumes, object storage, and the managed database are not billed by the GB-hour — each plan just includes a fixed ceiling, checked the same way any other quota is: Explore has no persistent volume (state goes to the managed database, itself capped at 1 GB); Builder includes 10 GB of volume + object storage and 10 GB of managed database, Studio 100 GB and 50 GB; Enterprise gets higher ceilings, operator-adjustable. Storage counts against its ceiling for as long as it's provisioned, independent of whether the owning app is awake or asleep — stopping an app frees no storage headroom, only deleting the app or dropping the mount/bucket does.

Explore: the free discovery tier

Explore is a contained discovery surface, not a tier for real workloads. It never bills — there's no card and no meter — but it is pool-governed like every paid tier, at 150 GB-hours/month. One containment mechanism across the whole lineup; free's pool is just small. A new workspace starts here with no credit card so you can connect your agent and watch it build and rebuild a real app. The MCP endpoint and app-source edits stay fully open. What's withheld is the envelope around running that app for real:

• 1 app, scaffolded from a curated template (no arbitrary repo import). The tutorial app your workspace starts with doesn't use that slot, and doesn't draw on the pool, for as long as its free window is open — see below.
• No persistent volumes: app state lives in the included managed Postgres. That database is storage, not awake compute, so it doesn't draw on the pool — it's bounded by a hard 1 GB size ceiling (maxDatabaseGb); Builder includes 10 GB, Studio 50 GB, Enterprise more. Over the ceiling the app is paused until you free space or an operator raises the ceiling — your data is never deleted.
• deploymill subdomain only (no custom domains).
• No REST /api/v1 or API keys: the agent drives the app over POST /mcp, and the headless/automation surface is paid.
• No object storage, locked egress, locked build recipe.
• No always-on: Explore apps are forced to sleep, and compute size is platform-managed (no custom CPU/memory).
• No read-row SQL (query_database) and no outbound webhooks. Schema inspection (describe_database), in-place restore_backup, and on-demand verify_backup all stay free. What's paid is restore-to-a-new-database (plus swap_database) and the scheduled daily restore drill.
• The "Built on deploymill" badge ships on free scaffolds. A card removes it.
• A short fixed idle window (30 minutes, not tunable) + a daily awake-minutes ceiling, so a free app can't be kept awake 24/7. Running out of the 150 GB-hour pool sleeps apps and returns pool_exhausted — it never bills, because there's no card on file to bill.

The tutorial app

Every new workspace is given one tutorial app: a real, deployed site you learn on by editing it. While its free window is open it costs you nothing — no app slot, no pool draw — so your one Explore app is still free for whatever you actually came to build.

The window is bounded, and that's the deal: before it closes you either keep the app (it becomes a normal app in your workspace and starts counting against your quota like any other) or it's deleted. Your dashboard and the tutorial page both show how many days are left, and we email you a week out and again the day before. Keeping it is refused if you're already at your app limit — you'd have to stop another app or upgrade first, rather than silently spending your last slot.

None of this traps the deploy loop: an agent can create, edit, deploy, preview, and operate a free app end-to-end over MCP.

Builder and Studio: everything unlocked, a flat price with a pool underneath

Putting a card on file flips the entire containment envelope on at once: custom domains + TLS, the REST API + org API keys, object storage, open egress, an editable build recipe, custom templates, arbitrary import, always-on apps, custom CPU/memory sizing, read-row SQL (query_database), restore-to-a-new-database + swap_database, scheduled backup verification, outbound webhooks, and dropping the "Built on deploymill" badge. Seats are free and unlimited. You don't buy app slots, seats, or storage blocks, and you never see a usage invoice: the price is flat. Builder includes a 2,000 GB-hour/mo pool plus a 10 GB storage / 10 GB database ceiling; Studio includes 10,000 GB-hours, 100 GB storage, 50 GB database, and 6-hour backups. SSO and the contracted SLA are not part of the lift-on-pay envelope. They stay Enterprise-only.

Enterprise

Once Builder unlocks everything, Enterprise sells what a card can't: enterprise SSO (SAML/OIDC, operator-registered, with domain auto-join and enforcement), commercial terms (a contracted SLA, DPA, invoicing/net-30), a larger included pool and storage ceilings (50,000 GB-hours / 5 TB storage / 500 GB database by default, operator-adjustable further), and dedicated/custom infrastructure. It's a sales motion. Use the Contact us button on /pricing or email [email protected].

How upgrading works

• Upgrade to Builder from the billing section of your account dashboard, a real Stripe Checkout that captures the card. The moment the subscription is active, every envelope capability turns on together, including the pool.
• Downgrading / canceling Builder drops the workspace back to the Explore floor. Apps already running keep running, but anything over the free ceiling is re-contained, so reduce your footprint before canceling.

If a payment fails (the dunning ladder)

A failed base payment follows a written ladder, not a sudden cutoff:

1. Grace (~7 days): Stripe retries the card, and your apps keep running. Fix the card to recover.
2. Soft suspend: your apps are forced to sleep (not deleted, data and config intact). A wake requires resolving billing.
3. Retention: after a further window, your data/volumes are kept read-only, with a final warning.
4. After the retention window your data becomes eligible for deletion.

Fixing your card at any point clears the dunning state and wakes your apps. Think a charge is wrong? Contact [email protected]. There's a human credit path for billing disputes.

Free-tier build limits

Free (Explore) accounts face two build limits not present on paid plans:

• Per-org rate cap: up to 25 builds per hour and 2 concurrent builds per org.
• Platform-wide build pool: free orgs share a platform-wide pool of 5 concurrent builds maximum across all free accounts. When the pool is full, a new free-org build attempt is refused with code build_queue_full and a retryAfter hint. Wait and retry, or upgrade to Builder for immediate build capacity. Paid builds (Builder, Studio, and Enterprise) are never subject to this pool limit, so they always have headroom.

The build pool exists so that a flood of free-org builds can't starve paid workloads on the shared build node. It is separate from the per-org hourly rate cap. Hitting the pool limit does not consume the org's per-hour budget.

What an agent sees when it hits a limit

Every gated capability returns a structured, coded error, never a silent dead-end. Branch on the code, surface the upgradeUrl (when wired) to the human, and retry once they've resolved it. The same call then succeeds. The codes you'll see:

• upgrade_required: a feature gate (custom domains, the REST API, idle-window tuning) refused because the plan doesn't include it.
• pool_exhausted: the workspace has used up its monthly awake-compute pool (Explore: 150 GB-hours; Builder: 2,000; Studio: 10,000), and the error carries includedGbHours / usedGbHours / remainingGbHours. New app creation and new/idle wakes are refused; a running prod app keeps serving until the 125% hard ceiling. Free up pool by sleeping idle apps/previews, wait for the pool to reset on the 1st, or ask an operator to raise the pool (not self-serve), then retry.
• active_app_limit_reached: starting/deploying another app would exceed the (high) anti-abuse app ceiling. The error carries runningApps so you can suggest a specific app to stop.
• preview_app_limit_reached: same, for the separate ephemeral-preview quota.
• build_queue_full: the platform-wide free-tier build pool is full (5 concurrent free builds). The error carries retryAfter (seconds). Retry after the hint, or upgrade to Builder.
• storage_limit_reached: adding/growing a volume or object-storage bucket would exceed the org's maxStorageGb ceiling. Free space or ask an operator to raise the ceiling.
• database_limit_reached: the workspace is over its managed-database size ceiling (maxDatabaseGb) and its enforcement grace window has elapsed — creating apps and waking database-backed apps is refused until space is freed (drop unused data or apps) or an operator raises the ceiling. Data is never deleted.

// Example shape of a pool-exhausted refusal
{
  "ok": false,
  "errorCode": "pool_exhausted",
  "action": "create",
  "includedGbHours": 2000,
  "usedGbHours": 2000,
  "remainingGbHours": 0,
  "upgradeUrl": "https://deploymill.com/account/billing" // present only when configured
}

Checking your current usage

Call get_account (MCP, or POST /api/v1/tools/get_account) for the authenticated workspace's resolved plan, quotas, current resource counts, and the live usage block: usage.pool (includedGbHours / usedGbHours / remainingGbHours / pctUsed, plus per-app draw rates), usage.storage, and usage.database (each usedGb vs limitGb). That's the read-only view an agent uses to reason about headroom before it spawns another app. usage.pool.poolGoverned is true on every tier, free included — a free workspace reads its 150 GB-hour pool here just like a paid one reads 2,000 or 10,000.