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.

Exceeding your MAU or bandwidth allowance never stops an update being served to a device. There is no overage billing, no throttling, and no automatic plan change. If your organization runs well past its allowance we will get in touch about moving to a plan that fits.

The four blocking limits share one precondition: the organization needs an active or trialing subscription, or a valid admin-granted plan. Without one, every one of those actions is rejected with Active subscription required regardless of the numbers.

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. It includes:

• The bundle currently active on each channel
• Every earlier bundle kept for rollback
• Bundles uploaded but never deployed

Bundles are never removed automatically. Everything you upload counts until you delete it, which is what makes rolling back to any earlier release possible.

Storage is enforced at upload time against a live sum of your bundle sizes, 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, 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.

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.

Bandwidth — reduce bundle size. Every byte you cut is multiplied by the number of devices that take the update.

Storage — delete bundles you will never roll back to. Bundles from superseded releases are the usual culprit. Nothing is cleaned up for you.

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.