sandbin
Runs untrusted code and survives it. No Docker, no root, no VM.
A submission gets its own PID namespace, its own network stack (empty), its own filesystem view, a syscall allowlist, and hard ceilings on memory, CPU and process count. When it misbehaves — and the test suite makes sure it does — it dies, and the host doesn't notice.
Try it
How it's contained
Four independent layers, so no single bug is an escape:
Namespaces
No network, no host filesystem, no host processes, private tmpfs root.
Seccomp
146-syscall allowlist — everything not explicitly needed is denied.
cgroup v2
memory.max, cpu.max, pids.max, cgroup.kill teardown.
rlimits
File size, open descriptors, no core dumps.
Why not Docker
Docker needs a daemon, root or rootless plumbing, and image pulls, and costs hundreds of milliseconds per container. Everything sandbin needs is already in the kernel: namespaces, cgroup v2, seccomp and rlimits. Skipping the container runtime is what buys the 20 ms start and lets the same code run somewhere as small as a phone.
Measured on the same machine, back to back, not estimated:
17.6× faster, median of 20 runs each. Full methodology and raw samples →
Read more
Architecture →
The cgroup delegation walk, the seccomp policy's clone-flag trick, the hard-timeout backstop.
API →
HTTP endpoint to submit a run, WebSocket protocol to watch it stream.
CLI →
Run code from a terminal, locally with no server or against a remote one.
Languages →
Python, Bash, Node.js, C and Go. How a compiled language gets sandboxed twice.
Benchmarks →
17.6× faster than Docker, measured, plus real concurrency and throughput numbers under load.
Security →
The threat model, stated plainly, and the real bugs found building this.
Testing →
Every case asserts on evidence the guest can't fake, not its own claims.
Run it yourself
git clone https://github.com/ayazdoruck/sandbin.git
cd sandbin
npm install
npm startOpens the same black-and-white playground at localhost:8080 — pick a language, write your own code, run it live.