Hey everyone 👋 I built sandbin because every time I needed to run untrusted code — a user-submitted script, an LLM's output, a coding-challenge submission — the "correct" answer was always "just spin up a Docker container." That's a daemon, root or rootless plumbing, an image pull, and real seconds of cold start for something that should be near-instant. sandbin skips Docker entirely. It's bubblewrap for namespace isolation, seccomp-bpf for a strict syscall allowlist (146 explicitly permitted, everything else returns EPERM — not a blocklist of "known bad" calls), and cgroup v2 for hard memory/CPU/PID ceilings. Cold start is ~20ms — 17.6× faster than Docker by median, measured with the methodology written up in the docs, not just claimed. A submission gets its own PID namespace, its own empty network stack, its own filesystem view, and hard resource ceilings. When it misbehaves — fork bombs, memory bombs, ptrace, raw sockets, nested user namespaces — the test suite proves it dies and the host never notices. 111 adversarial test cases, all against real spawned sandboxes, no mocking: cgroup counters read directly from the kernel, not the guest's own claims about what happened. Three ways to use it: CLI: sandbin run script.py, local or against a remote server with --server HTTP + WebSocket API: submit code, stream stdout/stderr live Browser playground: try it right now at the link below, no install Runs Python, Bash, Node, C, and Go today. It's a side project, MIT licensed, single maintainer — I'd genuinely love feedback, especially from anyone who's fought with Docker-per-request architectures before. And if you find a way to break the sandbox, that's the best kind of comment I could get. 🙂 GitHub: https://github.com/ayazdoruck/sa... Live visual playground: https://sandbin.vercel.app

sandbin

Run untrusted code and survive it — no Docker, no root

Run untrusted code and survive it — no Docker, no root