Spinnery
Sign up

Runtime-awake billing

Pay for the runtime only while it is awake.

Spinnery keeps the organization shell and workspace storage baseline ready, then meters Small, Medium, or Large runtime capacity only while service processes are awake. Auto-sleep stops runtime billing, and customer-cloud resources stay on the cloud bill that owns them.

Start with the CLIOpen hosted onboardingReview trust boundariesSee pricing and security together

Product surfaces

Pricing is easier when each product surface has a meter.

Buyers should not have to reverse-engineer which parts of a workspace bill. The shell baseline, runtime service layer, signed review traffic, and customer-cloud resources each have their own cost boundary.

Shell baselineincluded layer

The workspace handoff stays ready.

CLI entry, Git checkout, tmux, editors, Claude, Codex, logs, metadata, and signed-link state are not charged as runtime minutes.

Runtime service layerSmall / Medium / Large

The service VM is the metered layer.

Runtime capacity bills only while web, /api, workers, checks, or resources are awake for service work, tests, reviewer traffic, or agent jobs.

Signed review trafficdev.spinnery.dev

Review traffic can wake service work.

A valid signed dev link can wake the runtime but never becomes an admin surface for SSH, logs, secrets, root, or private consoles.

Customer-cloud resourcesprovider-owned costs

External resources stay outside runtime minutes.

Databases, buckets, queues, caches, egress, retained snapshots, and third-party APIs stay on the provider bill that owns them.

Organization baseline

Shell and storage are the always-ready layer.

The baseline gives developers and agents a stable place to land before service processes need CPU and memory. It keeps workspace continuity without charging runtime hours for an idle shell.

Organization shell baseline

Every organization keeps the CLI entry point, Git checkout, tmux sessions, editors, Claude, Codex, workspace metadata, logs, and signed dev link state ready outside runtime-awake billing.

Workspace storage baseline

Repo storage, branch workspace metadata, signed-link state, and declared workspace artifacts remain available while the runtime is asleep.

Runtime usage starts separately

Web, API, worker, database proxy, cache, and services reached through signed dev links wake on demand and bill only while the runtime VM is awake.

Launch pricing

First-release launch amounts for evaluation.

These launch prices let teams model a first workspace before rollout. The key boundary is stable: shell and retained workspace state are baseline/storage costs, while runtime sizes bill only for awake service minutes.

Shell baseline$49 / active builder / month

Includes CLI and dashboard access, the always-ready shell handoff, Git/tmux/editor tooling, logs, workspace metadata, signed-link state, and 20 GB of retained workspace storage.

Retained workspace storage$0.15 / GB-month after included storage

Covers branch checkouts, declared artifacts, retained logs, and workspace state while the runtime is asleep or awake.

Small runtime$0.18 / awake hour

1 vCPU reserved; 4 GB RAM reserved; up to 2 shared vCPU / 8 GB burst. Bills only while web, API, workers, tests, jobs, or signed dev traffic keep the runtime awake.

Medium runtime$0.36 / awake hour

2 vCPU reserved; 8 GB RAM reserved; up to 4 shared vCPU / 16 GB burst. Bills only while web, API, workers, tests, jobs, or signed dev traffic keep the runtime awake.

Large runtime$0.72 / awake hour

4 vCPU reserved; 16 GB RAM reserved; up to 8 shared vCPU / 32 GB burst. Bills only while web, API, workers, tests, jobs, or signed dev traffic keep the runtime awake.

Shell-only branch dayspin up + Git + editor work = 0 runtime minutes$0 runtime charge

The shell baseline covers the handoff while no service CPU or memory is awake.

Medium reviewer session37 awake minutes / 60 x $0.36 = $0.22$0.22 runtime charge

A signed dev request wakes Medium for review; asleep time before and after adds no runtime cost.

Large agent burst + storage2 awake hours x $0.72 = $1.44; 12 GB for 15 days x $0.15/GB-month = $0.90$2.34 before baseline and customer-cloud costs

Runtime cost follows the awake burst. Retained storage is separate from asleep runtime minutes.

First-release receipt

First-release pricing receipt.

Pricing copy should make the runtime meter visible before a team lets humans, agents, and reviewers share a workspace. The receipt names what is included, what wakes service capacity, what stops the meter, and what remains a separate cloud resource cost.

Before wakeshell baseline

The CLI, Git checkout, tmux, editors, Claude, Codex, retained logs, metadata, and signed-link state stay available before runtime billing starts.

Wake triggersigned dev.spinnery.dev traffic

The first signed dev request can wake web, /api, assets, or realtime routes when the workspace runtime is asleep.

Meter windowruntime awake window

Runtime billing follows the selected Small, Medium, or Large size until idle auto-sleep or spinnery sleep stops service CPU and memory.

Separate costcustomer-cloud resources

Databases, storage, queues, caches, egress, retained snapshots, and third-party API usage remain visible on the customer cloud or provider bill.

Policy stays onsecurity boundary unchanged

Auth0, root policy, and signed-link state remain active while the meter is off.

Billing language

Name the Shell baseline separately from Runtime awake billing.

The first release should use product nouns consistently: Organization, Project, Workspace, Service, Resource, Shell, Runtime, Access Policy, signed dev link, and CLI. That makes the pricing boundary clear before a customer opens a paid Runtime session.

Shell baselineOrganization + Workspace included

The CLI opens the Shell for the selected Organization, Project, and Workspace. Git, tmux, logs, repo state, and signed dev link metadata stay ready before Runtime billing starts.

Runtime awake billingService + Resource capacity

