Isolation model

One sandbox per session

A session’s browser, shell and /workspace disk all live inside a single sandbox. That sandbox is the boundary.

gVisor today

Every session runs in its own gVisor sandbox. gVisor is an application kernel that implements the Linux system-call interface in user space, so processes in a session, including Chrome and anything you run in the shell, do not make system calls to the host kernel directly.

Never shared between customers

A session belongs to one customer. Sessions are never shared between customers: another customer’s code never runs in your session’s sandbox.

MicroVMs on the roadmap

We plan to add microVM isolation. When it ships, it will be announced in the changelog and described on this page.

Data handling

What we store, and why

We keep what is needed to run your sessions and bill for them.

  • Session data. Files in /workspace and browser state exist so the session can run. Download what you want to keep before you release a session.
  • Paused sessions. When you pause a session we save its state so it can be resumed. Saved state is free for 24 hours and billed after that; release the session to discard it.
  • Contexts. A context stores browser state (cookies and localStorage) so logins carry over between sessions. Only one running session can use a context at a time. Treat context IDs and your API key like credentials.
  • Account and usage data. We record usage (such as session time and resources) to bill you, and you can read it back through GET /v1/usage.
  • API keys and session URLs. Keys authenticate every request with the x-api-key header. A session’s connectUrl, liveUrl and terminalUrl carry signed tokens, so share them only with people and code that should control the session. Keep keys on your servers, never in browser code or public repositories.

Detailed retention periods will be set out in our privacy policy, which is currently a draft.

Compliance

Certifications

Responsible use

Acceptable use, in short

A summary of the rules. The full policy will be part of our terms.

You are responsible for what your sessions and agents do. Do not use Boxline to:

  • break the law, or help anyone else break it;
  • access accounts, systems or data you are not authorised to access, including credential stuffing or brute-forcing logins;
  • attack, probe or overload other people’s services, or interfere with our platform and other customers;
  • send spam, run fraud or phishing, or distribute malware;
  • collect personal data in ways that break privacy law or the terms of the sites you visit;
  • create, store or share content that exploits or harms children.

We may suspend sessions or accounts that break these rules, especially where there is a risk of harm to others.

Reporting

Report a vulnerability or abuse

If you believe you have found a security issue in Boxline, or see Boxline sessions being used for abuse, email security@example.com. Please give us a reasonable chance to fix a vulnerability before disclosing it, and do not access other customers’ data while testing.