Deploy and Host a Code Execution Sandbox on Railway

An HTTP endpoint that runs JavaScript, TypeScript and Python with the network off, the filesystem closed, and a wall-clock limit — built for the code an AI agent just produced, which has to run somewhere that is not your application process.

Send code, get back stdout, stderr, exit code and duration. Nothing else crosses the boundary.

About Hosting a Code Execution Sandbox

Agents write code, and something has to execute it. Doing that inside your own service means one infinite loop takes the whole thing down, and one careless fetch sends your environment variables to an address the model invented.

The option already in the catalogue is Judge0: 216 installs, 48% of deployments coming up. That rate is not a packaging mistake — Judge0 isolates through isolate, which needs cgroup privileges a managed platform does not grant. It cannot work in this environment, and it keeps being deployed anyway.

This template uses a boundary that does exist inside an ordinary container. The submitted code runs in a child process started with every permission denied, and Deno's runtime enforces that: no network, no subprocesses, no environment access, no writes, and reads limited to the single file being run. Python is CPython compiled to WebAssembly, so it has no system interpreter to fall back on — urllib is refused exactly the way fetch is.

Where the boundary is. This is process-level isolation, not a virtual machine. It is the right tool for code your own model generated — careless rather than hostile: runaway loops, accidental allocations, unintended network calls. It is not the right tool for running code submitted by strangers, which needs a kernel boundary (Firecracker, gVisor, Kata) and therefore host access no managed container has. Stated plainly here rather than discovered later.

Common Use Cases

• A tool your agent can call. Give a model a run_code tool that reaches this endpoint instead of your production runtime.
• Data work on demand. Let a chat interface compute something in Python — sums, parsing, transformations — without shipping a notebook.
• Evaluating generated code. Run what a model wrote against test input and read the exit code, in a place where a bad answer costs nothing.

Dependencies for Sandbox Hosting

Deployment Dependencies

• Deno 2.9.3 — the runtime whose permission model is the sandbox
• Pyodide 0.29.4 — CPython 3.13 compiled to WebAssembly
• One service, no database, no volume
• Template source

Implementation Details

• Permissions are denied explicitly, not merely unrequested. The child starts with --deny-net --deny-run --deny-ffi --deny-sys --deny-write --deny-env and a read allowance scoped to one file.
• The service refuses to start without a token. An unauthenticated code-execution endpoint on a public domain is not a lesser version of this product; it is a different and much worse one.
• Timeouts end in SIGKILL. Code that ignores a signal is precisely the code a timeout exists for.
• Concurrency is capped, and past the cap the answer is an immediate 503. Without that, a burst turns one container into processes competing for the same CPU and everything times out together.
• Output is truncated, not buffered without bound, so a program printing in a loop cannot exhaust memory in the parent.
• Each run gets a new process and a new directory, both destroyed afterwards. The verification script checks this by setting a global in one run and reading it back in the next.
• The Python runtime is baked in at build time — roughly 100 MB of WebAssembly. Fetching it on first use would make that request look broken, and would need network access the child does not have.
• The token comparison is constant-time, so a wrong token cannot be discovered one character at a time.

The repository carries scripts/verify-sandbox.sh: twelve checks, most of which are things that must fail — a run without a token, a network call from JavaScript and from Python, a read of /etc/passwd, a spawned process, an endless loop — plus a confirmation that the service is still healthy afterwards and that no state survives between runs. This template was published only after that script passed against a deployment created from the template itself.

Why Deploy a Code Execution Sandbox on Railway?

Railway is a singular platform to deploy your infrastructure stack. Railway will host your infrastructure so you don't have to deal with configuration, while allowing you to vertically and horizontally scale it.

By deploying a code execution sandbox on Railway, you are one step closer to supporting a complete full-stack application with minimal burden. Host your servers, databases, AI agents, and more on Railway.