Day 0: Why DevStation?

It usually happened late at night. A disk in a machine that had been running for years would quietly give up, the OS wouldn’t boot, and there I was again — reinstalling, restoring backups, trying to remember exactly how the thing had been wired together the last time. DevStation started as an answer to that recurring night. This is the story of how it got there.

A homelab for more than fifteen years

I’ve run homelabs for more than fifteen years. Early on, the router was the firmware: an AMD Geode with 512 MB of RAM running BrazilFW as its operating system, bonding a 10 Mb ADSL link and a 2 Mb cable link — the latter with a static IP from a local ISP — into something stable enough to host online RPG game servers for friends. Next to it, a Pentium 4 with 2 GB ran an appserver — PHP and Apache — for the game and its site.

Over the years the boxes got more serious: proper Linux servers, more services, and eventually everything living on Proxmox. But one thing never changed — it was consumer hardware running 24×7, doing work it was never rated for.

The same failure, over and over

So the disks died. Not dramatically — just the slow, ordinary death of hardware that never gets to rest. And every time, the same evening repeated itself.

I did the responsible things. Automated database dumps, scheduled backups, uploads to the cloud. RAID 1 and SSDs later on to buy resilience. None of it removed the real cost: the data survived, but the machine — the exact arrangement of VMs, packages, configs, and the dozen small decisions that made everything talk to each other — did not. Restoring a backup was easy. Rebuilding the environment around it was not.

And the environment drifted out of my own head. Give it a few months of stability and I could no longer tell you, from memory, exactly how the cluster was laid out.

Trying to make it reproducible

The first honest attempt was documentation-as-code: I started versioning docker-compose files and Kubernetes manifests on GitHub, each with a README walking future-me through the steps to bring it all back. It helped. It also wasn’t enough. A rebuild was still a manual march through those READMEs, and with limited free time it could stretch across days.

The first cut: Jenkins, Terraform, and a chicken-and-egg problem

The next idea was to actually orchestrate the thing on Proxmox: Terraform to provision the VMs, Jenkins to run the pipelines that turned bare VMs into running services. I built it — it lives in an earlier repo called platform.

It worked like this. A Bash CLI with a dialog wizard drove Terraform (the bpg/proxmox provider) to full-clone VMs from a cloud-init template. Jenkins — defined as code through a Job DSL seed job — then ran the pipelines that configured each node: Docker and Portainer here, a K3s control plane with External Secrets and ArgoCD there, an agent joining the cluster, and a build pipeline that produced images and committed manifests for ArgoCD to sync. Secrets came from Infisical at runtime.

It proved the idea. It also had a flaw I couldn’t design away: it needed running infrastructure to provision infrastructure. Jenkins, Infisical, Portainer, the proxy — all of them had to be standing before any of the automation could run, and standing them up was itself a manual bootstrap. When a disk died, I wasn’t one command from recovery; I was one command from rebuilding the thing that rebuilds the thing.

Why a CLI

That chicken-and-egg is the reason DevStation is a CLI — a single self-contained binary. A binary starts from zero. It doesn’t ask you to first stand up a control plane, a secrets manager, or a CI server; it is the tool that stands those up. Nothing has to already exist for it to work, which is exactly what the previous design could never claim.

It’s also why a local secret vault is a first-class feature rather than an afterthought. You need somewhere safe to keep credentials from the very first minute — before there’s an Infisical, before there’s a cluster, before there’s anything. The vault is local and encrypted at rest; a later cloud-sync feature will add another layer of durability without ever making the first run depend on the network.

Describe the topology once

The shape of DevStation follows from that. You describe your topology once — the Proxmox clusters, the nodes, the VMs — and the services that run on top of them, grouped into what we call stations.

A station is a logical cluster: a set of services that can be spread across N VMs and treated as one unit. A station might run k3s (clustered or standalone) as a foundation, and host ArgoCD or Percona Everest on top of it; another might run an Nginx Proxy Manager that wires up DNS and Let’s Encrypt certificates automatically, or Jenkins sitting on Portainer.

Each service comes from a blueprint — a declarative manifest paired with shell scripts, together describing how to install, verify, and tear a service down. Blueprints are what make a service reproducible instead of remembered. And because the whole topology is declared, DevStation can destroy and reprovision it — a single VM or the entire estate — on demand.

And let an agent drive it

The last piece is that none of this has to be driven by a human at a keyboard. DevStation embeds an MCP server over stdio, so an AI agent — Claude Code, Codex, whatever speaks the Model Context Protocol — can orchestrate every feature: list the topology, provision a node, install a service, tear it all down. The same boundary I use from the terminal is the one an agent uses to run the loop unattended.

Why “DevStation”

The name came before the tool. I’d registered devstation.tech years earlier — at first just to have real DNS in front of the homelab, somewhere to expose services from behind a residential connection. But the word stuck for a reason: what I actually wanted was a development station — a place to prototype personal projects, tinker with home automation, stand up a test bed, throw a proof-of-concept together and tear it down again.

Making that environment reproducible is the first job. It isn’t the last. A station is meant to grow into more over time — managing development environments, and, now that agents are part of the workflow, the harness tooling that helps drive projects forward.

There’s a plainer reason too. A name that covers all of it — a GitHub org, project-scoped email, a single brand — makes the whole thing feel a little less like a hobby folder and a little more like a project, and keeps it at a healthy arm’s length from my personal profile.

Day 0, repeatable

The disk will die again. That part hasn’t changed and probably never will. What’s changed is what happens next: instead of a lost weekend and a strained memory, rebuilding the homelab is a described topology and a command. Day 0 — the day you stand everything up from nothing — used to be the worst day. The whole point of DevStation is to make it an ordinary one.