Infrastructure Automation at Scale.

Platform & DevOps Engineer — GitOps, Kubernetes, and end-to-end infrastructure automation.

From bare-metal provisioning with Terraform to self-healing Kubernetes clusters managed by ArgoCD. I build platforms that are declarative by design, secure by default, and automated end to end — this site runs on the very homelab it describes.

Engineering Philosophy

I treat infrastructure as a product. My focus is architecting resilient, production-ready systems where manual intervention is the exception, not the norm — from the OS layer up to application configuration, every piece is declarative and version-controlled.

Everything below runs in a single-operator homelab I built and operate as real infrastructure: bare-metal Proxmox hosts, an immutable Talos Kubernetes cluster, GitOps delivery via ArgoCD, a signed-and-attested CI supply chain, and custom tooling where off-the-shelf didn't fit. It's not a demo — it's the platform, and it's the proof.

24
Kubernetes apps
17
Helm charts
14
CI/CD components
18
Managed VMs / LXCs
6
GitOps repos

Featured Projects

GitOps Kubernetes Platform

KubernetesArgoCDGitOpsTalosHelm

A self-healing, production-grade Kubernetes platform on immutable Talos Linux, managing the entire cluster state declaratively through ArgoCD with an app-of-apps pattern — 24 applications across four sync-wave tiers, all reconciled from Git.

The platform runs on a six-node Talos Linux cluster (three control-plane, three workers) and treats the entire cluster as a single declarative artifact. ArgoCD self-manages from a root Application; one ApplicationSet then generates every other Application from a Git files generator over per-app config files, so onboarding a new workload never touches central wiring. Secrets are sealed at rest (SealedSecrets), TLS is issued automatically, and identity is centralized through an OIDC provider fronted by a Traefik ForwardAuth middleware.

Key Technical Highlights

  • One ApplicationSet, every app: A single ArgoCD ApplicationSet with a Git files generator discovers every application from a per-app config.yaml. Adding an app is adding a directory — no central allowlist to edit.
  • Declarative from OS to app: Immutable Talos Linux (API-only, no SSH) underneath; every workload, namespace, sync wave, and sync policy declared in Git and reconciled by ArgoCD.
  • Tiered rollout: Four tiers (infra → data → services → user) with sync-wave bands bring dependencies up in the right order; auto-sync is opt-in per app.
  • Batteries included: Traefik ingress, cert-manager wildcard TLS, Longhorn distributed storage, MetalLB, and OIDC SSO (Pocket ID + oauth2-proxy ForwardAuth) — all GitOps-managed.

Technologies

KubernetesArgoCDHelmKustomizeTraefikLonghorncert-managerGo

App-of-apps reconciliation

Diagram: App-of-apps reconciliation

Shared CI/CD Component Catalog

CI/CDGitLabSupply ChaincosignSBOM

A dedicated hub that publishes 14 versioned, typed-input GitLab CI/CD components — plus one shared toolchain image — consumed by every repo in the estate. Releases are cut automatically from Conventional Commits; every artifact is cosign-signed and ships a syft SBOM attestation.

Before this hub, four repos each carried their own copy of the same lint, scan, and publish jobs — and drifted. The catalog centralizes that job logic behind a typed input surface, versions it like any other dependency, and hardens the supply chain: images and charts are signed by digest and carry SPDX SBOMs as attestations. A weekly scheduled rebuild refreshes base layers so CVE fixes land without a Dockerfile edit, and the new digest propagates to consumers automatically.

Key Technical Highlights

  • One source of truth for CI: 14 components (scan, lint, build, sign, SBOM, mirror, release) replace hand-rolled pipelines. Every consumer pins a version and passes typed inputs — the job logic lives once.
  • Automatic SemVer releases: An auto-tag component reads Conventional Commits since the last tag and cuts the next version (feat→minor, fix→patch, !→major); the tag pipeline publishes to the CI/CD Catalog.
  • Signed + attested by default: Every CI image and Helm chart is cosign-signed by digest, and a syft SPDX SBOM is attached as a cosign attestation — a real supply-chain story, not just a checksum.
  • One shared base image: A single ci-base image bakes the common toolchain and shared config defaults; consumers layer only their repo-specific tools and adopt updates via digest-pinned Renovate bumps.

Technologies

GitLab CIcosignsyfttrivygitleaksDockerRenovate

Component release flow

Diagram: Component release flow

