4 Matching Annotations
  1. Last 7 days
    1. 4.3 Data ownership orgs splits. Newly keeps orgs; run.cloud gets accounts carrying runcloud_stripe_customer_id, max_active_tunnels, credit_limit_usd, spend_limit_usd, and the sandbox meter rollups. They are linked by an opaque external_account_id — a value, not a foreign key. Tables move with their owner. The clean ones (fleet_enrollments, run_cloud_assets, runcloud_ci_*) move first as a rehearsal. usage_ledger and credit_ledger are the hard ones: they FK to both orgs and Newly sessions, and they gate sandbox admission. Recommendation: run.cloud owns its own metering end-to-end, and Newly's spend appears as an invoice line, exactly as it would for any customer. That is more work than sharing a ledger and is the entire point. auth_api_keys splits by configId into two stores.

      we should add orgs to run cloud at the same time

    2. Publish the OpenAPI spec for the existing /run-cloud/* surface before moving any code, and generate Newly's client from it. This is deliberately the reverse of the tempting order, for two reasons. It makes the surface reviewable while it is still cheap to change; and it converts today's comment-based contract into a machine-checked one — today run-cloud/components/LinuxRateToggle.tsx:7 says "Matches control-plane/apps/api/src/billing/pricing.ts", and run-cloud/sdk/src/sandbox.test.ts:9 asserts against the sandboxRoutes.ts route table. Post-split those become silent drift.

      don't we have this already via the docs? docs.run.cloud

    3. One fact must be stated plainly because it is widely assumed the other way: today the session launcher does not run on run.cloud. It runs in a Modal Sandbox (control-plane/apps/worker/src/venueLauncher.ts:9-11 — the only drivers are modal, local, none; there is no run.cloud driver). Papaya changes that: session sandboxes move to run.cloud, allocated through the public API like any customer's. That is the sharpest possible test of the whole split — if our own sessions cannot run on run.cloud's public API, the API is not finished.

      I don't think we need to solve this yet

    4. The image is Modal-native. control-plane/runner-image.json is {"runnerImage": "cp-runner:v13", …} — a Modal tag with no registry host and no digest, built by scripts/build-runner-image.ts:196-204 through Modal's fromRegistry(...).dockerfileCommands(...). It cannot be handed to run.cloud as-is. Moving it is a real improvement on its own terms: a registry reference with a digest fixes the long-standing problem that prod's RUNNER_IMAGE drifts from the repo (terraform owns the env var, and CI deliberately reads the live value rather than inferring it).

      Is this true? I think we support this no?