Limits & Sandboxing
Every submission runs in its own throwaway Docker container, destroyed right after the run. What happens in a run can't see other students' code, the database, or the network.
The sandbox
| Restriction | Value |
|---|---|
| Network | None (network_mode: none) — no internet, no internal services |
| Memory | 100 MB (Python) / 512 MB (C# — the compiler needs room) |
| CPU | ~5% of one core |
| Processes | 128 max |
| Filesystem | Read-only for Python; C# may write to the working dir (compiler output) |
| Lifetime | One run — the container and its files are deleted afterwards |
No wall-clock timeout yet
An infinite loop currently blocks until the container is cleaned up manually — a hard per-run time limit is on the roadmap. The CPU throttle limits the damage, but don't rely on it.
What a run can use
Python runs on python:3.13-slim — standard library only, no pip. C# compiles with Roslyn on the .NET 8 SDK image — base class library only, no NuGet.
What counts as a pass
A case passes when the function's return value equals the expected value — full semantics (per language, with the gotchas) are in How results are compared. In short:
- Printing to stdout never affects grading
- An exception fails that case and shows its message to the student
- A submission that fails to load (syntax error, wrong function name) fails the whole run
- The overall score is the pass ratio across cases; teachers customise correctness per problem with a custom resolver
Recorded per run
Each submission stores the code, per-case results (runtime, output, expected, stdout, stderr), and the timestamp — that's what powers the student's history dialog and the teacher's review views.