EFEnvForgeJoin waitlist

Instant shell. Background runtime.

Cloud workspaces for AI-assisted development.

Run envforge up, choose a workspace, and land instantly inside an org-owned shell VM with your code, Git, Claude, and Codex. EnvForge starts your runtime in the background so web, API, database, storage, mail, logs, and signed dev links can report readiness as they come online.

Start with the CLISee runtime pricing

Why it exists

AI can write code fast. The slow part is giving it a real environment.

Local setup, half-wired services, missing databases, broken dev links, and manual testing slow down the loop. EnvForge keeps the shell ready and wakes the runtime only when the work needs it.

First release

First-release product contract.

The public story should make the first product boundary readable: a shell opens immediately, service runtime wakes later, and every reviewer handoff stays scoped by organization, workspace, service, signed session, and billing state.

Open first workspace docsReview trust model
VM tenancyone-org-per-VM

Each shell and runtime VM belongs to one customer organization. Branch workspaces can share that organization boundary, but cross-customer code, dev traffic, service processes, and logs never co-tenant.

IdentityAuth0 + EnvForge roles

Auth0 identifies the user and organization login context. EnvForge still authorizes product actions such as workspace access, signed dev link issuance, billing visibility, and root policy changes.

Public reviewsigned dev.envforge.ai URL

The public handoff is a signed dev.envforge.ai URL for service--workspace--org.dev.envforge.ai. The signed session gates app, /api, asset, and realtime traffic before runtime wake; it is not a production availability promise for every generated host.

Billingawake-only runtime billing

Shell opens before the runtime meter starts. Runtime billing begins only when web, API, workers, tests, resources, or signed dev traffic wake the selected runtime size.

Hosted workspace proof

The hosted loop should be legible from one receipt.

A buyer should be able to trace the workspace from command, to public review URL, to isolation boundary, to billing trigger without reading the docs first.

proof pointfirst workspace
  • CLI opensenvforge up

    The branch workspace shell VM opens first with Git, tmux, Claude, Codex, logs, and repo storage ready before runtime billing starts.

  • Host scopes*.dev.envforge.ai

    The public handoff uses a signed dev.envforge.ai link for service--workspace--org.dev.envforge.ai, covering web, /api, assets, and realtime traffic only.

  • Tenant isolatesone-org-per-VM

    Shell and runtime VMs are assigned to one customer organization, so another customer's code, processes, logs, and dev traffic never co-tenant.

  • Meter followsshell included / runtime awake

    Shell access stays included while asleep; Small, Medium, or Large runtime billing begins only when service work, tests, or signed dev traffic wakes services.

Operational readiness

A first workspace should come with a reviewable receipt.

The public site should set the bar for a usable hosted handoff: reviewed repo setup, named access surfaces, visible readiness, and a clear runtime cost boundary before anyone shares the link.

Repo contract reviewedenvforge.yml PR

Service commands, ports, inputs, dev routes, runtime defaults, and smoke checks are reviewed in the repository before branch workspaces depend on them.

The hosted workspace should not be a surprise diff.
Access surfaces namedAuth0 + signed links

The handoff names who can open the shell, who can issue signed dev links, which reviewer routes are allowed, and which admin surfaces stay closed.

Product access replaces raw VM handoffs.
Readiness is visibleready / waking / blocked

Shell, runtime, services, resources, checks, and signed dev links report a state before a reviewer is asked to use the workspace.

A link without readiness is not a useful handoff.
Cost boundary statedshell included / runtime awake

The workspace receipt says which actions can wake the runtime meter, which customer-cloud resources remain separate, and when idle sleep stops billing.

Cost follows awake service work, not workspace existence.

Product loop

From envforge up to asleep runtime.

The shell opens first. The runtime wakes only for service work, powers full-stack dev URLs, and sleeps again so runtime billing follows actual awake usage.

  1. envforge up

    Run envforge up

    Choose the prepared branch workspace from the CLI and attach before service boot becomes the blocking step.

  2. shell VM: ready

    Shell VM is ready

    Git, tmux, Claude, Codex, tests, and logs are available immediately on the org-owned shell VM before runtime billing starts.

  3. runtime: waking

    Runtime wakes in background

    Web, /api, database, cache, mail, storage, workers, and checks wake behind the shell and report readiness without blocking shell access.

  4. dev URL: signed

    Signed dev.envforge.ai URL

    A signed service--workspace--org.dev.envforge.ai link covers web, same-origin /api, assets, and realtime paths after gateway verification.

  5. billing: awake only

    Sleep stops runtime billing

    When service work goes quiet, the runtime meter stops while the shell VM and workspace state remain ready.

