EFEnvForgeJoin waitlist

Docs / Pricing and usage

Usage billing starts after the shell is ready.

EnvForge separates the always-ready shell baseline from awake-only runtime work. Teams can attach with envforge up, choose a runtime size for service work, let auto-sleep stop the meter, and keep live cost visibility while agents, tests, and dev sessions run.

See pricing pageReview workspace lifecycle
usage modelawake runtime

shell: ready baseline

runtime: bills only while awake

size: Small / Medium / Large

sleep: idle auto-sleep stops meter

visibility: live estimate + cap state

Billing boundary

The shell baseline and runtime meter are different layers.

The baseline keeps the collaboration surface ready. Runtime usage starts only when service processes need CPU and memory for dev URL traffic, tests, jobs, or explicit service commands.

Shell baselinealways ready

Git, tmux, editors, Claude, Codex, logs, repo storage, workspace metadata, and signed-link state stay available before the runtime wakes.

Workspace storageretained asleep

The branch checkout, declared artifacts, and workspace identity remain available while service CPU and memory are not running.

Runtime meterawake only

Web, API, workers, tests, database proxy, cache, mail, and storage helpers bill only while the selected runtime is awake.

Usage handoff

A usage receipt should explain the active meter without exposing infrastructure.

Before an agent run, long test suite, or reviewer session is left running, the pricing docs should tell teams what to check: runtime state, cap posture, separate customer-cloud costs, and the receipt EnvForge keeps after sleep.

workspace usagesafe billing view

$envforge workspace usage signed-links

runtime: Medium awake for 37m

wake trigger: signed dev request from web

cap: warn at 80%; stop disabled

customer-cloud: postgres, storage, egress billed separately

sleep receipt: retained after idle sleep

  1. Runtime stateasleep / waking / awake

    Name what is running now.

    A usage handoff should show whether the runtime is asleep, waking, or awake, which size is selected, and which trigger started the session.

  2. Cap posturenone / warn / stop

    Show what happens near the limit.

    Caps should be visible before work starts, then record when the product warned, blocked new runtime work, or let the session continue.

  3. Separate costcustomer-cloud resources

    Do not hide provider spend.

    The usage handoff should call out resource modes and provider-owned costs that are not part of EnvForge runtime minutes.

  4. Sleep receiptwake + sleep timestamps

    Leave evidence after the meter stops.

    After idle sleep or envforge sleep, keep the runtime size, awake window, cap events, and wake trigger available for review.

Security and billing boundary

The meter can sleep, but the organization boundary does not.

Pricing should not imply that sleep, wake, or runtime size changes the trust model. The included shell, signed dev links, root policy, and one-org-per-VM placement remain governed by the same organization boundary.

  1. VM tenancyone-org-per-VM

    Each shell/runtime VM is assigned to exactly one customer organization. Awake or asleep runtime state never places another organization on that VM.

  2. Root policyorg-governed root

    Root stays disabled, approved break-glass, or workspace elevation by organization policy. Runtime wake, sleep, or billing state does not grant root.

  3. Signed dev linksapp boundary only

    Signed dev URLs can wake web, same-origin /api, assets, and realtime traffic for one service/workspace/org session; they do not expose SSH, secrets, logs, private consoles, or runtime admin.

  4. Billing stateshell included / runtime awake

    envforge up and shell collaboration stay included while idle. Runtime minutes start only when service work, tests, jobs, or signed dev traffic wake the selected capacity.

Runtime guardrails

Billing rules should be obvious before a workspace wakes.

The pricing docs should give teams a plain-language contract for which actions stay in the included shell baseline, which actions wake paid runtime capacity, and what evidence appears when caps or auto-sleep change a session.

  1. Does not wakeshell / git / docs

    Opening the shell, editing files, reading logs already captured in the workspace, or reviewing repo metadata should not start runtime billing by itself.

  2. Does wakedev URL / tests / services

    A signed dev URL request, service command, worker run, test suite, or agent task that needs web, API, database, cache, mail, or storage processes wakes the selected runtime.

  3. Stops or warnscap / idle policy

    Workspace caps warn before stopping more runtime work, and idle policy stops the meter after service traffic and background jobs go quiet.

  4. Leaves a recordwake / sleep / cap

    The usage trail records who or what woke the runtime, which size ran, when sleep stopped the meter, and whether a cap changed the session.

Runtime sleep contract

envforge sleep stops runtime billing without deleting the workspace.

Use envforge sleep when the service runtime should stop billing now, but the workspace should remain available for shell work, later signed-link review, and usage-history audit.

runtime sleepbilling off

$envforge sleep

runtime billing: stopped

shell: still available

workspace data: persisted

signed dev URL: can wake later

usage history: wake + sleep recorded

  • Stop metered runtimeenvforge sleep

    Stop paid service capacity on command.

    envforge sleep shuts down the service runtime and stops runtime billing for web, API, workers, tests, and resource helpers.

  • Keep shell accessshell remains

    Keep the terminal handoff alive.

    Sleeping the runtime does not close the workspace shell, tmux session, Git checkout, editors, Claude, Codex, logs, or workspace metadata.

  • Retain workspace datastate persists

    Sleep is not cleanup.

    The repo checkout, declared artifacts, metadata, and signed-link state persist until an explicit cleanup action removes the workspace.

  • Wake from signed linksdev URL wake

    Review links remain useful after sleep.

    A valid signed dev URL can wake the runtime later for app, same-origin /api, asset, or realtime traffic without exposing shell access.

  • Record the lifecyclewake + sleep

    Usage history keeps the billing trail.

    Runtime usage history records who or what woke the runtime and when envforge sleep stopped billing for the awake session.

Runtime sizes

Pick the capacity for the work that wakes.

Size changes affect the awake runtime window, not whether the shell baseline exists. Start smaller for normal branch work and increase only when tests, workers, or agent loops need more reserved headroom.

Small

1 vCPU / 4 GB reserved

Bursts to 2 shared vCPU / 8 GB when the host has room.

Default branch workspaces, light web/API dev routes, and smoke checks.
Medium

2 vCPU / 8 GB reserved

Bursts to 4 shared vCPU / 16 GB for heavier test loops.

Full-stack branches with workers, background jobs, or larger fixtures.
Large

4 vCPU / 16 GB reserved

Bursts to 8 shared vCPU / 32 GB for short compile-heavy windows.

Busy agent runs, large monorepos, and integration suites that need headroom.

Auto-sleep and visibility

Every awake session should show what it costs.

EnvForge should make runtime state visible while work is happening: when the meter started, which size is awake, what the session has accumulated, and whether a cap is close to stopping more service work.

  1. Open shellenvforge up

    The user or agent lands in the workspace shell first. Runtime billing has not started just because the shell is open.

  2. Wake servicesdev URL / tests / jobs

    Signed dev traffic, service commands, smoke checks, or agent jobs wake the Small, Medium, or Large runtime.

  3. Watch usagelive cost panel

    The product shows runtime size, awake/asleep state, current session minutes, estimated spend, and cap status while work runs.

  4. Sleep idleauto-sleep

    When service work goes quiet, EnvForge stops the runtime meter and keeps the shell baseline ready for the next wake.

Current sessionawake minutes + estimate

Developers can see what the active runtime session is accumulating before leaving a dev session, test run, or agent job unattended.

Workspace capwarn before stop

Usage caps should be visible before a runtime wakes and again when the session approaches the configured limit.

State historywake / sleep events

The billing trail records when a workspace runtime woke, which size it used, and when auto-sleep stopped the meter.