Runtime minutes begin only when a Service, test, agent job, signed dev request, or Resource helper needs CPU, memory, ports, or declared dependencies.

Access Policynot a meter switch

Access Policy, root posture, and signed dev link scope remain enforced while the Runtime is asleep, waking, awake, or stopping after spinnery sleep.

Wake receipt

Runtime billing should read like a workspace lifecycle receipt.

Pricing needs to make the moment of charge obvious: opening the shell is included, service work wakes paid capacity, the active session shows its trigger and estimate, and sleep stops the meter without deleting the workspace.

Open workspacespin up

A developer or agent lands in the included shell baseline with Git, tmux, Claude, Codex, logs, metadata, and signed-link state. Runtime minutes remain at zero until service work wakes.

Wake service worksigned dev request / tests / jobs

A signed dev request for web or backend /api, test run, worker, or service command can wake the selected Small, Medium, or Large runtime for web, /api, assets, realtime, and declared resources.

Show active costawake minutes + trigger

While the runtime is awake, the page should name the size, wake trigger, current session minutes, estimated spend, cap posture, and separate customer-cloud resource costs.

Stop the meterauto-sleep / spinnery sleep

Idle sleep or spinnery sleep stops paid service CPU and memory while preserving the shell, repo checkout, workspace metadata, workspace event history, and valid signed-link policy.

Operational checks

Pricing should leave a usage trail before and after runtime wake.

A release-facing pricing model needs more than size names. Teams should see what can wake paid capacity, what the active session is accumulating, what sleep recorded, and which resources stay on a separate cloud bill.

Before wakeestimate + cap visible

The pricing surface should show the selected runtime size, cap posture, and what can wake paid service capacity before tests, jobs, or reviewers start it.

During awake worksession minutes visible

An active runtime session should show awake minutes, estimated spend, service state, and the actor or trigger that woke the runtime.

After sleepreceipt retained

Sleep should leave a usage receipt with wake and sleep timestamps, selected size, cap events, and whether signed dev traffic can wake the runtime later.

Separate resourcescustomer-cloud bill

Database, storage, queue, cache, egress, retained snapshots, and third-party costs remain visible as provider costs outside Spinnery runtime minutes.

Awake-only runtime

Runtime hourly billing follows the size that wakes.

Runtime size sets reserved CPU and memory for awake periods. The hourly meter starts when service processes run and stops after auto-sleep, so dev URL traffic, tests, workers, and agent jobs carry the runtime cost only while they need the VM.

Small

Everyday branch work

Reserved CPU
1 vCPU reserved
Reserved memory
4 GB RAM reserved
Burst ceiling
up to 2 shared vCPU / 8 GB burst
Launch plan
$0.18 / awake hour
Medium

Full-stack test loops

Reserved CPU
2 vCPU reserved
Reserved memory
8 GB RAM reserved
Burst ceiling
up to 4 shared vCPU / 16 GB burst
Launch plan
$0.36 / awake hour
Large

Agent-heavy runs

Reserved CPU
4 vCPU reserved
Reserved memory
16 GB RAM reserved
Burst ceiling
up to 8 shared vCPU / 32 GB burst
Launch plan
$0.72 / awake hour
  1. Shell opens

    A developer or agent runs spin up and lands in the workspace shell without starting the runtime meter.

  2. Runtime wakes

    Signed dev traffic, tests, background jobs, or service commands wake the selected Small, Medium, or Large runtime.

  3. Auto-sleep stops billing

    When service work goes idle, Spinnery sleeps the runtime and leaves the shell and workspace storage ready for the next wake.

Usage boundary

What stays ready is different from what bills.

The product plan keeps a workspace handoff ready for spin up and signed dev links, then meters only the awake runtime work needed to serve dev.spinnery.devtraffic or run services.

  1. Included baselinespin up

    Shell access stays ready.

    spin up lands in the branch workspace shell with Git, tmux, editors, Claude, Codex, logs, workspace metadata, and signed dev link state. That baseline is not runtime-metered while services are idle.

  2. Retained dev routedev.spinnery.dev

    Signed dev links keep their handoff handle.

    The service--workspace--org.dev.spinnery.dev host and signed session metadata remain known while the runtime sleeps. A request to web, /api, assets, or realtime paths can wake the selected runtime.

  3. Metered runtimeawake services

    CPU and memory bill only while awake.

    Web, API, workers, tests, database, cache, mail, storage, and queue processes bill during awake runtime periods. Auto-sleep stops the runtime meter without deleting the workspace.

Customer-cloud resources

Resource billing stays with the cloud account that owns it.

Spinnery meters the awake runtime. Databases, storage buckets, queues, caches, egress, retained snapshots, and third-party APIs remain customer-cloud costs so teams can inspect infrastructure spend where the resources are created.

Customer cloud resources

Managed databases, buckets, queues, caches, search indexes, and other cloud resources declared for a workspace stay on the customer cloud account or provider bill.

Usage remains visible

Storage, I/O, egress, retained snapshots, and third-party API usage are not hidden inside Spinnery runtime minutes.

Spinnery tracks the contract

The repo contract records which resources a workspace needs so teams can review cost-bearing infrastructure before branch workspaces depend on it.

Pricing principles to review before rollout.

  • The organization baseline is for always-ready developer access: shell, repo workspace storage, metadata, logs, and signed dev link state.
  • Runtime billing is awake-only: select Small, Medium, or Large, then pay for the periods when service processes are running.
  • Auto-sleep turns off the runtime meter without deleting the workspace or interrupting the next spin up.
  • Customer-cloud resource consumption remains a separate cloud/provider bill, so infrastructure cost stays visible in the account that owns it.