Humans + agents

Built for humans and agents.

EnvForge treats Claude, Codex, and developers as peers in the same workspace. The shell is available immediately; the runtime wakes behind it and reports readiness shortly after.

Immediate shell

Attach first, then let services catch up.

A developer, Claude, or Codex can run envforge up and get immediate shell access to the branch checkout with Git, tmux, editors, tests, logs, and normal developer tools.

Shared context

Agents work where humans debug.

Claude and Codex stay inside the same terminal context a developer can inspect, with prompts, diffs, Git status, and tmux panes tied to one workspace.

Runtime shortly after

The app stack wakes in the background.

EnvForge starts the selected runtime behind the shell so web, API, database, cache, mail, storage, and signed dev links report readiness shortly after access opens.

Dashboard screenshots

The product surface should show the workspace receipt, not just the command.

Buyers need to see the same state a developer or agent will rely on: shell readiness, runtime wake, signed dev link scope, access boundary, and awake-only usage in one dashboard view.

app.envforge.ai/acme/scheduler/signed-links
Branch workspace

signed-links

bravara/scheduler / service web / org acme

runtime waking
Shellready

Git, tmux, Claude, Codex

Runtimewaking

Small / web + api

Billingawake-only

00:18 current session

Readinessenvforge up
  • webready

    signed dev link issued

  • apiwaking

    /api route warming

  • postgresready

    reference injected

Signed dev link38 min
web--signed-links--acme.dev.envforge.ai

Web, /api, assets, and realtime allowed.

SSH, secrets, logs, root, and runtime admin blocked.

shell includedruntime awake-only$0.42 est.
Workspace receipt

The dashboard names the branch, repo, shell state, runtime state, and current readiness without asking someone to parse raw VM details.

Review link scope

Signed dev links show the service, workspace, organization, expiration, and blocked surfaces before a reviewer opens the app.

Cost boundary

Usage panels separate the included shell baseline from Small, Medium, or Large runtime minutes while the workspace is awake.

CLI docs

The terminal is the front door.

EnvForge starts from the command line because that is where developers, Claude, Codex, Git, tests, and logs already meet. The dashboard can explain state later; the CLI is the reliable entry point for opening workspaces.

  1. envforge up

    Enter through the CLI

    Authenticate, choose an organization, pick a repo workspace, and attach to the always-ready shell before runtime work finishes booting.

  2. envforge repo connect

    Record the environment contract

    Create the envforge.yml that declares service commands, ports, dev routes, resources, and inputs next to the application code.

  3. envforge prepare-pr

    Review setup before rollout

    Open a small onboarding PR so teams can review the workspace contract before branch workspaces depend on it.

A successful envforge up lands in the shell first, then shows dev URL, runtime, and resource readiness as background work completes. Users never need the VM hostname or raw cloud credentials to start a workspace.

Repo onboarding

Prepare the environment in a reviewable PR.

Keep environment setup in the repo with the code. EnvForge adds a concise envforge.yml that records commands, ports, resources, and service inputs, then opens a setup PR before any branch workspace depends on it.

envforge.ymlcommitted with the repo
repo: github.com/acme/scheduler
prepare_pr: true
services:
  web:
    command: npm run dev
    inputs:
      api_url: required
    environment:
      API_URL: input.api_url
  api:
    command: npm run api
    inputs:
      database_url: required
    environment:
      DATABASE_URL: input.database_url
resources:
  postgres: branch_scoped
  1. envforge repo connect

    Attach an existing Git repo

    EnvForge keeps one envforge.yml per repository, committed beside the app so every branch inherits the same workspace recipe.

  2. services.inputs

    Declare what services need

    Web and API services request URLs, database credentials, cache endpoints, and mail sinks as inputs instead of depends_on timing.

  3. envforge prepare-pr

    Open a reviewable setup PR

    The onboarding change is small enough to review: commands, service inputs, ports, dev routes, and environment wiring.