kryptos — Secret-Sealing CLI/TUI

GoKubernetesSecurityCLITUI

A from-scratch Go tool that turns declarative YAML secret configs into Kubernetes SealedSecrets. A cobra CLI plus a charm/huh TUI, with a two-pass derive engine, value generators, and a JSON schema for editor autocomplete — built to gate CI without cluster access.

kryptos started as a way to stop hand-running kubeseal and grew into a repo-agnostic tool. It reads a declarative config describing which secrets exist and how to produce them, resolves generators and derive types in two passes (so templates can reference other derived values), and writes SealedSecrets ready to commit. It ships a JSON schema for editor autocomplete, and its validate/diff/audit commands run offline — which is what lets CI verify secret configs without ever touching the cluster.

Key Technical Highlights

  • Nine subcommands: An interactive TUI plus seal, rotate, validate, audit, diff, layout, and dry-run — covering the full secret lifecycle from generation to drift detection.
  • Two-pass derive engine: Eight derive types (htpasswd, cluster_secret, render, jwt/hmac, tls, ssh_keypair, file) resolve in two passes so a derived value can consume another derived value in a template.
  • Generators, not literals: Value keywords (secure, strong, apikey, passphrase) mean secrets are generated, never pasted — the config declares intent, the tool produces the material.
  • CI-gating without a cluster: validate, diff, and audit run against the config and the sealed output offline, so a pipeline can catch secret drift before anything reaches the cluster. Released via goreleaser + auto-tags.

Technologies

Gocobracharm/huhSealedSecretsJSON Schemagoreleaser

Seal pipeline

Diagram: Seal pipeline

Three-Phase Infrastructure as Code

TerraformAnsibleKomodoProxmoxIaC

Bare-metal to running services with a clean tool separation and live-state handoff: Terraform provisions, Ansible configures by reading Terraform state directly, and Komodo reconciles committed TOML to running Compose stacks on every push.

The design keeps three tools in their lanes and lets state flow between them instead of being copied. Terraform provisions the Proxmox hosts and the cluster VMs and writes its state to object storage; Ansible’s inventory is a script that reads that state live, so there is no static inventory to fall out of sync; Komodo watches the repo and, on push, redeploys only the Compose stacks whose content changed — a deliberate choice to avoid redeploying every service on every commit.

Key Technical Highlights

  • Strict phase separation: Terraform owns provisioning (Proxmox hosts + cluster VMs via the bpg provider, state in S3-compatible object storage), Ansible owns configuration, Komodo owns service deployment — no phase leaks into another.
  • Live-state handoff: Ansible's dynamic inventory reads Terraform state directly — no generated inventory YAML to drift. Terraform even emits per-host SSH keys the later phases consume.
  • Push-to-reconcile services: A git push triggers a ResourceSync plus a single batch procedure that redeploys only the Compose stacks whose content actually changed — no fan-out across every host.
  • Packaged as a collection: Ansible roles ship as a versioned collection (common system/users/ssh/docker, Komodo, and cluster roles) with a two-user bootstrap-then-harden model and Vault-managed secrets.

Technologies

TerraformTerragruntAnsibleKomodoProxmoxDocker Compose

Provisioning phases

Diagram: Provisioning phases

OCI Helm Chart Registry

HelmOCICI/CDPython

17 custom Helm charts authored to a single consistent contract and published to an OCI registry, with a CI pipeline that validates every chart without a live cluster and signs each release with cosign.

The registry is as much about consistency as distribution. Seventeen charts — covering stateful services, gateways, and utilities — share one authoring contract so any of them reads the same way. The pipeline validates changed charts by rendering and parsing them without a cluster, publishes idempotently to an OCI registry, and signs every release by digest (rolling back an unsigned chart rather than leaving it published).

Key Technical Highlights

  • One chart contract: Every chart follows the same conventions — @section/@param value docs, an existingSecret pattern for external secrets, and {{- fail }} validation helpers for mutually-exclusive options.
  • Cluster-free validation: CI renders each changed chart with helm template and parses the output with Python — catching template and schema errors without needing a Kubernetes cluster in the pipeline.
  • Idempotent, signed publishing: Charts publish to the OCI registry with smart version detection to prevent overwrite conflicts; each release is cosign-signed by digest, with an automatic rollback if signing fails.
  • Renovate-tracked images: Chart image tags are Renovate-managed and auto-bump the chart version, so upstream updates flow through as reviewable, soaked merge requests.

