skip to content
Logo Rabbit Holes
A blacksmith deep in an underground cave

Creating Hephaestus - Self-hosting a dev box

/ 4 min read

Table of Contents

Introduction

Hephaestus (UK: /hɪˈfiːstəs/ hih-FEE-stəs, US: /hɪˈfɛstəs/ hih-FES-təs; eight spellings; Ancient Greek: Ἥφαιστος, romanized: Hḗphaistos) is the Greek god of artisans, blacksmiths, carpenters, craftsmen, fire, metallurgy, metalworking, sculpture, and volcanoes.[2]

Like most software engineers in 2026, my development workflow is increasingly agent-centric. However, as convenient (and frankly more astonishing by the day) as they are, they come with a handful of issues / compromises.

Most notably, as far as I’m concerned, is a tight balancing act between giving the agent enough freedom, while keeping some things out of reach.

Let me explain what I mean by that: As more and more of my development workflow shifts towards agents, the pull towards the practicality of YOLO mode increases exponentially. I want to be able to start a few sessions in parallel, and let the agents do their thing. The implication is that I am absolutely not interested in pressing enter every time one of them does a git commit.

On the other hand, I’ve spent enough time on the internet to know that things can go wrong if you use this approach. Risks include:

  • Agents deciding to delete files they shouldn’t, simply because they aren’t in the cwd they thought they were.

  • Credentials and accesses from your machine can be misused, and your live databases might suffer from it.

So the solution was the following: A playground for an agent to do whatever it wants, with the strict minimum of access it requires to function, and all the metaphorical dog poo and razor blades taken out of the sand.

The machine

To me, this took the form of a VM in Proxmox. I have multiple machines at home, some of which can easily run a development environment. LXCs and Docker containers were briefly considered, but the clearer separation brought me more peace of mind.

Docker sandboxes could be an interesting addition, but that will be a later topic.

So I carved out a VM from my server, gave it 16GB of RAM and installed the latest Ubuntu server on it. My workflow is basically completely in the terminal, so a headless box reached via SSH was just fine.

The environment

Now like many, I’m a creature of habits. So although I wasn’t on my main machine, I sure wanted my tools available. A couple chezmoi commands later, the tools had arrived.

The next thing I did was to give the box its own SSH key.

After that, time to download some repos! GitHub works, great. Time to get the work projects downloaded.

And that’s when the first complication hit:

VPN

My workplace hosts their own GitLab instance, which is only available when connected to the VPN. This wouldn’t be too much of an issue, but we use an AWS SAML client. This is a problem for two reasons:

  • I’m not a fan of the idea of dropping my Google credentials on a box that is meant to have the least access possible.

  • Even if I get over that, the login flow requires me to visually choose my account. Not the best situation for a remote headless box.

After some ping-ponging with the agent of the day, this ensued: https://github.com/ywallis/aws-vpn-cli

This is an adaptation of some existing work, and it lets me do the following:

  • Temporarily map a port from my main machine to the SSH box.
  • Start a VPN connection flow
  • copy-paste a string, log in

And voilà! My box is on the VPN.

VPN, round 2

On the following day, as I sit down in the office, I realize I now have the opposite issue. Hephaestus is sitting on my home network, and I can only reach it via VPN.

Since I’m not a fan of having to constantly stack VPNs, I decide to explore another option I wasn’t yet familiar with - cloudflare tunnels.

The setup is quite easy and well documented. The one catch in this scenario: If you want to use tunnels specifically for SSH, you have to install cloudflared on your client machine as well. Plus a simple entry in your SSH config file:

Terminal window
Host myserver
ProxyCommand cloudflared access ssh --hostname ssh.example.com

Conclusion

So far, I’m very impressed with the setup. I didn’t give it the beefiest specs, but it’s performing admirably. It also feels like magic to be able to issue a command via my regular terminal, see a PR pop up with included screenshots, and know that everything took place in a headless box in my office, no matter where I am.

I also don’t have to deal with a warmer laptop, since everything that requires power happens away from me.

Next steps

Although chezmoi is quite capable and I’m currently running Ubuntu almost everywhere, I’m definitely interested in how Nix could help me reproduce my environments consistently. Having a fully portable identity, perhaps even over different platforms altogether, seems like another interesting rabbit hole to go down.