Runtime's Sandbox Orchestration: How Multi-Provider Agent Execution Isolates Secrets, Snapshots State, and Routes Across E2B, Daytona, and K8s

Runtime (YC P26) addresses the operational gap between “coding agents work for engineers” and “non-engineers can safely use them.” The platform orchestrates Claude Code, Cursor, Codex, Copilot, Gemini, and Devin across multiple sandbox providers (E2B, Daytona, EC2, self-hosted K8s) while injecting secrets through a managed proxy and enforcing infrastructure-level guardrails. The founders built this after experiencing the pain of internal agent infrastructure at Mentum (acquired) and Modern Treasury.

The core is open source at github.com/runtm-ai/runtm. The hosted version charges a flat platform fee plus compute with no token markup.

The Orchestration Problem

When you let a PM or support engineer use a coding agent, you face three failure modes:

Secrets leak into agent context or logs. The agent sees your database password, includes it in a commit message, or logs it during a tool call.
Setup friction kills adoption. Every repo needs local dependencies, environment variables, and running services. Engineers end up doing one-off setup for each non-engineer.
Unmergeable output. The agent produces code that works in isolation but breaks integration tests, violates style guides, or ignores company-specific patterns.

Runtime solves this by separating the orchestration layer from the agent. Engineering defines the context once (system instructions, skills, integrations), Runtime snapshots the full environment, and then anyone can trigger a session without touching credentials or needing local setup.

Secret Injection Proxy Architecture

Runtime’s secret proxy sits between the agent and external services. When an agent makes a tool call that requires credentials (Stripe API, database connection, Snowflake query), the proxy injects the secret at request time without exposing it to the agent’s context window or logs.

How it works:

Secrets are stored in Runtime’s managed vault, scoped per team and per agent.
The agent receives a placeholder token (e.g., STRIPE_API_KEY_PROXY) in its environment.
When the agent calls curl -H "Authorization: Bearer $STRIPE_API_KEY_PROXY", the proxy intercepts the request, swaps the placeholder for the real key, and forwards it.
The agent never sees the actual secret. Logs show only the placeholder.

This is similar to how Kubernetes secrets work with init containers, but Runtime extends it to arbitrary tool calls and API clients. The proxy layer also enforces network egress controls, so an agent can only reach approved endpoints.

Millisecond Environment Snapshots

Runtime claims “millisecond environment snapshots” for multi-service Docker Compose setups, Kafka, Redis, and seeded databases. This is not container checkpointing (which would require CRIU and kernel support). Instead, Runtime uses layered filesystems and pre-warmed pools.

Likely implementation:

Layered filesystem (OverlayFS or similar): The base environment (OS, language runtimes, installed packages) is a read-only layer. Each session gets a writable overlay. When the session ends, the overlay is discarded or snapshotted.
Pre-warmed pools: Runtime keeps a pool of containers with services already running. When a session starts, it clones a warm container instead of booting from scratch.
Service state snapshots: For databases and message queues, Runtime likely uses volume snapshots (ZFS, Btrfs, or cloud provider snapshots) to restore seeded data instantly.

This approach trades memory (keeping warm containers) for latency. It works well for environments under 10 GB but gets expensive for larger monorepos or data-heavy services.

Multi-Provider Routing Logic

Runtime orchestrates across E2B, Daytona, EC2, and self-hosted K8s. The routing decision depends on:

Compute requirements: CPU-heavy tasks (compilation, test suites) go to EC2 or K8s. Lightweight tasks (script execution, API calls) go to E2B or Daytona.
Latency sensitivity: If the agent needs sub-second feedback (interactive debugging), Runtime prefers providers with pre-warmed pools.
Cost constraints: E2B and Daytona charge per-minute. EC2 and K8s give you more control over spot instances and reserved capacity.
Compliance requirements: Self-hosted K8s for customers who can’t send code or data to third-party sandboxes.

Runtime likely uses a simple decision tree or cost model to pick a provider. The open-source core probably exposes this as a pluggable strategy so teams can customize it.

Infrastructure-Level Guardrails

Runtime enforces guardrails at the infrastructure level, not the agent level. This means the agent can request any tool call, but the sandbox blocks it if it violates policy.

Guardrail types:

Command allow/deny lists: The agent can run npm install but not rm -rf /.
Network egress controls: The agent can reach api.stripe.com but not evil.com.
RBAC per human and per agent: A support agent can read logs but not deploy. A finance agent can query Snowflake but not write to production databases.

