How the Academy runs
The first question every developer asks about this is where the Solidity compiles, usually followed by what happens when several people open a lesson at once. The honest answer is that concurrency is not a server property here at all: the compiler and the EVM run inside the student’s own browser, so four students and four thousand cost us exactly the same.
There is no compile server, and no endpoint that offers one
Not a container per user, not a pool, not a queue. Our servers hand out static files and never see the code a student writes. That is also a privacy property: the contract you type in a lesson is never transmitted anywhere.
What actually happens when you type
- 1
Once per browser: the compiler downloads
Opening a Solidity lesson fetches one 8.5MB file from our origin. The filename carries the compiler version and commit hash, so it is served with a one-year immutable cache header. A browser that has it never asks again, and a returning student pays nothing.
- 2
Every keystroke after that: your CPU, not ours
The compiler lives in a Web Worker, off the main thread so the tab never freezes. Your source goes into it and bytecode comes out, roughly 20ms for a lesson-sized contract. No network is involved, which is why lessons compile as you type instead of behind a Run button.
- 3
The result runs in an EVM in the same tab
The bytecode is deployed into an in-browser EVM and the lesson’s transactions run against it. That is where the storage grid and the timeline scrubber get their data: real storage writes, captured at the opcode level.
Measured
There is no request. The compiler runs in a Web Worker in the student’s tab.
A small contract, second compile onward. Fast enough that lessons compile as you type, with no Run button.
Version-stamped filename, served immutable. A returning browser never fetches it again.
Paid once per tab, and only when a Solidity lesson opens.
The compile number is asserted on every CI run, not quoted from a blog post. If it regresses past the point where live-on-type is comfortable, the build fails.
Not every lesson pays for a compiler
simA scripted chain driven from a command line. Used for the concept lessons, blocks, gas, the three chains, validators.
No compiler, no EVM. Plain JavaScript in the page.
jsReal viem against a real EVM running in the tab, over a precompiled chain fixture committed to the repo.
No compiler. The fixture was compiled once, at build time, by us.
evmReal Solidity: solc compiles what the student typed, and the bytecode is deployed into an in-browser EVM.
The only runtime that loads the 8.5MB compiler, and only when such a lesson opens.
Which is also why running arbitrary code here is safe
A server-side runner has to defend against a student who writes an infinite loop, opens a socket, or tries to read the filesystem. We do not have that problem, because the code never reaches a machine we own. It runs in the browser’s own sandbox, in a worker with no network access and a hard five-second timeout, on the student’s hardware. The worst case is one slow tab, and it is theirs.
If you are embedding this
The same property is what makes an Academy module free to host on someone else’s site. A partner drops in an iframe and their infrastructure carries no compute, no runner, no rate limit and no abuse surface, their visitors’ browsers do the work, and our servers only hand out cached static files.