Plans & pricing

This page answers the practical questions: what does each plan include, how is the bill calculated, 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 cap_reached error, this is the page that explains what to do about it.

The lineup is three relationships, not tiers: Explore (no card) → Builder (card) → Enterprise (contract). The marketing-facing pricing cards live at /pricing. This is the operational reference.

The headline: your apps sleep when idle, so you don't pay for idle time

A DeployMill app sleeps when it's idle and wakes on the next request. A sleeping app costs nothing. You pay for the hours your apps are actually awake, not for seats and not for nominal app count. One always-awake 512 MB app costs about half a penny an hour (~$3.65/mo). A hundred apps that are all asleep cost ~$0.

The short version

Agents never consume a seat, and after the move to uptime pricing, neither do humans: seats are free and unlimited on every plan. The enforced numbers come from the billing catalog, and the values above are the launch defaults.

The meter: you only pay while an app is awake

Builder's bill is max($10, usage):

• The $10/mo base is a floor that includes your first $10 of usage. A developer running one or two mostly-sleepy apps rarely sees the meter go past $10.
• Beyond that, awake compute meters at a per-hour rate by app size:

A preview is an app, so an awake preview meters exactly like a prod app, but previews sleep much faster (≈20 min idle) and are reaped on a TTL, so a forgotten preview stays cheap.

The $10 is a floor, not free usage forever. It's framed as a floor on purpose: it covers a couple of hobby apps as a courtesy, but the meter is always running underneath, and your live spend is always visible (call get_account, or open the billing dashboard). So a third always-on app isn't a surprise. You can watch the bill the whole time.

Your billing period is the calendar month (UTC). Usage accrues from the 1st to the end of each month and your invoice lands on the 1st, so the "usage this month" you see on the dashboard is exactly what that month's invoice bills. When you first add a card mid-month, the rest of that month is free of the base fee. Your first full $10 month starts on the next 1st (usage above the included amount still bills). Everything is measured in UTC, so the meter resets at 00:00 UTC on the 1st.

The idle window is your spend dial

How long an app stays awake after its last request before it sleeps is your spend dial. Sleep aggressively (a short window) and the bill stays near the floor. Keep an app always-on (never sleep) and it meters the full month. Paid apps tune this per-app or with a workspace default. Free apps use a short fixed window.

The spend cap (the safety control)

Because an agent drives the uptime being metered, every workspace ships with a conservative hard spend cap (~$20/mo by default). It works in two tiers so a budget never becomes a surprise outage. Over the cap: new app creation and new/idle wakes are paused with a coded cap_reached error and idle previews are slept, but a running production app keeps serving. An admin is pinged to raise the cap (an agent operating the app may never see that ping, so we never silently take prod down). At the hard ceiling (2× the cap): the grace is exhausted, so a running prod app is finally slept too and the bill stays bounded. get_account surfaces both thresholds (capUsd and graceCeilingUsd). Raising the cap is a deliberate, conscious action you take in the dashboard.

Explore: the free discovery tier

Explore is a contained discovery surface, not a tier for real workloads, and it is not metered (no card, no meter). 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).
• No persistent volumes: app state lives in the included managed Postgres. That database isn't billed on Explore, but it's bounded by a hard 1 GB size ceiling (maxDatabaseGb); paid orgs get 50 GB, Enterprise custom. Over the ceiling the app is paused until you free space or raise 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.
• A short fixed idle window + a daily awake-minutes ceiling (so a free app can't be kept awake 24/7).

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: everything unlocked, pay for uptime

Putting a card on file flips the entire containment envelope on at once: custom domains + TLS, the REST API + API keys, object storage, open egress, an editable build recipe, bring-your-own Neon/Supabase, custom templates, and arbitrary import. Seats are free and unlimited. You don't buy app slots, seats, or storage blocks. You simply pay for what you run: uptime, plus metered storage (volumes $0.10/GB-month, object storage $0.02/GB-month, and managed-database storage $0.35/GB-month, each billed by the GB-hour for as long as it's provisioned). SSO and priority support are not part of the lift-on-pay envelope. They stay Enterprise-only.

Enterprise

Once Builder unlocks everything and the meter scales without limit, Enterprise sells what a card can't: identity governance (SSO/SAML/SCIM), spend governance at org-chart scale (department budgets, cost allocation, cap-raise approvals), commercial terms (SLA, DPA, invoicing/net-30), a negotiated usage rate, 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.
• 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 usage invoice 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 metered 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 15 builds per hour and 1 concurrent build 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 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.
• cap_reached: the workspace is over its monthly spend cap, and the error carries mtdUsd / capUsd / remainingUsd. Raise the cap (a human action), 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.
• 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 the ceiling is raised. Data is never deleted.

// Example shape of a spend-cap refusal
{
  "ok": false,
  "errorCode": "cap_reached",
  "action": "create",
  "mtdUsd": 20.0,
  "capUsd": 20.0,
  "remainingUsd": 0.0,
  "upgradeUrl": "https://deploymill.com/account/billing" // present only when configured
}

Checking your current usage and spend

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 spend block (mtdUsd, capUsd, remainingUsd, and per-app burn rates). That's the read-only view an agent uses to reason about cost before it spawns another app.