# Plans and limits There are three plans: **Starter**, **Publisher** and **Enterprise**. Most of this chapter is about Starter, because it is the one you can reach on your own. **Starter is where you build and test a game. It is not where a game meets an audience.** Registering costs nothing, and scaffolding, the dev loop and playing the game locally all work with no approval needed. A hosted deploy to a public Playground needs your account approved first, which the next section covers. The limits below are sized for development rather than for a crowd, and a game that needs to reach real fans needs Publisher or Enterprise, which a person at Monterosa arranges with you. A limit that is reached refuses, and never charges anybody. That holds on all three plans. A separate mechanism, the rate limiter, throttles a busy game with a retry-after wait instead of refusing outright; it protects the Engine's capacity rather than enforcing a plan. ## Availability now Local inspection, scaffolding and validation work without an account. Running the dev loop and `verify` both require a signed-in session. The hosted Starter path runs on the CLI's own default, `https://api.gamestage.ai`. Sign in, get the account approved, and deploy to a public Playground from the published route with nothing else to configure. Approval is the gate rather than availability: `gamestage login` leaves an account pending and somebody at Monterosa approves it. Gamestage is not commercially launched, so that approval is a conversation rather than a form. ## Dev and prod A game is either **dev** or **prod**, and a game on Starter is dev. Two separate things have to be true before it counts as prod, and you control one of them: * **You approve your own game.** `gamestage promote ` records that approval, and always succeeds for a game that exists and is not archived. Approving your own game is not a purchase, so there is nothing here for a plan to refuse. * **Monterosa moves your workspace onto a paid plan.** Only an operator does that. `gamestage plan live` is refused with `operator_required` and changes nothing. Until both are true the game is dev, and `gamestage promote` tells you which of the two you are waiting on. What is built today is the record and the gate: the approval is stored, and the two are composed into one answer the CLI reports. Serving does not read the approval: a dev game and a prod game are reached the same way and play the same way, so promoting a game records the decision rather than changing what a fan meets. Promotion creates no second deployment and no second id either, so the files, the scores and the leaderboard are unaffected. ## Declared limits Backstage's contract currently defines: | Meter | Starter limit | | --- | --- | | Games in development | 3 | | Live games | 1 | | Monthly devices | 1,000 | | Storage | 250 MB | Monthly devices counts distinct browsers, not distinct people: a player id is minted per session and kept in that browser's storage for that game, so one person playing on a phone and a laptop counts twice. The one-live-game allowance is updated from game state and enforced on deploy and wake. The devices and storage meters are also real: devices sums what each game reports, storage is recomputed from what the bucket actually holds. Meters count real usage; the deploy gate on them is deliberately held empty, so reaching 1,000 devices or 250 MB does not refuse a deploy today. Only the one-live-game allowance actually refuses. Older planning files still call the plan Runtime and name 1,000 concurrent players and 10,000 monthly active players. Backstage's contract has no concurrency meter, so no concurrency figure anywhere is enforced. The App Manifest nomenclature and the contract above are the current source for the plan name and declared meters. One live-game limit means a redeploy of the same live game is allowed. To put a different game live, suspend the first one: ```sh gamestage suspend gamestage wake ``` Suspension is reversible and returns the live slot. Archive is different: it takes the game off the air, retains its record and id, and moves its bundle outside the served prefix. ## What Starter includes * **Shared hosting**: games are served from one shared Playground domain. * **Your own Studio Space**: your workspace gets its own [Space](https://products.monterosa.co/mic/creator-guide/spaces), made on your first deploy. Nothing about it is shared with anybody else's games. * **One live game**: drafts do not consume the live-game allowance. * **Managed Engine rules**: the same built game formats as local development. * **Fantenna Signal, on by default**: per-player engagement collection is switched on for every tier, Starter included, at no extra cost. What is paid is routing that data to your own destinations, which the next section covers. * **No surprise billing**: the contract has refusal and busy outcomes rather than an overage charge. * **Suspend and wake**: sleeping, manual suspend and manual wake states exist. ## What Starter does not include The current entitlement rules reserve these for paid plans: * **Custom analytics destinations**: the manifest can declare destinations, but changing routing is a paid entitlement. Fantenna Signal's own collection is not gated this way; see the previous section. * **In-game bug capture**: on Starter, use your repository's issue tracker directly. * **Prize promotions**: a prize needs human approval and is refused below Publisher. * **A contracted service level**: an SLA belongs to an Enterprise agreement. The manifest can declare a Monterosa Analytics destination. That declaration alone is not proof that analytics is flowing: production ingestion and Studio visibility are separate concerns from the manifest field. ## Reached limits Expected refusals carry a stable code: * **`live_allowance_reached`**: suspend the other live game or change plan. * **`tier_required`**: the declared feature needs a paid plan. * **`operator_required`**: the plan you asked for is one a person arranges. Your workspace is unchanged. A refusal is returned as a normal command result and exits `0`. In JSON, branch on `code`. Do not retry a refusal without changing its cause. ## Paid plans The stored plan keys are `runtime`, `live` and `enterprise`; creator-facing surfaces call them Starter, Publisher and Enterprise. Publisher and Enterprise are human conversations rather than a completed self-serve purchase flow. Paid customer onboarding also needs a Monterosa account and org created by a person. Do not use `gamestage plan` as evidence that commercial approval or dedicated infrastructure exists. `gamestage plan` enforces that. Starter is the only plan a workspace can move itself onto; asking for Publisher or Enterprise is refused with `operator_required` and changes nothing. An operator moves a workspace onto a paid plan out of band. Moving back down to Starter is not refused, because it grants nothing.