Why we built our code execution sandbox from scratch
Amara Chukwu
Backend Engineer
When a learner clicks "Check Solution," their code has to run somewhere. That somewhere cannot be our API server — untrusted code with network access, unbounded memory, and no time limit is an outage waiting to happen.
The constraints
We needed sub-5-second execution, network isolation, a hard memory ceiling, and support for four languages out of the gate: JavaScript, TypeScript, Python, and SQL.
export async function executeCode(
code: string,
language: string,
stdin = '',
): Promise<ExecutionResult> {
const languageId = LANGUAGE_IDS[language]
if (languageId === undefined) {
throw AppError.badRequest(`Unsupported language: ${language}`)
}
// ... sandboxed execution via isolated container
}Every submission runs in a freshly-provisioned container with networking disabled, a 128MB memory cap, and a 5-second CPU budget. If a learner writes an infinite loop, the sandbox kills it — their browser tab never even slows down.
The sandbox should be invisible when it works and obvious when it protects you.
What this unlocked
Real test execution, not string-matching a regex against expected output. Learners get actual pass/fail per assertion, with the same test runner output they'd see locally.