Commercial offering

The Core Is Free. The API Above It Is the Product.

Sandlock itself is Apache-2.0 and complete: no paywalled flag, no enterprise-only feature, no runtime that phones home. What we sell sits on top of it: the Sandbox HTTP API, and the Sandbox Scheduler, which runs agent sandboxes at a fraction of the memory a reservation would hold.

The split

Three Layers, One Boundary

The line is drawn where it is useful rather than where it is lucrative: everything that confines a process is open, and everything that operates a fleet of them is not. The core is public and free at any scale; the two layers above it are closed source and licensed.

Sandlock

Apache-2.0

The sandbox itself: Landlock, seccomp-bpf, the supervisor, copy-on-write, the network and HTTP ACLs, credential injection, and the handler API. Every interface, from the CLI through Python, Rust, Go, the OCI runtime, and the MCP server, is in the open-source project.

Nothing on this site's documentation is gated. Apache-2.0, patent grant included, free at any scale. If you run Sandlock on your own machines and never talk to us, that is a supported outcome, not a trial.

Sandbox HTTP API

Commercial

An HTTP API over the core API, plus client SDKs. It turns a local library call into a remote one: create a sandbox from a container image, run commands in it, move files in and out, checkpoint it, and reconnect to it later from a different process or a different machine.

This is the layer where sandboxes stop being a function call and start being infrastructure with identity, lifetime, and access control.

Sandbox Scheduler

Commercial

Places sandboxes across a fleet. It treats a sandbox's home as a checkpoint store rather than a node, so a node lends memory for the duration of a call and takes it back afterwards.

For a workload that is idle over 99% of the time, that difference is the entire economics of running it.

HTTP API

What the Sandbox HTTP API Adds

The core confines one process on one machine. These are the things you need the moment there is more than one machine, more than one tenant, or more than one call.

Any language, over HTTP

The core is Rust with bindings. The API is a REST surface with an API key, so a caller needs no Landlock, no Linux, and no FFI.

Sandboxes that outlive the call

A sandbox has an id and persists across runs. Files written by one call are there for the next. Disconnect, then reconnect from another process entirely.

Checkpoint and restore

Save a named checkpoint, stop the sandbox, and bring it back later. The same mechanism the Sandbox Scheduler uses to move a sandbox between nodes.

Container images as the rootfs

Name an image and the server extracts it to a cached rootfs, sets up the chroot, and applies copy-on-write, with no image build in your loop.

Long-running service processes

Start a server inside a sandbox, query its status and ports, tail its output, and stop it, as a first-class lifecycle rather than a backgrounded command.

Remote MCP

Native MCP transports, so Claude Desktop, Cursor, or any MCP client points at the API directly. Register your own Python tools; each call runs in its own sandbox.

Scoped keys and usage

Keys carry fine-grained scopes covering create, exec, read, files, checkpoints, tools, and MCP, with per-key usage accounting behind them.

Pipelines across stages

The core's split-trust pipelines, available remotely: each stage keeps its own policy, and data flows between them without either stage gaining the other's access.

Sandbox Scheduler

Stop Paying for Sandboxes That Are Doing Nothing

An agent session spends almost all of its life waiting on the model. Reserve a node for it and you pay for that wait. The Sandbox Scheduler keeps the session in a checkpoint store and hands it node memory only while it is actually running.

1,000

Sessions

Two gigabytes each. Under reservation that is 2 TB of memory held continuously, whether or not anything is running.

42 GB

What it actually takes

Around ten are executing at any instant. Provision for a p99.9 of concurrent live sandboxes and the same thousand sessions fit in 42 GB.

~48×

More sessions per host

The ratio grows with fleet size, towards 91× at a hundred thousand sessions, because concurrency averages out.

Modelled from the duty cycle. Send us your session count, concurrency, and idle profile and we will size it against your workload.

How it works

The session lives in the store, not on a node. Nodes write an incremental checkpoint whenever the sandbox goes quiet, so the authoritative copy is never the one in someone's RAM.

A request restores it wherever there is room. Clients see latency, never an allocation step. Cold starts are sub-second because creating a sandbox is itself a restore, from a golden template.

Idle memory goes back. Residency is graded: a brief pause sinks the sandbox to local storage, a longer one returns it to the store.

What that changes operationally

Node failure is not an incident. Failover, eviction, and rebalancing are the same path: the next request restores the session somewhere else. It runs constantly rather than only when something breaks.

Overcommit is safe. A node with no headroom refuses and the router moves on, so you can pack hosts without a bad guess becoming an outage.

Forking a session is free. Restore one checkpoint any number of times under fresh ids, which is what best-of-N sampling and tree search need.

Routers are disposable. They hold no durable state, so run as many as you like behind a load balancer with no leader election or placement table to keep honest.

Two things do not move with a session. TCP connections drop on relocation and GPU state does not checkpoint cleanly, so plan long-lived connections and GPU work around that boundary.

Who this is for

Teams Running Sandboxes as a Fleet

If you run one sandbox at a time on one machine, the open-source project is the whole answer and you should stop here.

AI agent platforms

You run a sandbox per session, sessions outlive a request, and the memory bill is dominated by sandboxes that are doing nothing.

Code execution products

Notebook backends, interpreters, and evaluation harnesses that need an execution API with tenancy, quotas, and per-key accounting.

Developer platforms

Build and CI services where jobs come from outside your trust boundary and per-job VMs are the line item you are trying to remove.

Security engineering

You are approving untrusted execution on shared infrastructure and need a boundary you can describe precisely to an auditor.

Take It Beyond One Machine

The open-source core will carry you a long way on a single host. When sandboxes become a fleet, with many tenants, many machines, and a memory bill dominated by sessions that are doing nothing, the API and the scheduler are what turn that into infrastructure you can operate.

A technical call

Forty-five minutes with an engineer rather than a salesperson. Bring the workload.

Sized against your numbers

Sessions, concurrency, and idle profile, measured rather than modelled.

A pilot on your infrastructure

Running against real traffic before anything is signed.

Book a Technical Call contact@multikernel.io