Giving back: the same infrastructure questions on bare metal

My networking background keeps me interested in the physical side of infrastructure. Cloud and virtualization interfaces are helpful abstractions, but a service still depends on a machine, a network path, and somewhere to put its data.

The examples in this series include direct host bootstrap paths where appropriate. The GitLab repository separates provisioning from service configuration, and the kubeadm repository exposes the operating-system and cluster preparation layers. That makes it easier to see which parts change when the machine is physical rather than a Proxmox guest.

Start with available capacity

You do not need to recreate an expensive estate to learn. Start with one service on a machine you can administer, and compare its documented CPU, RAM, and storage requirements with what remains available. Kubernetes, a management plane, and observability compete for that capacity; installing them all at once can make the learning experience harder. A GPU is not required for these infrastructure examples. The series guide helps you choose the next dependency instead of treating the whole stack as the minimum starting point.

Inventory before installation

Know which machine you are configuring, which disks hold existing data, and how you will regain administrative access. Do not translate a VM example into a command that formats an unidentified physical disk. Verify interfaces, addresses, routes, time, and DNS before introducing delivery dependencies.

Network placement still matters. A public-facing service belongs behind a reviewed access and segmentation design. Putting a container on the hypervisor or connecting a DMZ host to a trusted network for convenience changes the risk and the recovery story.

Persistence is not a backup

A service surviving a restart says little about losing its disk. Local Kubernetes storage can tie a workload to one node, and several VMs on one physical host share that host's failure domain. Three guest machines do not automatically provide three independent physical failure domains.

Choose what data must survive, where its backups go, and what a restore needs. Include the source and delivery system in that exercise. If every recovery instruction is only available inside a broken local GitLab, bootstrap has become a circular dependency.

Keep the workflow you chose

A physical runner can execute GitHub Actions or GitLab CI, depending on the platform you choose. It needs reachability to the infrastructure and target hosts, protected credentials, and a deliberate execution scope. Public examples should be adapted into your own reviewed deployment configuration.

The GitOps guide connects these decisions to the rest of the series. The benefit of bare metal is not that it is automatically better; it is that working through the underlying dependencies can make your infrastructure decisions much more concrete.