These guardrails run in the sandbox’s init process or as a sidecar container. When the agent executes a command, the init process checks it against the policy before passing it to the shell. If the command is denied, the agent sees a permission error and can adjust its approach.

This is more robust than prompt-based guardrails (which agents can bypass) but less flexible than runtime monitoring (which catches violations after they happen).

Shareable Preview URLs for Ephemeral Sandboxes

Every Runtime session gets a shareable preview URL. This is tricky because the sandbox is ephemeral and doesn’t have a stable IP or DNS name.

Likely implementation:

Reverse proxy with session routing: Runtime runs a reverse proxy (Envoy, Traefik, or Caddy) that maps session-abc123.preview.runtm.com to the sandbox’s internal IP. When the session ends, the proxy removes the route.
Persistent routing layer: The proxy keeps the route alive for a configurable TTL (e.g., 24 hours) even after the sandbox shuts down. If someone visits the URL after the sandbox is gone, Runtime can optionally restart it from the snapshot.
WebSocket tunneling: For interactive sessions (live collaboration, real-time updates), Runtime uses WebSockets to tunnel traffic from the preview URL to the sandbox.

This is similar to how Vercel and Netlify handle preview deployments, but Runtime has to handle stateful services (databases, message queues) in addition to static assets.

Trade-offs and Failure Modes

Component	Trade-off	Failure Mode
Secret proxy	Adds latency to every API call	Proxy outage blocks all agent tool calls
Pre-warmed pools	High memory cost for idle containers	Pool exhaustion causes cold starts
Multi-provider routing	Complexity in cost modeling and failover	Misconfigured routing sends expensive tasks to wrong provider
Infrastructure guardrails	Rigid policies can block legitimate agent actions	Overly permissive policies allow dangerous commands
Shareable preview URLs	Persistent routing increases attack surface	Leaked preview URL exposes internal services

Example: PagerDuty + Sentry + Repo Agent

One Runtime customer built an on-call inspector that wires PagerDuty, Sentry, and their repo. When an alert fires:

PagerDuty webhook triggers a Runtime session.
The agent queries Sentry for the stack trace and error context.
The agent clones the repo, checks out the relevant branch, and runs the test suite.
The agent writes a unit test that reproduces the bug.
The agent opens a PR with the test and a proposed fix.
The PR is ready before the on-call engineer gets paged.

This workflow requires:

Secret injection for PagerDuty, Sentry, and GitHub API keys.
Pre-warmed environment with the repo, dependencies, and test runner already installed.
Guardrails to prevent the agent from deploying the fix directly (only open a PR).
Shareable preview URL so the on-call engineer can review the PR in the Runtime UI.

Code Snippet: Defining a Runtime Environment

# runtime.yml
name: monorepo-agent
providers:
  - e2b
  - k8s-prod
compute:
  cpu: 4
  memory: 8GB
  timeout: 30m
install:
  - mise install
  - npm install
  - docker-compose up -d
secrets:
  - STRIPE_API_KEY
  - DATABASE_URL
  - SENTRY_DSN
guardrails:
  commands:
    allow:
      - npm
      - git
      - docker
      - pytest
    deny:
      - rm
      - sudo
  network:
    allow:
      - api.stripe.com
      - sentry.io
      - github.com
    deny:
      - "*"
rbac:
  engineering:
    - read
    - write
    - deploy
  support:
    - read

This config defines an environment that installs dependencies with mise and npm, boots services with Docker Compose, injects three secrets, and enforces command and network guardrails. Engineering can deploy, but support can only read.

Technical Verdict

Use Runtime if:

You want non-engineers to use coding agents without engineering handholding every session.
You need to enforce secrets isolation and guardrails at the infrastructure level.
You have multiple repos or microservices and want a single orchestration layer.
You’re already using E2B, Daytona, or self-hosted K8s and want to unify them.

Avoid Runtime if:

You only have one engineer using agents and don’t need multi-user orchestration.
Your agents need to run in air-gapped environments with no external orchestration layer.
You want full control over the sandbox implementation and don’t want to depend on Runtime’s routing logic.
Your environments are too large (50+ GB) for pre-warmed pools to be cost-effective.

Runtime is best for teams that have already validated coding agents and need to scale them across the organization. If you’re still experimenting with agents, start with a simpler setup (local Docker Compose, manual secret injection) and migrate to Runtime when the operational burden becomes painful.

Source Links

Primary: Runtime
Open Source: github.com/runtm-ai/runtm
Discussion: Launch HN: Runtime (YC P26)