Runtime-awake billing

Pay for the runtime only while it is awake.

EnvForge 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.

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.

First-release receipt

First-release pricing receipt.

Pricing copy should make the runtime meter auditable 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.envforge.ai 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 envforge sleep stops service CPU and memory.

Separate costcustomer-cloud resources

Databases, storage, queues, caches, egress, backups, 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.

Operational checks

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

A production-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, backup, and third-party costs remain visible as provider costs outside EnvForge 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
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
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
  1. Shell opens

    A developer or agent runs envforge 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, EnvForge 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 envforge up and signed dev links, then meters only the awake runtime work needed to serve dev.envforge.aitraffic or run services.

  1. Included baselineenvforge up

    Shell access stays ready.

    envforge 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.envforge.ai

    Signed dev links keep their handoff handle.

    The service--workspace--org.dev.envforge.ai 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.

EnvForge meters the awake runtime. Databases, storage buckets, queues, caches, egress, backups, and third-party APIs remain customer-cloud costs so teams can audit 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, backups, retained snapshots, and third-party API usage are not hidden inside EnvForge runtime minutes.

EnvForge 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 envforge up.
  • Customer-cloud resource consumption remains a separate cloud/provider bill, so infrastructure cost stays auditable in the account that owns it.