How App Deployment is billed

A deployment is billed through one service on your account. Every instance it runs is billed at the price of the instance size you chose, on every plan, and you choose whether that is by the hour or by the month. Your plan's allowances cover the rest: build minutes, bandwidth, edge requests and static storage.

A static site runs no instances. It costs nothing within the allowances, and it counts as one of your plan's websites (How account plans work).

Pay as you go

The order charges one hour of one instance at the size's hourly price. From the next whole hour, each hour, we charge the seconds each instance ran at that price, from your credit. A stopped or sleeping instance costs nothing, and the instances of previews are billed the same way. Pay as you go is paid from prepaid credit, so an account billed by invoice cannot order it, and orders monthly per location instead. You can order by the hour once you have added enough credit in total (Unlocking hourly billing).

Monthly per location

You commit to a number of instances and pay for them each month at the size's monthly price, whether they run all month or not. It suits instances that run all the time, and pay as you go suits ones that sleep or run only some of the time. The instances you committed to are covered wherever they run. Instances above that number, such as the extra ones autoscaling starts, are billed by the hour as pay as you go is. On an account billed by invoice, they go on its next renewal invoice instead.

An instance's price can differ from one location to another. The order prices each location you choose (Order any kind).

You can move a deployment from one to the other, or change how many instances you commit to, while its service is active:

1. Open the deployment and go to its Billing tab. How it is billed shows the mode, and the price of an instance-hour or of the instances committed.
2. Select Change…, then choose Pay as you go or Monthly per location. For a commitment, set Instances committed.
3. Check the price and what is due now, then select Change billing.