Technologies

HelmOCI RegistryGitLab CIPythoncosignRenovate

Chart publish pipeline

Diagram: Chart publish pipeline

Supply-Chain & Dependency Automation

RenovateAutomationSecurityPython

The estate's automation backbone: one centralized Renovate runner keeping every repo current, and a sanitized public-mirror pipeline that scrubs private repositories and force-pushes public GitHub mirrors behind a hard verification gate.

Two automations keep the estate healthy and shareable. Renovate runs from one central project that autodiscovers every repo and applies a shared policy, with low-risk updates auto-merging after a soak so routine bumps never need a human. The mirror pipeline is what makes this very portfolio possible: it sanitizes each private repo against a layered config and refuses to publish unless a verification pass finds zero sensitive terms — turning internal work into public proof without leaking anything.

Key Technical Highlights

  • One runner for the estate: A single autodiscover Renovate project with a shared preset (plus modular presets every repo composes) replaces per-repo jobs — one schedule, one token, one warm cache.
  • Low-risk auto-merge: Digest and pin updates, and patch updates on stable packages, merge themselves once CI is green and their soak window passes; minor and major updates stay under human review.
  • Layered sanitization: A shared sanitize base (identity, domain, and token replacements plus protective exclude lists) is extended per repo with a union-only merge — a child config can only add protections, never remove one.
  • Fail-closed mirror gate: Before any public push, a verifier hard-fails if a single sensitive term survives (names, private domains, token prefixes) — so the private repositories become public mirrors safely and automatically.

Technologies

RenovateGitLab CIPythongitleaks

Sanitized mirror pipeline

Diagram: Sanitized mirror pipeline

What I Self-Host

A live catalog of services running on the cluster and the Proxmox hosts — all GitOps- or IaC-managed, TLS-terminated, and SSO-gated. (Hostnames are kept private.)

Platform & Infrastructure

  • ArgoCD — GitOps controller (self-managing)
  • Traefik — Ingress controller / edge router
  • cert-manager — Automatic wildcard TLS
  • MetalLB — L2 load balancer
  • Longhorn — Distributed block storage
  • Cloudflared — Cloudflare tunnel ingress
  • Harbor — OCI registry (images + charts)
  • Sealed Secrets — Secret encryption controller

Identity & Data

  • Pocket ID — OIDC identity provider
  • oauth2-proxy — ForwardAuth SSO gate
  • PostgreSQL — Shared relational database
  • Valkey — Cache / session store
  • Headlamp — Kubernetes dashboard
  • Bitwarden — Password manager

Productivity & Media

  • Joplin — Note-taking sync server
  • Memos — Lightweight notes
  • Actual — Budgeting & personal finance
  • DocuSeal — Document signing
  • Paperless-ngx — Document management
  • PrivateBin — Encrypted pastebin
  • SearXNG — Privacy metasearch engine

AI & Self-Hosted Tooling

  • Open WebUI — Multi-model AI chat front-end
  • LiteLLM — LLM proxy / gateway
  • Semaphore — Ansible / Terraform UI
  • Komodo — Compose deployment control plane
  • AdGuard Home — Network-wide DNS filtering (HA pair)
  • Technitium — Authoritative DNS (HA pair)

Technical Skills

Container Orchestration

KubernetesTalos LinuxDockerDocker Compose

GitOps & CI/CD

ArgoCDHelmKustomizeGitLab CI/CDCI/CD ComponentsRenovate

Infrastructure as Code

TerraformTerragruntAnsibleKomodoProxmox VE

Supply-Chain Security

cosignsyft / SBOMtrivygitleaksSealedSecrets

Networking & Ingress

TraefikMetalLBCloudflare Tunnelcert-managerLet's Encrypt TLS

Identity & Access

Pocket ID (OIDC)oauth2-proxyForwardAuth SSOAnsible Vault

Storage & Data

LonghornPostgreSQLValkey

Observability

Metrics ServerResource metrics

Languages & Scripting

GoPythonBashYAML

Cloud & Platforms

AzureCloudflareHarbor (OCI)GitLab

Version Control

GitGitLabGitHub

Certifications

Azure Administrator Associate

Microsoft

Issued: August 2025

Credential ID: 86F88C248C92836B

Get in Touch

Interested in discussing platform engineering, GitOps, or infrastructure automation? Let's talk.