How Compiler Explorer Runs on AWS in 2026 — Matt Godbolt’s blog
How Compiler Explorer Runs on AWS in 2026
Written with LLM assistance.<br>Details at end.
I’ve been meaning to write an update on how Compiler Explorer actually runs on Amazon’s cloud, and it’s been sat on my list for a good while now, somewhere behind the other random things that take up what laughably I refer to as my spare time1.
The last time I wrote about this was 2016, when the whole site was a load balancer, a couple of instances and some Docker containers I built on my laptop. I wrote a much longer how it works last summer, but that one is mostly about Compiler Explorer and only incidentally about the cloud it sits on.
It’s no secret that we run on AWS, and none of it is hidden: the infra repository has all the terraform, the install scripts and the ce command line tool we drive the whole thing with, so if you’d rather read the real thing than my description of it, help yourself. So this one goes the other way round, through the Amazon services we lean on, roughly in the order your compile request runs into them.
Getting your code as far as our servers
Your browser talks to CloudFront, Amazon’s CDN. We run two separate CloudFront distributions. The one in front of godbolt.org mostly just hands requests on to our load balancer, caching what it sensibly can and compressing things on the way back out2. The bulky static stuff lives in an S3 bucket behind a second distribution at static.ce-cdn.net: the compiled JavaScript, the images, the web fonts. Much the largest part of that is Monaco, the editor component out of Visual Studio Code, which is what gives you the syntax highlighting and the squiggly underlines and the rest of it. It’s a lot of JavaScript to send someone who only wants to look at some assembly, so it’s worth having it cached near them.
Sitting in front of that is WAF, doing our rate limiting. Our limits are very simple and very high, mostly because we used to be stricter and it kept catching C++ trainers: a whole classroom behind a conference’s NAT looks like a single very keen IP address. We could probably do something cleverer with fingerprinting, but raising the limit was easier and it hasn’t been a problem since.3
Rather a lot of fleets behind one load balancer
Behind CloudFront is a single Application Load Balancer. It works out from the path which cluster a request is for, and then picks a healthy instance in that cluster to send it to. Almost everything has no special prefix at all and goes to the production fleet, which is where the overwhelming bulk of the traffic ends up. /beta* and /staging* go to the beta and staging fleets4. /winprod* goes to a fleet of Windows instances running MSVC, /aarch64prod* to Graviton machines that run ARM code natively rather than under emulation, and /gpu* to machines with real NVIDIA cards in them5.
Each of those is an Auto Scaling Group, and these days each one is doubled up: a blue and a green. To deploy, we bring up the other colour, wait for it to go healthy, point the load balancer’s target group at it and drain the old one. If it’s wrong, we point it back. Before that, deploying meant a rolling restart of the fleet with our ce command line tool, one instance at a time. That worked well enough, but backing out a bad release meant rolling the whole fleet forward again onto the previous version, which is a bit slow when you’ve just broken the site.
The scaling itself is simple: we just try and keep the average CPU load below a threshold. We’ve kicked around more sophisticated ideas but this one is supported out of the box6.
Renting the bits nobody else wants
The production fleet is almost entirely spot instances – unused EC2 capacity, sold off cheap, on the understanding that you can be evicted at two minutes’ notice. It’s a 60-90% saving over on-demand – quite a lot of money, for us.
We can get away with that because our instances don’t really matter. Everything that needs to survive lives on the shared filesystem, in S3 or in DynamoDB, so an instance that vanishes is just an instance that gets replaced. We ask for sixteen different instance types across the m5, m6, m7, r6 and i3/i4i families. The allocation strategy is price-capacity-optimized – Amazon’s way of saying “pick whichever of these is cheapest and least likely to get yanked”. In practice we get evicted, the scaling group notices, and a new one turns up.
Why the compilers are the hard part
We have around 6,000 compiler entries9 across 93 languages, and we never delete any of them7. Once a compiler version goes up it stays up, so that Stack Overflow answer showing a GCC 4.8 codegen quirk still compiles today. It’s our bit against link rot, and it does mean we hoard an awful lot of binaries.
All of that lives on EFS, Amazon’s elastic NFS, and NFS has latency. C-like...