TECHNICAL BRIEF · INFRASTRUCTURE
Operable platform foundations for reproducible workloads.
A self-hosted control-plane layer for GitOps, observability, and CI runners. The eSIM application runtime remains deliberately simpler: Docker Compose and Traefik on standalone VPSes, supplied by immutable images from GHCR.
- Control plane
- Proxmox → 3 Rocky VMsThree-node k3s HA control plane, embedded etcd
- Delivery
- Argo CD + GHCRGitOps for platform services; digest promotion for application releases
- Validation
- k3d per CI runDisposable cluster installs the real charts before live reconciliation
Proxmox + Ansible
Inventory-driven playbooks create and configure three Rocky Linux VMs.
Three-node k3s HA
Embedded etcd provides the platform layer for GitOps, observability, private access, and CI runners.
Argo CD
Git declares the desired platform applications; sync, prune, and self-heal make drift visible and correctable.
ARC + k3d
Self-hosted ARM64 runners execute CI; disposable k3d clusters install the real charts before live reconciliation.
GHCR → Compose VPSes
CI publishes immutable images. Staging validates a digest; human approval promotes that same digest to production.
Repository-evidenced evolution
Platform repositories show continuous activity across the whole period: research, a first k3s GPU node with its own security suite, then consolidation into the three-node production platform.
This is the source-controlled delivery phase within the wider independent engineering period.
Product and platform research. eSIM provider API exploration and storefront groundwork, alongside AI knowledge-system development — the research that shaped both case studies.
First k3s platform. On the existing XCP-ng homelab: a declaratively managed gpu-node-1 running k3s with NVIDIA (2×3080), a k3s GPU security-hardening suite with probe and enforce modes, and a self-hosted opencode agent environment over Tailscale. AI research and agent development ran on this cluster from January.
Platform tooling. Workstation and node management consolidated declaratively (Nix), CI automation for the configuration repos, and the DriveNets DevOps Infrastructure Engineer role began in April.
Homelab consolidation. The core-platform-infra IaC stack moved VM-per-service workloads onto a three-node k3s platform defined as code on Rocky Linux — ARC multi-runner scale sets, an Argo CD GitOps split, and a Cilium upgrade for Kubernetes 1.35 landed across 68 commits.
Continuing evolution. Platform iteration continued with AI harness and agent-skills development running alongside.
Platform mechanisms
Each mechanism has a clear job: make platform state reproducible, delivery controlled, and operating signals visible. k3s runs the platform layer, not the current application runtime.
The workload stays small on Compose while CI and platform services gain a reproducible three-node k3s HA control plane.
- Ansible + VMs
- Mechanism: Ansible creates and configures three Rocky Linux VMs on Proxmox. Why: reproducible node lifecycle and replaceable k3s guests. How: inventory-driven, idempotent playbooks provision and join nodes.
- k3s HA control plane
- Mechanism: three k3s servers with embedded etcd. Why: control-plane quorum and safer node maintenance. How: rolling upgrade and replacement procedures preserve quorum while a node is serviced.
- Argo CD GitOps
- Mechanism: Argo CD reconciles platform applications from Git. Why: desired state is reviewable and drift is visible. How: app-of-apps with automated sync, prune, and self-heal.
- ARC runner pools
- Mechanism: Actions Runner Controller provides self-hosted ARM64 runner sets. Why: native builds and controlled CI capacity. How: an operations pool stays warm; workload runners scale 0→6.
- Observability + access
- Mechanism: VictoriaMetrics, Loki, OpenTelemetry, Grafana, GlitchTip, and private access. Why: inspect failures before they become tickets. How: metrics, logs, traces, alerts, health checks, and non-public operator access.
- Workload runtime
- Mechanism: Compose + Traefik on standalone ARM64 VPSes; GHCR image digests; Cloudflare Pages and API edge. Why: a smaller application runtime today. How: human-approved digest promotion, no production rebuild.
Controlled delivery
One delivery boundary separates platform and workload. Git declares platform state. GHCR declares the workload artifact. Human approval controls production promotion.
The application is not rebuilt for production. The validated staging digest is promoted.
Source + GitOps
Ansible provisions VMs. Argo CD reconciles platform applications from Git.
ARC runners + GHCR
Self-hosted ARM64 runners run CI and publish immutable images with provenance.
VPS runtime
Staging proves the digest. A human creates and approves production promotion; GitHub Actions deploys that same digest.
| Control | Evidence | Purpose |
|---|---|---|
| Toolchain | Nix, direnv, and pinned tools | Reproducible local and CI environments. |
| Integration validation | k3d cluster per CI run | Installs cert-manager, ARC controller, and runner-set release; waits for Ready; always tears down. |
| Artifact boundary | GHCR image digest + attestation | Staging and production run the same artifact. No production rebuild. |
| Rollback | Readiness assertion + prior tag | Readiness failure returns to the prior release; production rollback is a known digest. |
Why this maps to research infrastructure
The useful signal is not Kubernetes by itself. It is controlled, repeatable operation of an evolving technical environment.
The application provides a real workload with integration, release, and recovery pressure.
Reproducible environments. Nix, Ansible, and GitOps make the platform reconstructable from source-controlled definitions.
Controlled delivery. Pinned tools, immutable images, digest promotion, and human production approval constrain change.
Disposable validation. A k3d cluster per integration run exercises actual charts and readiness rather than static configuration alone.
Observable recovery. Metrics, logs, error tracking, backups, health checks, and runbooks make failure inspectable and recoverable.
Day-2 operations
The useful infrastructure artifact is the recovery path, not the install command. These are documented procedures exercised against the actual platform.
The scope is intentionally narrow: reproducible node and service recovery.
Change the channel in inventory and re-run idempotent automation. The quorum supports rolling node maintenance.
Remove a VM from inventory, destroy its VMID, delete the node object, and re-run provisioning to create and join the replacement.
Documented one-node-at-a-time path: cordon, drain, stop k3s, move storage, verify etcd health, uncordon.
VM snapshots and vzdump cover guests; etcd snapshots cover control-plane state; encrypted application database dumps land in Cloudflare R2.
In place
- Ansible VM lifecycle and idempotent re-runs
- Argo CD reconciliation, observability stack, private access, and runner pools
- k3d integration validation, pinned supply-chain controls, digest promotion, rollback path
- Backups, health checks, and concrete day-2 runbooks
Current scope
- Three-node k3s HA control plane improves node maintenance and control-plane continuity
- Application runtime remains Compose on VPSes; a k3s migration is future work only
- Cloudflare is edge/perimeter and R2 backup storage, not the runtime or orchestrator
- Production promotion remains human-created and human-approved
Technical walkthrough: I can show the delivery gates, disposable integration environment, recovery boundaries, and day-2 procedures.