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