judge0

Executes untrusted code in isolated sandbox environments using the Isolate sandbox system with configurable resource constraints (CPU time, memory, disk I/O, wall clock time). Each submission runs in a separate process-isolated container, preventing code from accessing host system resources or other submissions. The system applies per-language compiler options and runtime arguments while capturing detailed execution telemetry including stdout, stderr, compilation output, exit codes, and resource consumption metrics.

Supports 60+ programming languages by maintaining a registry of language-specific compilers, interpreters, and runtime configurations. The system maps language identifiers to appropriate build and execution commands, applies language-specific compiler flags (e.g., -O2 for C++, --release for Rust), and handles both compiled and interpreted languages transparently. Language support is extensible through configuration without code changes, allowing operators to add new languages by defining compiler paths and execution templates.

Provides health check endpoints that report API server status, worker availability, Redis connectivity, database connectivity, and queue depth. The system exposes metrics including submission throughput, average execution time, worker utilization, and queue latency. Health checks can be used by load balancers to route traffic away from unhealthy instances. Diagnostic endpoints provide detailed information about system state for debugging and capacity planning.

Allows operators to configure per-language and global resource limits including CPU time (seconds), wall clock time (seconds), memory (megabytes), disk space (megabytes), and process count. Limits are enforced by the Isolate sandbox using cgroups and system calls. The system supports different limit profiles for different languages (e.g., Java gets higher memory limit than C++). Clients can optionally override limits within operator-defined bounds. Limit violations trigger appropriate status codes (Time Limit Exceeded, Memory Limit Exceeded).

Caches execution results in Redis with configurable time-to-live (TTL), typically 24 hours. Clients can retrieve cached results without re-executing code if the same submission is requested multiple times. The cache key is derived from source code hash, language, and compiler flags, enabling deduplication of identical submissions. Expired results are automatically purged from Redis. Clients can optionally bypass cache and force re-execution.

Provides Docker container images for easy deployment of Judge0 API server and worker processes. The Dockerfile includes all dependencies (Ruby, PostgreSQL client, Redis client, language compilers) and is optimized for production use. Deployment is simplified to docker-compose or Kubernetes manifests. The system supports environment variable configuration for database, Redis, and resource limits, enabling deployment without code changes. Docker images are published to Docker Hub for easy access.

Provides dual execution modes: synchronous mode (wait=true) where the client blocks until execution completes and receives results immediately, and asynchronous mode (wait=false) where the client receives a submission token and polls for results or receives webhook callbacks. The system uses Redis-backed job queues and background worker processes to decouple submission acceptance from execution, enabling horizontal scaling. Asynchronous mode supports webhook callbacks to notify clients when execution completes, eliminating polling overhead.

Accepts multi-file program submissions where clients can submit multiple source files that are compiled and executed together as a single unit. The system extracts files to an isolated submission directory, applies language-specific build commands (e.g., make, gradle, cargo), and executes the resulting binary. This enables support for projects with headers, modules, and dependencies while maintaining sandbox isolation. The API accepts files as base64-encoded strings or raw binary data in JSON/multipart payloads.

Captures comprehensive execution telemetry including stdout/stderr streams, compilation output, exit codes, signal information, execution time (milliseconds), memory usage (kilobytes), CPU time, and wall clock time. Results are structured as JSON with language-specific status codes (e.g., 'Accepted', 'Wrong Answer', 'Time Limit Exceeded', 'Runtime Error'). The system stores results in PostgreSQL and caches them in Redis for fast retrieval. Clients can retrieve full results immediately or via polling with optional filtering.

Implements a Redis-backed job queue that decouples submission acceptance from execution, enabling horizontal scaling of worker processes. The API server enqueues submissions as jobs; background worker processes dequeue and execute them in parallel. Workers are stateless and can be added/removed dynamically without affecting the API. The system supports configurable worker concurrency, job timeout, and retry logic. Multiple worker instances can run on different machines, processing jobs from a shared Redis queue.

Allows clients to specify custom compiler flags (e.g., -O2, -Wall, -std=c++17) and runtime arguments that are passed to the language's compiler or interpreter. The system validates flags against a whitelist to prevent injection attacks, then applies them during compilation and execution. This enables clients to control optimization levels, enable warnings, specify language standards, and pass command-line arguments to the executed program.

Provides webhook callbacks for asynchronous submissions, allowing clients to specify a callback URL that Judge0 will POST to when execution completes. The webhook payload includes the submission token, status, and execution results. The system supports custom headers for authentication (e.g., Bearer tokens) and retries failed webhook deliveries with exponential backoff. This eliminates the need for clients to poll for results.

Maps execution outcomes to standardized status codes (Accepted, Wrong Answer, Time Limit Exceeded, Memory Limit Exceeded, Runtime Error, Compilation Error, etc.) that are language-agnostic and consistent across all 60+ supported languages. The system analyzes exit codes, signal information, and execution metrics to determine the appropriate status. This enables clients to provide consistent feedback regardless of the language used.

Implements API authentication through API keys or JWT tokens that clients must include in request headers. The system validates credentials against a user/token database in PostgreSQL and enforces rate limiting per authenticated user. Authorization is role-based, allowing operators to restrict certain languages, resource limits, or features to specific users or tiers. The API supports both stateless JWT validation and stateful session-based authentication.