Workspace includes

Everything a full-stack dev URL needs.

  • Always-ready shell
  • Live web dev URL
  • Live API dev route
  • Workspace database
  • Redis/cache namespace
  • S3-compatible storage
  • Mail sandbox
  • Signed dev links
  • Logs and events

Signed dev links

Every workspace gets a signed dev.envforge.ai door.

Share a dev link that exercises the same web app, same-origin /api, assets, and realtime paths your agent is changing. The signed link opens a workspace-scoped session, while SSH, secrets, logs, runtime admin tools, and private resource consoles stay blocked by default.

https://web--signed-links--bravara.dev.envforge.ai

Signed session

Reviewer dev session is live

Expires in 38 minutes

Web appSame-origin /apiStatic assetsWebSockets
  • SSH stays closed
  • Secrets stay hidden
  • Logs stay private
  • Runtime admin stays private
  • The signed URL creates a workspace-scoped browser session for one service, workspace, organization, and expiration before traffic reaches the runtime.
  • That session covers the dev surface for the workspace: web app, same-origin /api, assets, and WebSockets. It is not just frontend access.
  • Old signed dev links stop working when the session expires or is revoked; DNS stays stable.
  • Public reviewers never receive SSH, secrets, logs, runtime admin, or private resource consoles.

URL model

One dev wildcard, scoped down to the workspace.

EnvForge uses dev.envforge.ai for workspace dev links, not production traffic or raw VM hostnames. Dev links resolve through wildcard DNS, so opening a new branch workspace does not require a new DNS record. The public host keeps the target scope in one short left-hand label: <service>--<workspace>--<org>.dev.envforge.ai. Because a single wildcard DNS record catches one host label, EnvForge uses -- separators instead of nested DNS labels. Long slugs are abbreviated deterministically when needed, then the signed dev link creates the workspace-scoped browser session before traffic reaches any runtime.

Dev host

web--signed-links--bravara.dev.envforge.ai
wildcard
*.dev.envforge.ai
dns records per workspace
0
slug length
abbreviated when needed
  • Service<service>

    Uses a short service slug such as web, api, or worker so the public host stays readable.

  • Workspace<workspace>

    Pins traffic to the branch-backed workspace, with long slugs abbreviated when needed.

  • Organization<org>

    Keeps the hostname and signed session inside the owning organization boundary.

This is a naming and session contract, not a promise that every possible host is serving traffic. Share a link after the workspace service is bound, ready, and issued as a signed dev link.

  • Wildcard DNS

    Dev links use *.dev.envforge.ai, so new workspaces and services route through the gateway without per-workspace DNS records. Because the wildcard matches one host label, EnvForge encodes service, workspace, and org together as service--workspace--org.

  • Short scoped host

    Generated hosts use service--workspace--org.dev.envforge.ai, keeping the service, branch workspace, and organization visible without nested DNS records.

  • Abbreviated slugs

    Long service, workspace, or organization slugs are shortened deterministically when needed so the same workspace keeps a stable, unambiguous dev link.

Usage model

Awake-only runtime pricing

Choose a runtime size. Pay while the runtime is awake. Your shell stays ready so envforge up is instant.

Small

1 vCPU reserved

4 GB RAM reserved

up to 2 shared vCPU / 8 GB burst

Medium

2 vCPU reserved

8 GB RAM reserved

up to 4 shared vCPU / 16 GB burst

Large

4 vCPU reserved

16 GB RAM reserved

up to 8 shared vCPU / 32 GB burst

Meter behavior

Only the background runtime is metered.

  • Wakes on demand

    Signed dev link traffic, test runs, and agent jobs start the runtime only when they need web, API, or service processes.

  • Sleeps after idle

    When runtime work goes quiet, EnvForge winds down the metered VM and keeps the workspace shell available.

  • Shell stays included

    Git, tmux, editors, Claude, Codex, logs, and repo storage stay ready outside the runtime meter.

Shell and workspace storage are covered by the organization minimum or included usage credit. Runtime billing stops when the runtime sleeps.

Billing guardrails for awake runtimes.

  • The meter starts when service processes wake on the VM, not when a developer opens the shell.
  • Idle sleep stops runtime billing while keeping the Git checkout, shell, and workspace metadata available.
  • Runtime size sets the reserved capacity for awake periods; burst capacity is shared and opportunistic.

