DocumentationAccount

Security

Its own computer.
Your boundaries.

Understand what is isolated, what is allowed, and what you control.

Isolated machines

Firecracker microVMs keep guest work separate.

Isolation evidence

Agent access

One credential per agent. Revoke access when needed.

Access and revocation

Controlled network

Public-web egress. Private destinations refused.

Network boundaries

Runtime uses Firecracker microVMs on Runtime-operated dedicated servers. Each sandbox has its own guest environment. Host credentials, control sockets and provider credentials are not customer tools.

Private hardware tests have exercised guest separation, selected private-address refusals, restart recovery and host-side lease expiry. This is limited evidence, not a claim of complete isolation assurance or a completed outside security audit.

Keys and secrets

Keep keys in server-side secret storage. Use separate credentials for separate agents or applications. Current owner-issued keys cover every Cloud product, including products enabled later, and last until revoked. Never put a key in a public prompt, URL, browser bundle, repository, command-line argument or diagnostic log. A framework adapter does not expand what the key is allowed to do.

Give a command its secrets through env, never in the command line. Runtime never echoes env values back, and its journals and request records keep only a hash of them. A command line is recorded as you sent it.

Read-only keys and daily limits

Both are optional. Without them a key reaches every product and is bounded by your prepaid balance, and nothing else.

  • Read-only key. Choose Read only when you create a key at API keys. It sees the whole account: every sandbox and its state, spec and cost, the images, volumes, snapshots, previews and network rules beside them, account notices, the balance, and its own access and limit. That covers products added later too. It cannot create, start, stop, pause, wake, run a command, write a file, change anything or spend anything. It does not see inside sandboxes (files, command output), job runs or secrets. Use it for monitoring, dashboards and CI checks.
  • Daily spending limit. Set one on any key that can spend, when you create it or later from its row. It is the most that key's agent may commit in any 24 hours: settled charges plus money still on hold. It counts everything the agent's sandboxes cost, including renewals and parked storage. When a create, wake, extension or renewal would pass it, that request fails with spending_limit_reached (HTTP 402) and nothing is charged. A running sandbox keeps its current lease; one that needs a renewal past the limit stops or pauses when its lease ends. Room comes back as older spending leaves the 24-hour window.

Only an account owner can create a read-only key or set, change or remove a limit, and only on the website. A key can read its own access and limit with GET /v1/limits, runtime limits or the runtime_limits_get tool. No key can raise, remove or set a limit, and no key can create another key.

Set a limit above what the agent's paused sandboxes cost in a day. If storage for a paused sandbox cannot be paid for, it is treated like storage on an empty balance: you are notified, and after seven days unpaid it is deleted.

Network access

The sandbox network contract is controlled public-web egress. Outbound traffic leaves through an HTTP CONNECT proxy, and the guest must keep the proxy environment it is given; a tool that ignores it does not reach the internet. By default, outbound traffic is the public web. Only the public web ports 443 and 80 are allowed. A paid account can open named host:port pairs with connect; a few ports are never reachable. Private and internal addresses are refused. Each sandbox's rules can narrow this further, and they bind root inside the sandbox too. See the sandbox environment.

Nothing connects in to a sandbox except through a preview you create: an HTTPS address for one port, private with an expiring token unless you make it public. Preview addresses are under runtimehost.com, never under withruntime.com, so content a sandbox serves never shares an origin with your account. A sandbox with no preview accepts no incoming connections. Per-sandbox limits on concurrent connections, bandwidth and bytes per day also apply; their values are host configuration and are not published here. A request to create a sandbox does not promise arbitrary outbound TCP or an unrestricted network interface. Check a migration's package managers and destination requirements explicitly.

Root inside the sandbox

The sandbox user has passwordless sudo. Root inside the guest controls the guest and nothing else: CPU, memory, disk, network rules, leases and billing are enforced on the host.

Lifetimes and storage

A host-side lease bounds execution even if management is unavailable. A stopped sandbox is not a separately promised backup. Export important results and do not assume a single-host sandbox has replicated customer storage. Persistent product guarantees require their own release and recovery tests.

Browser-approved agent connections

Run the CLI login to connect without copying a key. The browser uses your existing session when possible. Check the request code and agent name, then approve Connect agent. Only an account owner can approve a new connection. The request expires after 15 minutes. Do not approve unsolicited connection links.

Approval creates a distinct agent identity and credential. It does not give the agent your browser session. The credential is encrypted for the initiating CLI when delivered and saved outside the project. On Unix, the credential directory is private to its user and the file has owner-only permissions. This is file storage, not an OS keychain or encrypted-at-rest secret vault; software running as your user may be able to read it. Keep the machine and its backups secure.

Each connection can operate across the account and spend its prepaid balance. Separate agent identities make attribution and revocation possible; they do not make an untrusted agent safe to connect. No mandatory per-agent spending ceiling is imposed by the default connection flow. To bound one, set a daily limit on its row at API keys after it connects.

The browser reports success after the CLI receives and verifies the credential. Signing out of the browser leaves agent connections active. Revoke an individual credential from API keys, or run npx withruntime logout on its machine (installed: runtime logout). Revocation does not itself stop running resources: inspect them and stop any work you no longer want. Billing follows confirmed resource state, not sign-in state.

Before production use

Public signup is open to anyone at https://withruntime.com/sign-in. Validate your actual package registries, workload, cleanup and recovery before adoption. Runtime does not currently claim arbitrary network access, replicated sandbox storage, a completed external security audit or universal protection against malicious code. See the evaluation guide for concrete checks.

Was this page right?