Giving back: making GitLab a delivery foundation

Working across networking, automation, and SRE has made me care about what happens after a build passes. A successful job needs to connect to a specific artifact, a specific target, and evidence that the intended service actually changed.

The GitLab on Proxmox example gives readers a place to explore that connection. Terraform describes the guest, while bootstrap scripts configure the service. The same separation helps explain what belongs to infrastructure provisioning and what belongs to service installation.

Make the first step affordable

A useful delivery lab can begin with the resources you have. Check the repository's service requirements and leave capacity for the operating system, storage, and any runner jobs. You can choose GitHub as your source platform without hosting GitLab, or host GitLab when learning that service is part of your goal. Neither choice requires a GPU. Working DNS, time, routing, and an administrative path come before adding automation.

Build the delivery system independently

My own preference is local GitLab, but its initial installation cannot depend on the GitLab pipeline it is about to provide. Start with a reachable host, working time and DNS, and an independent administrative path. Keep enough bootstrap material available to restore the service when its UI or runner is unavailable.

Readers choosing GitHub can use GitHub Actions and their own reachable runner instead. Readers choosing GitLab can use GitLab CI and a GitLab runner. The series guide explains both choices. Neither path should require the other platform just to deploy its first service.

A runner is a real execution boundary

A runner that can reach Proxmox or SSH into a machine has useful privileges. Give it a defined scope, protect deployment branches and environments, and keep credentials in the chosen platform's secret facilities. Public example code is a learning resource; a private deployment repository is where your own reviewed configuration belongs.

The useful sequence is validation, a Terraform plan, review, and an explicitly authorized apply. The examples separate planning, provisioning, and service deployment so a new VM can be created before you establish trusted SSH host fingerprints. A green syntax check does not verify a service's TLS certificate, login, backup, or restore.

Delivery should leave a trail

I want to know which commit produced a change and which plan was applied. Persistent Terraform state needs a protected location and a backup, rather than disappearing with an ephemeral job workspace. GitLab data needs its own recovery process too; the VM definition cannot recreate lost repositories or application data.

This is a practical foundation for the rest of the giving-back series. It makes later automation easier to reason about because the place executing changes is itself understandable.