Security / trust

Trust boundaries built into the runtime.

EnvForge separates the customer VM, root policy, secrets, dev links, and runtime meter into explicit boundaries a team can review before agents start changing code.

Organization VM

One customer organization

Workspaces, service processes, signed sessions, and billing events stay inside the owning organization boundary.

  • IdentityAuth0 org membership
  • SecretsSSM SecureString
  • Dev linkSigned service/workspace/org session
  • MeterAwake runtime only
  • VM isolation

    One organization per VM

    Each runtime VM is assigned to one EnvForge organization. Branch workspaces can share that organization boundary, but another customer organization never lands on the same VM.

    No cross-customer code, dev traffic, or service processes share a VM.
  • Root policy

    Root is governed by org policy

    Teams choose disabled root, approved break-glass root, or workspace elevation as an explicit product policy instead of inheriting whatever the base image allows.

    Elevation is deliberate, reviewable, and narrow enough to explain.
  • Secrets

    SSM SecureString secrets stay out of dev links

    Workspace secrets are stored as AWS SSM SecureString parameters protected by KMS and injected into declared service inputs at runtime. Signed dev links and browser sessions never reveal raw secret values.

    Platform secrets stay in the control plane instead of being copied into shell or runtime hosts.
  • Signed dev links

    Dev sessions stop at the app boundary

    A signed dev link binds one browser session to one organization, workspace, service, and expiration before traffic reaches the runtime.

    SSH, secrets, logs, private network access, and runtime admin tools remain outside the dev URL surface.
  • Billing and sleep

    The runtime meter follows awake work

    Dev URL traffic, tests, and agent jobs wake the runtime. Idle sleep stops runtime billing while the shell, Git checkout, and workspace metadata remain ready.

    Teams can reason about cost without shutting down the developer shell.

Security and access

Security access stays inside explicit boundaries.

EnvForge keeps the access story narrow: customer organizations get exclusive VM boundaries, users enter through Auth0, signed dev links expose only the app surface, and platform secrets stay off shell and runtime hosts.

  • Org-exclusive VM boundary

    No shell or runtime VM is shared across customer organizations. Workspaces can share the owning organization boundary, but cross-customer code, service processes, dev traffic, and logs never co-tenant on the same VM.

  • Auth0 login

    CLI and dashboard access start with Auth0 sign-in. EnvForge then checks organization membership, product role, and workspace permissions before opening shell or admin surfaces.

  • Signed dev links

    Signed dev links create expiring workspace-scoped browser sessions for one service, workspace, and organization. By default they block SSH, secrets, logs, runtime admin, and private consoles.

  • Tailscale private access

    Teams can choose optional Tailscale private access for shell or private services through tagged devices instead of exposing those services on the public dev gateway.

  • Root policy

    Root is a named organization policy: disabled, approved break-glass, or workspace elevation. Elevation is scoped and auditable, and it does not widen signed dev links.

  • Platform-secret separation

    Platform secrets stay in the EnvForge control plane, out of shell and runtime hosts. Workspace secrets use SSM SecureString/KMS references and are injected only as declared runtime inputs.

Isolation model

One organization per VM.

  • VM tenancy

    A VM belongs to exactly one organization. EnvForge does not place another customer organization on the same VM.

  • Workspace scope

    Branch workspaces can share the organization VM while keeping hostnames, signed sessions, resource namespaces, and access checks workspace-scoped.

  • Policy boundary

    Identity, signed dev link sessions, private network access, and root policy are evaluated inside the owning organization before workspace access opens.

Root policy

Root is a product decision, not an accident.

  • Root disabled

    Best default for locked-down teams; host-level changes must be captured in envforge.yml or approved base images.

  • Break-glass root

    Useful for rare debugging and package repairs; elevation is approved, time-boxed, and auditable.

  • Workspace elevation

    Fastest for trusted internal teams; requires clear policy because elevated commands can alter runtime state.

Request access

Bring the first workspace online with us.

EnvForge is in a private build. Send the repo shape, organization size, and workspace workflow you want to run first, and we will map it to the CLI, Auth0, GitHub App, signed dev links, and runtime billing model.

npm install -g envforge
access intakeprivate build

This opens an email draft while hosted signup is being wired.