# Runtime Lab

> Learn Backend & Systems Engineering by building the real thing: your own Redis, Git, HTTP server and HTTP parser, plus language paths in Go, Python and C — stage by stage, verified by real test suites you run from the browser.

Runtime Lab teaches backend and systems engineering by having you rebuild the
software you already depend on — a PostgreSQL wire-protocol driver, a packet
decoder, an HTTP parser, a write-ahead log, a distributed job queue, a memory
allocator, kernel components in userspace, and the familiar ones too: Redis,
Git, a shell, a small language interpreter — from an empty file, one stage at
a time.

## How it works

- Every challenge is a private git repository we host for you, seeded with
  starter code. There is nothing to install.
- You write the code in the browser or clone the repo and use your own editor.
  A save in the browser is a commit.
- Pressing Run compiles your latest commit and runs that stage's real test
  suite against it, in a sandboxed container with no network access, on our
  hardware. The container is discarded afterwards.
- A stage adds one capability and one test. Passing is the gate to the next.
- Help is layered: hints one at a time, a guided prompt path, a reference
  solution once you have earned it, and a discussion for that exact stage.

## What it costs

One prepaid access pass, never auto-renewing, in two durations. A free account
can read and run the opening stages of every challenge. Current prices are on
the pricing page — do not quote figures from memory.

