info.bogdan.ws
A competitive-programming judge that compiles and runs untrusted C++ on my own server. Getting that to be safe took kernel namespaces, cgroup limits, and a seccomp filter on top.

Overview
info.bogdan.ws is a judge for competitive programmers. You browse problems by difficulty, write C++ in an in-browser Monaco editor, and either run it against custom input or submit it against hidden test cases for per-test verdicts (AC, WA, TLE, MLE, RE, CE) with runtime and memory for each.
There's an admin side for authoring problems and test cases, a personal dashboard with progress and activity, and a time-travel debugger UI that plays execution forward and backward with per-line variable state.
The problem
Everything here comes down to one question: how do you run arbitrary, potentially hostile C++ on your own hardware without letting it read the filesystem, open sockets, fork-bomb, or exhaust the machine? Most of the interesting work in this project went into answering that.
Approach & architecture
The stack is a Go/Fiber backend over PostgreSQL and Redis, a React 19 SPA, and a separate Go executor service. Everything runs in Docker except the executor, which runs natively under systemd — isolate needs full cgroup v2 delegation, and Docker's own cgroup namespace gets in the way. The backend talks to it over host.docker.internal.
Isolation is layered. Isolate (the IOI sandbox) gives each run its own PID, network, and mount namespaces, cgroup limits on CPU, memory, and process count, and a read-only filesystem. On top of that I wrote a custom seccomp-BPF filter, built in Go and applied by a small C launcher before exec, that blocks fork, socket, ptrace, and similar syscalls. Compiler flags are whitelisted, and every test case gets a fresh sandbox so nothing leaks between tests.
Challenges & tradeoffs
The longest fight was getting isolate and Docker to coexist, and the eventual answer was to stop trying: run the executor on bare metal under systemd and let Docker be the boundary for everything else. The cost is a deployment split across two process managers and two log streams, which I accepted because the isolation actually works this way.
For auth I use stateless access tokens plus database-backed refresh tokens in a jti.secret format: the jti is an indexed O(1) lookup, and the secret half is bcrypt-hashed, so even a leaked database can't be used to mint sessions. One small thing I'm fond of: ANSI colors survive the whole pipe from clang to the browser, so compiler errors look like they do in a real terminal.