EFEnvForgeJoin waitlist

Pricing + security story

Runtime pricing and workspace security share one boundary.

EnvForge keeps collaboration available without pretending every workspace is always running: the included shell baseline stays ready, the runtime meter wakes only for service work, and access controls stay scoped to the organization, workspace, service, and session.

Review pricing detailsReview security controls

Boundary ledger

The same line explains cost, access, and trust.

The marketing story should make the product contract obvious before a buyer asks for architecture detail: what stays ready, what bills, what a reviewer can open, where the VM boundary sits, and how secrets reach runtime services.

Always-ready shellincluded baseline

Git, tmux, editors, Claude, Codex, logs, repo storage, workspace metadata, and signed-link state stay ready before service CPU starts.

Awake runtimeSmall / Medium / Large

Dev URL traffic, tests, workers, and agent jobs wake the selected runtime size; idle sleep stops CPU and memory billing without deleting the workspace.

Signed dev sessionsservice / workspace / org / expiration

A signed dev.envforge.ai link creates one browser session for the app surface and blocks SSH, secrets, logs, private consoles, and runtime admin.

Org-exclusive VM and root policyone organization per VM

Customer organizations never share shell or runtime VMs. Root is disabled, approved break-glass, or workspace elevation as an explicit organization policy.

SSM SecureString secrets/envforge/{org}/{workspace}/

SSM SecureString/KMS references are injected only into declared runtime inputs, while platform secrets remain in the control plane.

Rollout checks

A focused slice should answer the sales-engineering questions first.

This page keeps the pricing and security claims close together so docs, demos, and product review can reuse the same language without widening the promise into infrastructure detail.

  • Does the page show when cost starts and when it stops?
  • Does a signed dev link explain the allowed browser surface and the blocked operational surfaces?
  • Does the VM boundary state that cross-customer organizations never co-tenant?
  • Does root access read as a reviewed organization policy instead of a hidden host default?
  • Does secret copy name SSM SecureString/KMS without implying browser or shell access to raw values?