Back to blog
Engineering
June 18, 2026

Why we built our code execution sandbox from scratch

AC

Amara Chukwu

Backend Engineer

7 min read

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.

typescript
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.

Enjoyed this?

More engineering notes land every couple of weeks.

Read more posts →