Usage and Limits

DeployYourApp meters three things against your plan: monthly active users, bandwidth, and storage. This page covers how each number is produced and what happens as you approach or pass a limit.

Usage is recorded per calendar month. A period runs from the 1st of the month to the 1st of the next month, and the counters reset at that boundary.

What blocks and what does not

Read this before anything else on the page.

Apps, channels and team members are unlimited on every plan, so there is nothing to meter and nothing to exceed. Only usage is metered: storage, monthly active users and bandwidth.

Storage is a hard cap — an upload is rejected the moment it would cross the number, with no grace period. It does not reset on a monthly boundary like MAU and bandwidth do, but it is not purely manual either: superseded bundles are reclaimed automatically by the retention policy (see Storage below), and you can also free space sooner by deleting a bundle yourself.

An organization with no active plan is the one exception: every limit drops to zero there, so app, channel and invitation creation is refused until a plan is active again.

MAU and bandwidth allow a 10% grace above the plan limit before anything is blocked. Below the grace boundary nothing is refused. Once an organization goes past it:

• Creating an app, a channel, or a member invitation is refused, the same as if it were past its own hard cap.
• Creating a deployment or a rollback is refused, so no new release can be published.
• Devices stop receiving updates. This is the consequence that matters most: an already-published release — including a hotfix — stops reaching end users the moment the block takes effect, and only resumes once the organization is back under its allowance.

Uploading a bundle is the one write action not affected by an MAU/bandwidth block — only the storage limit and the active-plan check in the row above govern uploads. An upload can still succeed while deploys and update delivery are both blocked; it just cannot be released to a channel or reach a device until the block lifts.

The block lifts automatically when the usage period rolls over to the next calendar month, or immediately on a plan with more room.

Every plan is meant to email at 90% and 100% of the MAU/bandwidth limit, ahead of the block. That email is not implemented yet — only the grace and the block described above are live. Until it ships, the grace period and the block itself are the only warning an organization gets, visible on Settings > Usage and Settings > Billing.

Every one of the limits above additionally requires the organization to have an active or trialing subscription, or a valid admin-granted plan. Without one, every action in this table is rejected — the server's error message says why (trial ended, subscription cancelled, payment failed, and so on) and links to Settings > Billing.

And without one, devices stop receiving updates too. A metered overage is not the only way delivery stops. Every inactive state does it: an expired trial, a cancelled or expired subscription, a past_due subscription after a failed payment, an incomplete one whose first payment never confirmed, and a complimentary plan that has lapsed with no billing behind it. In all of those, the update check answers "no update" for every device in the organization, including for releases published long before. Nothing is deleted in any of them, and delivery resumes the moment the organization is back on an active plan.

Monthly active users

MAU counts unique devices that sent analytics events to POST /api/stats during the calendar month, across every app in the organization.

Both clients emit an update_check analytics event on each update check while analyticsEnabled is true, which is the default. So in practice a device that checks for updates at least once in the month is counted once, no matter how many times it checks.

Counting rules:

• A device is counted once per organization per month. An install that uses several apps in the same organization is still one MAU.
• A device running with analyticsEnabled: false sends no events and is not counted at all.
• The count is recomputed from stored events, not incremented. It is exact for the events that were recorded, not an estimate.
• The count resets on the 1st of each month.

Bandwidth

Bandwidth is credited when the server hands a device a download URL for a bundle. The bundle's stored file size is added to the organization's counter for the current month at that moment.

This means:

• Bandwidth is counted per update served, using the bundle's size on the server.
• Update checks that return no update, status reports, dashboard traffic, and CLI traffic do not count.
• The figure reflects updates offered to devices. It is not measured from the storage or CDN layer, so it will not match a byte-level network trace exactly.

To reduce bandwidth, ship smaller bundles: minify, compress images, and drop assets your app does not need at runtime.

Storage

Storage is the total size of every bundle stored for the organization's apps, summed across all apps, excluding bundles the retention policy has expired (see below) — an expired bundle's database record is kept, but its storage object is gone, so it no longer counts. What still counts:

