An expensive way to run Doom.

You’ve heard of Doom running in a smart fridge, Doom in a calculator. All of that takes a lot of engineering effort to run Doom on the smallest hardware possible.

So here’s a guide on how to run Doom in one of the most expensive hardware setup I could think of.

Architecture

Let’s start from the architecture:

The architecture is pretty simple:

• User SSHs into a server deployed on K8s.
• The Go server has the Doom binary and runs it for the user.
• SSH input is piped into the binary.
• Binary output is piped to the user’s terminal.

And now we have it, fully fledged cloud gaming for our users.

What’s good about this architecture

• Doom is run server-side, so hey cloud gaming.
• Very easy to scale to 1 billion active users, you could save the checkpoint file for each game based on SSH fingerprint to make the Doom game completely resumable.
• There is no better way of interacting with applications than the terminal.
• Your colleagues will be very impressed that you managed to run Doom in K8s.
• That’s it really.

What’s wrong

• The binary is compiled once and embedded into the Go SSH Server binary. That is wrong for so many reasons, and it won’t work for users with just a slightly different hardware setup.
• Try to guess how many concurrent SSH sessions it takes to reach 100% CPU usage of the pod? Well, this is the kubectl top output after 4 sessions:

    kubectl top pod doom-k8s-0 -n doom-charm --containers 
    POD          NAME    CPU(cores)   MEMORY(bytes)   
    doom-k8s-0   app     2175m        58Mi      
  

• To run Doom in a terminal, a very feature-complete terminal is required, for example Ghostty

What’s left?

If you feel like being nerd-sniped, it would be cool to add a GPU into the mix. I don’t know exactly how, but it would certainly increase the cost of this hardware setup just to run Doom.

How to do it

Disclaimer: I’ve been working for Canonical in the last year, and in particular in the Juju team. So here you will see a lot of Canonical products. It’s not an ad, it is just what I (sort of) know!

In Juju, you can create a Charm, which is an operator that wraps your application code and handles instructions to deploy on K8s, configure, and all that good stuff.
And that is exactly how I did it to create this application which runs on K8s.

The code for this application + charm can be found here.

There are some instructions if you’d like to try it locally. Do it at your own risk! :)

There are some links in the README.md if you want to reproduce the charm locally or if you want to follow the tutorials to do something else in K8s and Juju.

Feel free to reach out if you are curious about anything.