Limits and pricing
That the free plan holds one person's GitHub site and refuses past its limits, and the paid plan bills.
Limits and pricing
usage gives what this project has right now (counts of tables, rows, users and files, plus data and file sizes). get_billing gives this month's bill and usage by day (owners, admins and billing only). Cards and payment history are only on the console's billing screen (/billing). When you pass numbers on to a person, include the unit and the time they were taken.
Free plan: one person, one GitHub site, going over is refused
The Free plan is one organisation per account that signs up with GitHub. This is all it does:
- One person (the owner).
invite_memberis refused. - One site from a GitHub repository, deployed to its default address (
*.<zone>). Production deployments only, up to 10 a day. - 30 build minutes and 1 GB of traffic a month. Past them it stops until the 1st of next month; nothing is billed.
- A site with no visits, deployments or console use for 3 days is paused (with an email a day before). Nothing is deleted, and
resume_projector a new deployment brings it straight back. - Not for commercial use.
The database and everything on it (tables, SQL, sign-in, files, realtime, queues, Vault, cron, database webhooks, branches, backups), functions, servers,
the AI gateway, edge config, KV, flags, middleware, analytics, log drains and custom domains are on Pro. Called on a Free project, those tools
are refused with 402 and "This feature is not available on the Free plan. Upgrade to Pro to use it right away."
The project API answers plan_required (402) for the same reason.
The answer is not to retry. Ask the user whether to upgrade to Pro on the console's billing page (/billing).
Moving to Pro needs a person to see the price, the billing start date, the payment method and how to cancel, and agree. No tool does it, and it never happens by itself.
get_plan returns the limits that apply now in free.
Pro plan: ₩62,000 a month (VAT included), overage billed
Paying from abroad (Lemon Squeezy) it is $42 a month, with tax added separately at checkout. The first project, one dedicated 2GB server and three team members are included. Each further project is $16 a month (its own 1GB database machine), each further member $10 a month. A project that rents a server of its own pays only that server's size price. Allowances are for the whole organisation. Nothing is refused; it is billed. What's included and overage prices:
| Metric | Included | Overage price |
|---|---|---|
| Database | 8GB | ₩2,000 / GB-month |
| Files | 8GB | ₩584 / GB-month |
| Data transferred out | 100GB | ₩852 / GB |
| Server memory | 186 GB-hours | ₩65 / GB-hour |
| Realtime messages | 5 million | ₩3,020 / 1 million |
| Concurrent connections | 500 | ₩12 / connection-month |
| Builds | 400 minutes | ₩8 / minute |
| Function calls | 2 million | ₩2,500 / 1 million |
| Function execution (GB-s) | 100,000 GB-seconds | ₩1,500 / 10,000 GB-seconds |
| Cron runs | 200,000 | ₩500 / 100,000 |
| AI agent | 1,500,000 tokens | ₩5 / 1,000 tokens |
| Requests, rows read, rows written | Unlimited | Not billed |
The database price includes the cost of daily backups and the 7-day point-in-time restore copy.
AI agent tokens are counted at the default model (deepseek-flash). If the operator uses a more expensive model, they are counted higher by that cost (4 times for v4-pro).
With the spending cap on, usage stops at the included amount; with it off, the overage is billed.
186 GB-hours of server memory is one 512 MB server for about half a month. The function execution, cron run and server memory allowances were lowered in October 2026 (400,000 → 100,000 GB-seconds, 1,000,000 → 200,000 runs, 372 → 186 GB-hours). An organisation already on Pro keeps the previous allowances until the billing period named in its notice email. included in get_billing is the figure that applies now.
What to know when designing
Calls are free and outgoing bytes are expensive. Traffic leaving Seoul is among the most expensive of Google's prices, and that price is passed on here as it is.
So the way to cut costs is not fewer requests but smaller responses.
- Pick only the columns you need with
select=. Reading a large table withselect=*is what makes most bills. - Give large files such as images and videos long cache headers. Sending the same file twice is counted twice.
- Put a
limiton lists.
Calling usage once to see which metric is actually large before you change anything
is always better than optimizing on a guess.