• The bundle currently active on each channel
• Every retained earlier bundle kept for rollback
• Bundles uploaded but never deployed, until they age out

Storage is no longer unbounded until you delete something yourself. An hourly background pass reclaims the storage object of any bundle that is not among the 5 most recently deployed bundles of any channel and is older than 15 days and is not a channel's active bundle or a channel's rollback target. Retention is per channel and unioned across channels, so being recent on any one channel is enough to keep a bundle's storage counted and its rollback available. A bundle never deployed to any channel is kept only by the age rule — it has no channel to be "recent" on. Full policy and what stays on record after expiry: Bundle retention.

Storage is enforced at upload time against a live sum of your bundle sizes, excluding expired ones, so the check does not wait for the hourly aggregator. An upload that would take you past the limit is rejected with a message showing how much of your allowance is used:

Storage limit reached (19 GB of 20 GB used). Delete old bundles or upgrade your plan.

To free storage sooner than automatic expiry would, delete bundles you no longer need. The dashboard's Bundles page is read-only, so deletion goes through the API:

DELETE /api/orgs/:orgId/apps/:appId/bundles/:bundleId

This requires the bundle:delete permission, which owners and admins hold. Deleting a bundle removes the ability to roll back to it — the same effect automatic expiry has, except expiry keeps the database record (version, checksum, history) and a manual delete removes the row entirely.

Build minutes

Cloud builds are not yet available, so no build minutes are metered and the dashboard shows no build-minutes meter. See Plans and pricing.

Where to see your usage

Settings > Usage shows the current period's MAU, bandwidth, and storage against your plan limits, your app and member counts, and up to 12 months of history.

Settings > Billing shows the same current-period meters alongside your plan and its full limit list.

Meters change colour as they approach and reach their limit.

Freshness

Bandwidth is credited immediately as updates are served. MAU and storage are also recomputed by a background aggregator that runs every hour, so those two figures can lag real activity by up to an hour.

Usage API

Both endpoints require the billing:read permission, which owners and admins hold.

Current period

GET /api/orgs/:orgId/billing

Byte counts are returned as strings because they are 64-bit values:

{
  "billing": {
    "planName": "Scale",
    "limits": {
      "maxApps": 10,
      "maxChannels": 10,
      "maxMembers": 10,
      "maxMau": 10000,
      "maxBandwidthBytes": 1099511627776,
      "maxStorageBytes": 53687091200,
      "maxBuildMinutes": 45
    },
    "usage": {
      "mauCount": 3245,
      "bandwidthBytes": "15432100000",
      "storageBytes": "5242880000",
      "buildMinutes": 0
    },
    "coupons": [],
    "adminGrantedPlan": null
  }
}

usage is null when nothing has been recorded in the current period yet.

History

GET /api/orgs/:orgId/billing/usage

Returns up to the 12 most recent monthly records, newest first:

{
  "usageRecords": [
    {
      "id": "clx0000000000000000000000",
      "periodStart": "2026-07-01T00:00:00.000Z",
      "periodEnd": "2026-08-01T00:00:00.000Z",
      "mauCount": 3245,
      "bandwidthBytes": "15432100000",
      "storageBytes": "5242880000",
      "buildMinutes": 0
    }
  ]
}

Staying inside your limits

MAU — keep development and QA installs in a separate organization, and set analyticsEnabled: false in debug builds so test devices are never counted. Going past the 10% grace stops updates reaching every device in the organization, not only the ones pushing you over.

Bandwidth — reduce bundle size. Every byte you cut is multiplied by the number of devices that take the update, and it is what stands between you and the grace running out mid-month.

Storage — superseded bundles past the 5 most recent per channel and older than 15 days are reclaimed automatically; delete manually only when you want the space back sooner, or want to free a bundle the age rule hasn't reached yet.

Apps, channels, and members — these are hard stops. Delete unused channels, or upgrade. Remember that pending invitations occupy member slots until they expire.

See Plans and pricing for each plan's numbers.