- [Pricing](https://runtimelab.io/pricing)
- [How it works](https://runtimelab.io/how-it-works)

## Challenges

Every challenge below has a public page of its own with what you build, how long
it runs, the language and the level. The stage list is not on it — see the
note at the end.

- [Full catalogue, with filters](https://runtimelab.io/catalog)
- [Career paths and ordering](https://runtimelab.io/roadmap)
- [What is shipping next](https://runtimelab.io/timeline)

### Programming Foundations
- [Programming Foundations (Python)](https://runtimelab.io/challenges/foundations-py) — 15 stages, python: New to Python? Build one real command-line tool — a grade book that grades a class roster — in fifteen small steps, each centered on a Python mistake that actually bites.
- [Programming Foundations (Go)](https://runtimelab.io/challenges/foundations-go) — 14 stages, go: New to Go? Build one real command-line tool — a grade book that grades a class roster — in fourteen small steps, each centered on a Go mistake that actually bites.
- [Programming Foundations (C)](https://runtimelab.io/challenges/foundations-c) — 16 stages, c: New to C? Build one real command-line tool — a grade book that grades a class roster — in sixteen small steps, each centered on a C mistake. Tested under AddressSanitizer.
- [Learn Go by writing it](https://runtimelab.io/challenges/learn-go) — 15 stages, go: Write a concurrent service health checker one piece at a time — bounded, with timeouts and a pluggable report. Fifteen exercises, each built around a bug that actually bites.
- [Learn Python by writing it](https://runtimelab.io/challenges/learn-python) — 14 stages, python: Build a concurrent service health checker with nothing but the standard library. Fourteen exercises, each a working part of the tool, each built around a mistake that bites.
- [Learn C by writing it](https://runtimelab.io/challenges/learn-c) — 14 stages, c: Build a word-frequency tool in C, one function at a time — ending in a hash table with collisions, rehashing and deletion. Fourteen exercises, each a place C lets you be wrong; every test runs under AddressSanitizer.

### AI Foundations
- [Build your own BPE Tokenizer](https://runtimelab.io/challenges/bpe-tokenizer) — 14 stages, python/go: Build a byte-pair-encoding tokenizer from scratch — training, encoding, decoding, special tokens, and the byte-level edge cases nobody warns you about. The GPT-2/GPT-4 tokenizer, cross-checked against tiktoken.
- [Build your own Text Generator](https://runtimelab.io/challenges/text-generator) — 15 stages, python: Build a text generator from counting alone — bigrams, sampling, temperature, top-k and top-p, then n-grams, smoothing, a repetition penalty and beam search. Every decoding knob in a modern LLM, with no neural network underneath.

### Backend Engineering
- [Build your own HTTP server](https://runtimelab.io/challenges/http-server) — 14 stages, go/c/cpp: Build an HTTP server from scratch, one feature at a time — bind a TCP socket, parse requests, serve responses, and handle headers and compression. In Go, C, or C++.
- [Build your own Redis](https://runtimelab.io/challenges/redis) — 115 stages, go/c/cpp: Build your own Redis — a server speaking real RESP over TCP, from PING to replication: commands, expiry, persistence, transactions, and streams. In Go, C, or C++.
- [Build your own curl](https://runtimelab.io/challenges/request-journey) — 16 stages, go: The request journey, built rather than narrated: open the socket, write the bytes, and add each piece a real request passes through — headers, body framing, redirects, connection reuse, timeouts, gzip, cookies, TLS, caching, ranges and proxies. Nothing imports net/http.
- [The Ring Buffer (Go)](https://runtimelab.io/challenges/ringbuffer-go) — 4 stages, go: One array, allocated once, that bytes go into and come out of forever. Four exercises: the wraparound arithmetic, safety under a concurrent reader and writer, waiting on a condition variable instead of spinning, and then the property the whole thing exists for — zero allocations per operation, error paths included.
- [TCP Reverse Proxy (Go)](https://runtimelab.io/challenges/tcpproxy-go) — 8 stages, go: A layer-4 reverse proxy, built on the ring buffer you wrote. Forwarding both directions of a stream, buffers borrowed from a pool rather than allocated per connection, TCP health probes and round-robin over what answers, a per-IP token bucket, a drain with a deadline, an upstream connection pool, and a final stage that attacks the whole thing under latency while the allocation count stays at zero.
- [Chunk a file (Go)](https://runtimelab.io/challenges/filechunker-go) — 4 stages, go: Every cloud uploader cuts a file into pieces before it sends any of it, and every one of those pieces carries a checksum so the receiver can tell a network from a liar. Build the splitter, the per-chunk SHA-256, the manifest that describes the whole file, and the reassembly that puts pieces back together in the order they belong rather than the order they arrived.
- [Resumable uploads (Go)](https://runtimelab.io/challenges/uploadserver-go) — 7 stages, go: A four-gigabyte upload that fails at 97% and starts again is the reason resumable protocols exist. Build the server side: a session opened from a manifest, chunks accepted in any order and written at their exact offsets, a progress endpoint that says what is still missing, eight clients at once with one in ten chunks corrupt, a whole-file checksum that seals the session — and a process that is killed mid-transfer and comes back knowing exactly what it already has.
- [Backend Engineering (Go)](https://runtimelab.io/challenges/backend-go) — 40 stages, go: Build RuntimeHub, the service behind a GitHub-like API — from the listener and its timeouts up through CRUD, then a real PostgreSQL underneath it: migrations, transactions, lost updates, isolation levels, deadlocks and idempotency. Tested against a real database, never a fake.
- [Build your own Postgres driver](https://runtimelab.io/challenges/driver-go) — 22 stages, go: Build RuntimePQ, a database/sql driver for PostgreSQL — message framing, MD5 and SCRAM authentication, prepared statements, transactions, query cancellation, COPY and a connection pool. Against a real server.
- [Build your own varint](https://runtimelab.io/challenges/varint-go) — 14 stages, go: A `uint64` costs eight bytes whether it holds 1 or 18 quintillion. LEB128 makes small numbers small — and it is the encoding under Protocol Buffers, SQLite, DWARF and WebAssembly. Build the codec, then the wire format on top of it, then the parts that face an attacker.
- [Write-Ahead Logging (Go)](https://runtimelab.io/challenges/wal-go) — 18 stages, go: Build a durable write-ahead log from first principles — varint framing over your own encoder, masked CRC-32C, torn-tail recovery, fsync versus fdatasync, page-boundary padding, group commit, segment rotation with an atomically-rewritten manifest, checkpointing, and a replay that is checked against corruption at every byte offset.
- [Systems Programming: memory & syscalls](https://runtimelab.io/challenges/learn-systems-c) — 15 stages, c: Build the primitives real systems are made of — allocators, raw syscalls, a lock-free ring, a thread pool, and an event loop that waits on sockets, timers and signals alike — from scratch in C, under AddressSanitizer.
- [Build your own HTTP parser](https://runtimelab.io/challenges/http-parser) — 20 stages, go/python: Parse HTTP/1.1 the way a proxy has to: request lines, header rules, three kinds of body framing, chunked decoding, pipelined messages — and the request-smuggling cases that come from two parsers disagreeing.
- [Packet Journey](https://runtimelab.io/challenges/packet-journey) — 20 stages, go/python: One packet, decoded outward from the wire: Ethernet, VLAN tags, ARP, IPv4 and IPv6, ICMP, UDP and TCP — then a whole capture, reassembled into flows and printed like tcpdump.

## Career paths

- [Backend Engineer](https://runtimelab.io/roadmap/backend): Ship production services in Go: HTTP, data stores, and the systems behind them. Starts with four short ones you can finish in an evening.
- [Platform / SRE](https://runtimelab.io/roadmap/platform): The infrastructure layer: systems programming, distributed coordination, the network — and the tools you type every day.
- [Systems Engineer (C)](https://runtimelab.io/roadmap/systems-c): Go under the runtime: memory, the kernel's primitives, and the filesystem.
- [AI/ML Engineer](https://runtimelab.io/roadmap/ai): From what a token is up to a served, retrieval-augmented, tool-using system.

## Writing

- [All posts](https://runtimelab.io/blog) — [Atom feed](https://runtimelab.io/blog/feed.xml)
- [What happens when you press Run](https://runtimelab.io/blog/what-happens-when-you-press-run): Your code goes into a repo we host, a worker on a separate machine checks it out and runs the tester in a container with no network, and a pass leaves a record you can point at. The path from button to green, and the four limits along it.
- [Tracks, paths and chapters: how the catalogue is organised](https://runtimelab.io/blog/how-the-catalogue-is-organised): Forty-odd challenges is too many to read as a list. They are sold as tracks, shown as career paths, and released as monthly chapters — three different cuts of the same catalogue, and it helps to know which is which.
- [Inside the workbench: a tour of the stage page](https://runtimelab.io/blog/inside-the-workbench): Every stage on Runtime Lab is worked in one page: the stage list, the instructions and the help around them, an editor on your own repo, and the run output. Here is what each part is for, and the shortcuts that make it quick.
- [Runtime Lab opens on 1 September](https://runtimelab.io/blog/runtime-lab-opens-1-september): What is actually there on day one, why the tests run on our hardware instead of yours, and what it costs.
- [Build your own curl: the request journey, one hop per stage](https://runtimelab.io/blog/build-your-own-curl): Twelve stages that start with a raw TCP socket and end with a working curl. Each one adds exactly one thing a real request passes through, and each one is gated by a bug that a competent person writes first.
- [The skill that got scarce](https://runtimelab.io/blog/reading-code-you-did-not-write): AI writes plausible code faster than anyone can review it. The bottleneck moved from producing code to judging it — and judging it means knowing the failure modes. That is a thing you learn by hitting them.
- [What a finished challenge leaves behind](https://runtimelab.io/blog/what-a-finished-challenge-leaves-behind): Finish every stage and you get a public record: which challenge, in which language, which stages, against which pinned version of the tester, on which date. Here is what that is good for — and, just as importantly, what it is not.

## Optional

- [Campus ambassadors](https://runtimelab.io/partners): the referral programme.
- [Waitlist](https://runtimelab.io/waitlist): pre-launch signup.
- [Terms](https://runtimelab.io/terms) — clause 6 carries the content attribution.
- [Privacy](https://runtimelab.io/privacy), [Refunds](https://runtimelab.io/refunds)

## Notes for agents

- Stage instructions, the per-challenge stage list and the chapter structure
  require a signed-in account and are not published. Please do not present a
  syllabus for a challenge as if it were public information.
- Challenge availability changes; https://runtimelab.io/catalog is the current source.
- Canonical origin is https://runtimelab.io. The app and API hosts are not public.