A bit of context: for every language/environment we have a Dockerfile (naturally) and a JSON configuration that describe how it runs, how it install packages, how it runs unit tests, how it formats code, etc. When we build the container we insert a program that we call pid1, it's the container's interface to the rest of the world.

The container manager creates pools of these containers with some rudimentary predictive logic to make sure we have enough containers to deliver on our promise of "loads in 2 seconds". When we take a container out of the pool, if we're reviving a container, we mount a GCS-backed fuse filesystem with the user code (it needs to be backed by GCS to handle persistence, say you're writing to a log file, it should be there next time you load your project). We then send the relevant setup command to pid1 (either init, or wakeup) which sets up the repl to start the user app, the repl, or what have you.

> What actually happens behind the scenes to make a deploy go live

We poll the container for published ports and the moment we see an open port we add a record to an etcd which stores the routing state. We then send a command to the client that we published a port, which will react by opening an iframe. Then the iframe or any request to the published url will hit our outer reverse proxy which will query etcd to find the container and if the container is alive we will send the traffic to the relevant container manager which has another reverse proxy which sends the traffic to the container.

If the container however is dead (from idling or because of an error) we revive via picking a container out of one the pools and going through the initialization phase described above.

Finally, we also host our own docker image registery so that we can push new images, whether new languages, new versions or what have you.

There is a lot more to talk about here so I or someone on the team will write a post soon.