cmux-api: PlatformMachines in staging and production; every team on the stub plan in dev and staging

TE
4d ago
+47-25

NEXT's cmux-api (backend/apps/api) now answers the platform Worker's machine calls (PlatformMachines) in staging and production, not only in development. Classic's backend (web/, /api/vm) is not touched.

Leo, 2026-10-31: "there's not really a point to be so baby gloves with a 'cutover' literally we're the only ones using cmux-next's cloud rn"

What changes

  • src/platform-machines.ts call(): the development/test environment gate is gone. PLATFORM_MACHINES alone turns the entrypoint on. With it off, the existing cleanup-only behaviour stays as it was (find and destroy of the caller's own boots; create and fork only recover existing intents).
  • src/cloud-do.ts platformHost().providerInfo.available: the same environment check is gone. It still requires PLATFORM_MACHINES=on, the direct Freestyle transport and a usable image for this environment.
  • src/domains/cloud-plan.ts:
    • CLOUD_ALLOWED_TEAMS="*" (ALL_TEAMS) now means every team. The stub plan still applies only in STUB_PLAN_ENVIRONMENTS (development, staging, test), so * never gives a plan in production. A restriction (cmuxVmPlan free) still wins, and a paid plan still takes over from the stub.
    • The stub plan gets Max's machine sizes (32 vCPU, 4 to 64 GB memory, 256 GB disk), so dogfood is not capped below what paying users get. The counts stay at 5 active and 10 saved because many DO tests pin them.
  • wrangler.jsonc:
    • development: CLOUD_ALLOWED_TEAMS goes from three team ids to "*".
    • staging: CLOUD_ALLOWED_TEAMS goes from one team id to "*", and PLATFORM_MACHINES is set to "on".
    • production: PLATFORM_MACHINES is set to "on". No stub plan and no CLOUD_ALLOWED_TEAMS.
  • scripts/cmux-next/release/production-approvals.json: adds the PLATFORM_MACHINES=on guarded-var entry. PLATFORM_MACHINES is a guarded var (prod-promote.ts GUARDED_VAR), so without this entry the production promote would hold at G7.

Production still cannot create machines (go-live entitlements are still needed)

Production does not hand out free plans, because that is money. With this PR, production's PlatformMachines answers, but the team's plan still decides creates. A team without a paid plan or grant gets cloud.plan.required, and paid entitlements in production are still off (#26757, held). Production also has no CLOUD_FREESTYLE_SNAPSHOT (no cmuxnp-prod-vmimg- image) and no provider key the promote has checked for. So providerInfo reports available: false and create answers cloud.provider.unavailable until those land. A push to feat-cmux-next deploys development and staging; production picks this up only when it is promoted from main.

Staging: what is still missing for creates to work

  • No staging image exists. I found no cmuxnp-stg-vmimg- id anywhere. cloud-vm-image-bake.yml and cloud-vm-image-promote.yml have only a dev channel and a production channel (prod-copy / names.production), with no staging channel. images/cmux-vm/channels/ holds only dev.json. plans/cmux-next/cloud-github-auth-DESIGN.md (probed 2026-10-27) records staging as "no CLOUD_FREESTYLE_SNAPSHOT in wrangler.jsonc". So this PR sets no staging snapshot, and staging's providerInfo stays available: false (create answers cloud.no_snapshot_configured / cloud.provider.unavailable). cloudConfig accepts only a snapshot with the cmuxnp-stg-vmimg- prefix (CLOUD-DEV-SNAPSHOT), so the dev image cannot be reused as it is. Two steps are needed: a staging bake/copy (a prod-copy-style mode, or a staging channel in the promote workflow), then setting CLOUD_FREESTYLE_SNAPSHOT on staging.
  • The staging Freestyle key is probably missing. No workflow, smoke config or approvals file names a staging CLOUD_FREESTYLE_API_KEY. plans/cmux-next/coordination/backend.md (2026-10-06) says "staging and production have no Freestyle secret". plans/cmux-next/chief.md and chief-done.md say staging Cloud VMs wait on "the non-production Freestyle account". state-placement.md D1 leaves open whether staging reuses the cmux-next-dev key with the cmuxnp-stg- prefix or gets a third key. I can't read Worker secrets, so this is unconfirmed: someone with Cloudflare access should check wrangler secret list --env staging for CLOUD_FREESTYLE_API_KEY.

Development already has both (cmuxnp-dev-vmimg-ci-41198930272-1 and the dev key). There, every NEXT user's personal team can now create through PlatformMachines and the Cloud ops.

Risk

Config and gate removal on NEXT's cmux-api only.

  • Development and staging: every signed-in team gets the stub plan, so Freestyle spend in development (and in staging once it has an image and key) is open to every NEXT user. That is intended (Leo: no caps for users).
  • Production: the entrypoint answers, but with no paid entitlements, image or key it creates nothing.
  • Rollback: unset PLATFORM_MACHINES (the entrypoint goes back to cleanup-only), or put the team list back in CLOUD_ALLOWED_TEAMS.

Tests

  • test/platform-machines.test.ts: the old "inert in staging and production" assertions now check that staging and production answer find and providerInfo and still refuse another person's machine.
  • test/cloud-plan-overrides.test.ts: covers "*" (stub in development, staging and test; none in production; a restriction wins; a paid plan wins).
  • test/cloud-plan-production.test.ts: "*" gives no stub plan in production.
  • test/cloud-routes.test.ts: the size-locked vector asks for 64 vCPU, because the stub now allows the 16 vCPU / 64 GB case.

cmux-platform: this is cmux-api's own PlatformMachines gate and config, the upstream half that manaflow-ai/cmux-platform's workspace machines call; it has not moved.

Agent session: agent session

šŸ¤– Generated with Claude Code