Security and trust

Every Runtime sandbox is its own Firecracker virtual machine, copies of your volumes and snapshots are encrypted with a key that belongs to your organization alone before they leave the server, and single sign-on, SCIM, two-step sign-in and a 400-day audit log are free on every account. This page is what a security review asks for, with the proof linked.

For anything this page does not answer, write to security@withruntime.com.

For your security review

Where your data lives

Everything runs in one region, in Virginia, United States (speed has the measurements).

The full list, with what each company does and where, is on the subprocessors page, and the data processing addendum is part of the terms for every account.

How your work is kept apart

• Each sandbox is its own virtual machine, with its own Linux kernel, disk and memory. CPU, memory, network rules and leases are enforced on the host, outside the guest.
• Sandboxes reach the public internet only. Private and internal addresses are refused, and any sandbox's network can be cut at once.
• Secrets your sandboxes use are never inside them. A sandbox sees a placeholder, and the host puts the real value in on the way out (secrets sandboxes never see).
• Customers are separated in the database by row-level security tied to the organization, and each part of the system connects with its own role holding only what that part needs.

Isolation and account boundaries has the detail.

Encryption

• In transit: every connection to Runtime, and from Runtime to its database, uses TLS, and the database's certificate is verified.
• Copies of your volumes and snapshots are encrypted with a key that belongs to your organization alone, before they leave the server. Deleting the organization destroys that key first, so those copies become unreadable at once (storage and backups).
• Each server's nightly backup is encrypted with that server's own key before it leaves the server. It is kept 30 days, and its pieces leave the storage within 44, so what a closed organization had on that server is gone from these backups by then.
• The nightly copy of our database is encrypted to a key held offline, so neither the storage provider nor the website can read it.
• Stored secrets are sealed, never returned by any API, and never written into a sandbox.

Sign-in and access

• Single sign-on over SAML or OIDC and directory sync over SCIM, free on every account (single sign-on).
• Two-step sign-in with a passkey or an authenticator app, which an owner can require of everyone in the account, and sign-in with a passkey alone (two-step sign-in).
• Four roles (owner, admin, developer, billing), read-only keys, compartments that wall a group of keys off from the rest of the account, and daily spending limits per key (keys).
• An audit log of every change to the account, who made it, from where and how, kept at least 400 days (teams and the audit log).

Availability and recovery

• The status page publishes the API's uptime, checked from outside every two minutes, and a real sandbox started from outside every ten (status).
• Paid accounts are promised 99% API uptime every month, with service credit paid automatically when a month falls short (uptime promise).
• The database can be rewound to any moment in the last 24 hours, and a sealed copy goes off-site every night and is kept 30 days, locked so it cannot be deleted early. A restore from that copy was last tested on 27 September 2026.
• Volumes are backed up off their server every day. A snapshot survives loss of its server once its off-server copy is checked, shown by backedUp: true (storage and backups). Every week one backed-up item is restored and checked against the checksum recorded when it was saved.

How Runtime is run

The service uses the following operational controls.

• Access. Production is reached only by the people and systems that operate it, and actions on customers' resources are recorded.
• Change. Changes are in version control and pass repository checks before they are pushed. The checks cover formatting, dependency advisories, linting, types, builds and tests for the affected packages. A production website release passes the full check; going live is a separate, deliberate step.
• Vulnerabilities. Dependencies are checked against published advisories. Reports go to security@withruntime.com, as security.txt says (report a vulnerability).
• Monitoring. Security events, such as an account locked after wrong two-step codes, every sign-in to the operator's dashboard and a backup that did not complete, are reviewed automatically every ten minutes, and the operator is alerted to anything unusual. The servers' sign-in logs and the log of every release signed are copied off the servers every day and kept a year, where the key that writes them cannot delete them.
• Incidents. A written procedure covers containing an incident, keeping the evidence, finding who is affected and telling them without undue delay, as the data processing addendum promises.
• Suppliers. Every company that handles customer data is on the subprocessors page before it starts, under a data processing agreement.
• Retention and deletion. What is kept, and for how long, is in the privacy policy.

Every company that handles your data

Each is listed on the subprocessors page before it starts handling customer data, under data protection terms no weaker than the data processing addendum.

Report a vulnerability

Write to security@withruntime.com before you test anything, and again with what you find. Testing Runtime's own servers, network or other accounts without agreeing it with us first breaks the acceptable use policy, and we may suspend the account.

A report helps most with the steps to reproduce it, the sandbox or request ids involved, and the time with its time zone. Please give us a reasonable time to fix a problem before you describe it in public. The same address is in /.well-known/security.txt.