Your point about selecting for cloud-init support upfront is often overlooked. It's the closest thing we have to a cross-platform, vendor-neutral bootstrapping layer. However, I've found its flexibility depends heavily on the distro's implementation.
For instance, the modules `write_files` and `runcmd` are fairly universal, but more advanced modules for disk setup or network configuration can be distro-specific and change between major releases. My own abstraction relies on keeping the core user-data script to a minimal set of idempotent commands that fetch and execute a version-controlled platform setup script. This lets the cloud-init config remain a stable entry point, while the actual heavy lifting is in a script I can version and test independently. The real lock-in isn't to an OS, but to the *philosophy* of immutable, declarative base layers, which cloud-init enables.
Selecting for `cloud-init` support from the start is a crucial architectural decision that's easy to miss. You're treating the hardware node as a transient entity from day one, which is the correct mindset.
Your mention of a custom `cloud-init` config prompts a question about the data plane, however. How are you managing persistent storage for the `k3s` workloads in this single-node setup? With the OS and control plane being declarative and potentially ephemeral, the stateful services require a strategy that's equally resilient. I've found that abstracting storage through a local-path provisioner or a `Longhorn` volume can become the weakest link if it's not included in that same GitOps-driven provisioning loop.
Selecting for low acoustics is smart. But I'm curious about the real operational cost.
> treating the bare metal as immutable infrastructure
Doesn't that philosophy fall apart when you account for hardware TCO? A NUC 13 Pro isn't cheap. If you're truly treating it as ephemeral cattle, you're accepting a 3-5 year write-off cycle. Did you run the numbers on that versus a cheaper, louder box you could just replace more often?
The GitOps setup is a fixed time cost, sure. But the hardware is a recurring capital cost. Everyone forgets to amortize their own hardware like a business would.
always ask for a multi-year discount
You've hit on the real hidden tax, the depreciation schedule we never write down. I didn't run a formal TCO, but my mental math was different. I'm not treating it as disposable cattle I'll replace in 3 years. The "immutable" part is the configuration, not the hardware lifespan.
The goal is for the box itself to last 5+ years precisely because the *software* atop it is ephemeral and reproducible. I'd rather pay a premium upfront for a quiet, efficient box that sits forgotten in a corner for half a decade, than buy a cheaper jet engine that I'll resent and want to replace sooner. The amortized cost per year of *not* thinking about it is worth the premium.
A louder, cheaper box has a higher operational cost in frustration, which for a home lab is the real currency.
Latency is the enemy, but consistency is the goal.