A new commitment pays for its first whole month from now, and more instances pay for the rest of the month. Fewer instances, or leaving a commitment, return the unused rest of the month to your credit, as a plan change does (Change a service's plan). When your credit does not cover what is due now, Add credit first says so, and the change waits until it does.

Pay as you go is paid from prepaid credit. On an account billed by invoice, choosing Pay as you go shows This change cannot be made, with Pay as you go needs prepaid credit, and this account is billed by invoice: choose Monthly per location. Choose Monthly per location instead, which is also how such an account starts billing a deployment whose Billing tab says Not billed yet.

The deployment's Usage tab shows what it has used and cost this month, and in earlier months.

The allowances are for the calendar month and start again on the 1st. They belong to your account, so all the deployments you pay for share them.

Build minutes

The time each build runs in its build container, from its start to its end, counted to the second. The build container is not an instance, so it is never billed as one (How a release is built).

Bandwidth and edge requests

What the edge sends to visitors, and the requests it answers, at the deployment's addresses.

Static site storage

The files your static sites and hybrid sites hold in their live releases: production, previews that are ready, and releases an alias points at. A file that several releases share counts once. A release kept only for rollback is not counted.

Until account plans open on your account, your deployments have the Free plan's allowances, or the ones Coritan has set for accounts without a plan.

When your deployments have used up an allowance, they stop using more of it, and nothing past the allowance is billed. This is Stop at the allowance, what every deployment starts with:

• previews sleep,
• new builds wait for the next month,
• bandwidth past the allowance goes only to production,
• autoscaling keeps each location at its fewest instances.

Production keeps serving throughout. The deployment's Usage tab says An allowance is used up and marks which one. It is lifted when the month turns, when a bigger plan or a pack raises the allowance, or when you choose Bill past the allowance.

To keep going past an allowance, choose Bill past the allowance on the deployment's Billing tab, under Past an allowance, or when you order it. Each unit past the allowance is then billed: each build minute, GB of bandwidth, million edge requests and GB-month of static storage. It is taken from your credit, or put on your next invoice, up to your spend limits. A deployment stops at the allowance until you choose this, and Stop at the allowance turns it off again.

The price of each unit on your plan is in the order's quote, beside each allowance (Order any kind).

A spend limit caps what one deployment, or all your deployments together, can cost in a calendar month. It counts the month's charges, and each monthly commitment's share of its price for the month.

1. On the deployment's Billing tab, find Spend limits. It has a row for This deployment and one for Every deployment on the account.
2. Open the row's menu and select Set a limit…, or Change… for a limit you have.
3. Under A month, at most, type the amount. Under At the limit, choose Hold back the extras or Stop every instance.
4. Select Save limit.

• We email you when the month reaches 80% and 100% of a limit, and at 50% too while it covers a deployment billed by the hour. The 50% and 80% emails follow your Usage alerts choice, and the 100% email always goes (Email notifications).
• At 100%, the limit does what you chose for it. Hold back the extras, the default, sleeps previews, stops the instances above each location's fewest, makes new builds wait and stops overage, while production keeps serving. Stop every instance stops every instance of the deployments the limit covers, so nothing serves. The Usage tab then says A spend limit is reached.
• For a game server or a database, Stop every instance stops each of its servers that is running. Until the limit lets go, its servers cannot be started or restarted, from their panel, a schedule or the API, and they say This server's deployment is paused by its spend limit. Raise or remove the limit to start it. Stopping one still works. When the limit lets go, the servers it stopped start again, and a server you had stopped yourself stays stopped.
• Either lasts until you raise or remove the limit, or the month turns. Setting a limit you have already reached applies it at once.

A pack raises an allowance this month and every month after, until you remove it. A Build Minutes Pack adds 1,000 build minutes a month, and a Bandwidth Pack adds 500 GB. A pack goes on your account rather than on one deployment: order it on its own, as Add capacity to a service says for a websites pack.

A deployment's billing belongs to the account that pays for it. On a team, members with the Admin or Billing role change it, Read only members see it, and Technical members do not. An organization's deployments are billed to the organization's owner.

A game server or a database in one location is billed by its own plan, as every Container Apps server was: its price, billing cycle, invoices and renewals, with no meters and no spend limit. Manage a server's billing covers its Billing tab, and How hourly billing works covers one billed by the hour. A game server or a database ordered in several locations is billed as any deployment is, pay as you go or monthly per location.

• Order a deployment chooses the size and how it is billed.
• Choose locations and scaling sets how many instances run.
• How account plans work covers the plans themselves.

The billing routes are under /api/v1/billing and answer only to the account that pays for the deployment. GET /billing/deployments/{uuid} says how it is billed and what it has cost this month: billing_mode (payg, commit, or null for a server billed by its plan and a deployment not billed yet), overage_mode (block or allow), payg.hourly_price or commit, its spend limit and the account's, held, which says what is holding it back, and usage by meter.

PATCH /billing/deployments/{uuid} changes it. With ?preview=1 it writes nothing and answers the price: due_now, credit, and payment, which says whether credit or an invoice would pay:

curl -s -X PATCH "https://api.coritan.com/api/v1/billing/deployments/$DEPLOYMENT?preview=1" \
  -H "Authorization: Bearer $CORITAN_TOKEN" \
  -H "Content-Type: application/json" \
  -d '{"billing_mode": "commit", "commit_instances": 2}'

Send {"overage_mode": "allow"} to bill past the allowance, and "block" to stop at it. A change that credit does not cover answers 402 with insufficient_credit, pay as you go on an account billed by invoice answers 422 with prepaid_only, and a server billed by its own plan answers 409 with billed_by_service.

PUT /billing/deployments/{uuid}/spend-limit sets a deployment's limit, and PUT /billing/spend-limit sets the account's, each with monthly_limit and a policy of block (the default) or pause:

curl -s -X PUT https://api.coritan.com/api/v1/billing/deployments/$DEPLOYMENT/spend-limit \
  -H "Authorization: Bearer $CORITAN_TOKEN" \
  -H "Content-Type: application/json" \
  -d '{"monthly_limit": "50.00", "policy": "block"}'

DELETE on either removes it. GET /billing/usage?month=2026-09 lists a month's metered use and charges for each deployment you pay for. GET /api/v1/client/deployments/{uuid}/usage answers one deployment's use against the allowances, without prices, to anyone who can read the deployment.