Engineering Work

Start with the strongest work. Explore the rest by domain.

Validated projects, implemented tools, professional initiatives, and historical work are labelled separately. Expand a record only when you want the implementation detail.

Infrastructure Migration Case Study

Secure Always-On Git Platform

ValidatedAnsible / BashFeatured projectSelf-managed engineering project · Private foundation complete · Production migration pending

Designed and validated an always-on private Git foundation on a VPS with identity-based access, automated TLS, fail-closed activation, tested recovery, and verified reboot persistence.

Outcome: The private foundation passed its final reboot without manual intervention: Git HTTPS, split DNS, administration, application health, database health, certificate state, policy evidence, and firewall controls persisted. Production repositories and databases remain on the source platform pending a separately controlled migration.

Engineering detail and validation

Problem: Infrastructure automation depended on a Git service hosted by a Kubernetes homelab that powers down nightly. The replacement foundation had to remain available independently without exposing administration, Git HTTPS, or private DNS to the public Internet.
Solution: An Ubuntu VPS runs Gitea and PostgreSQL through root-managed Podman Quadlets. Tailscale identity policy controls access, Caddy terminates private HTTPS, Unbound provides split DNS, DNS-01 manages TLS, nftables restricts public access, and Ansible owns guarded activation, validation, rollback, and reboot-safe systemd ordering.
Architecture: Identity-verified clients reach only the VPS private interface. Caddy forwards private HTTPS to loopback-only Gitea, which uses PostgreSQL on a private container network with no host database listener. Unbound answers the private Git name on the same identity-controlled interface, while public web delivery remains separate and unchanged.
Scope: Completed self-managed private VPS foundation. Production data migration, Kubernetes egress, GitOps and build-runner integration, public cutover, and home-service shutdown remain outside the published result.

Core capabilities

Separated Git availability from the homelab power schedule with an always-on VPS foundation
Implemented named non-root administration, private identity policy, and public-access denial
Ran Gitea and PostgreSQL through root-managed Podman Quadlets with no host database listener
Automated DNS-01 TLS, split DNS, private reverse proxying, service health, and policy gates
Diagnosed and corrected a reboot-time service race through an Ansible-managed readiness check and systemd ordering
Proved rollback controls, positive and negative connectivity, reboot persistence, and final idempotence

Validation evidence

51 project tests passed
All seven Ansible playbooks passed syntax validation
Final Ansible reconciliation reported changed=0 and failed=0
Final reboot-persistence checks passed without manual Caddy intervention
Authorized private HTTPS, split DNS over TCP and UDP, and administrative access passed
Public SSH, private HTTPS staging, and public DNS-port negative tests passed
The existing public proxy, public DNS, Kubernetes environment, and home Git service remained unchanged

Read Secure Always-On Git Platform case study

Cloud Infrastructure Case Study

Hybrid-Cloud Kubernetes Disaster Recovery on OCI

ValidatedTerraform / Bash / PythonFeatured projectSelf-managed engineering project · Restore evidence plus live OCI inventory verified 24 July 2026

A cost-guarded Oracle Cloud recovery system that encrypts a controlled k3s workload off site, restricts the uploader by design, and proves one backup through an isolated restore.

Outcome: The OCI foundation was applied and reported converged, one encrypted backup was verified, uploader denial tests passed, and that backup was restored into a separate namespace and fresh volume with deterministic data checks. A read-only tenancy inventory on 24 July 2026 confirmed the private versioned bucket, five lifecycle rules, private subnet, Vault/key/secret metadata, budget and notification topic, with no compute, OKE, load balancer, NAT gateway, or database resources. The synthetic scope, notification delivery, retention lock, hard quotas, independent key custody, Flux ownership, and recurring restores remain incomplete.

Engineering detail and validation

Problem: A local cluster and its storage can share the same failure boundary. Moving recovery data off site introduces separate identity, encryption, retention, cost, and dependency risks, while an uploaded object still does not prove that an application can be recovered.
Solution: Terraform defines a compartment-scoped OCI foundation with private Object Storage, a default Vault and software key, restrictive networking, notifications, and a dedicated create/list uploader. Backup confidentiality relies on client-side age encryption before upload; the bucket adds provider-managed encryption rather than a customer-managed key. A hardened Kubernetes job exports selected non-secret resources, creates and validates a PostgreSQL dump, checksums and packages the payload, uploads with no-overwrite semantics, verifies presence, and removes plaintext working data.
Architecture: The data path runs from a controlled k3s workload through allowlisted export, database dump, checksums, deterministic packaging, client-side age encryption, a create/list-only identity, and private OCI Object Storage. Recovery uses separate administrator authority, strict archive validation, and an isolated PostgreSQL target. Terraform owns the cloud foundation; Kubernetes manifests and guarded scripts own workload deployment and secret handoff.
Scope: Self-managed infrastructure project. Completed evidence is limited to the OCI foundation, one controlled encrypted backup, uploader denial tests, and one isolated PostgreSQL restore; broader recovery and several operator-owned controls remain outside the current claim.

Core capabilities

Applied an isolated OCI foundation for private storage, key management, restricted networking, notifications, and least-privilege upload
Executed an encrypted no-overwrite backup of selected Kubernetes configuration and a controlled PostgreSQL database
Restored the verified archive into a separate namespace and fresh persistent volume without reusing the source database
Prepared and remotely verified an immutable Linux amd64/arm64 backup image while leaving the live migration review-gated

Validation evidence

Read-only OCI inventory on 24 July 2026 found one private versioned bucket with five lifecycle rules, one private subnet, one Vault, two key resources, one active secret, one budget, and one notification topic; no compute or managed Kubernetes resource was present
Applied-foundation report records reviewed plans, successful apply, a zero-drift follow-up plan, and live uploader allow/deny checks
Manual backup evidence records successful dump validation, deterministic data checks, encryption before upload, remote object verification, and plaintext cleanup
Isolated-restore evidence records a fresh namespace and volume, exact schema and data verification, source-workload integrity, negative paths, and cleanup
Current local make test passes ShellCheck, 12 mocked backup paths, 7 archive-validator tests, Terraform safety assertions, Kubernetes and container policies, range checks, quota syntax, recurring-restore contract, and blocker tests
Both Kubernetes overlays render locally and the immutable Linux amd64/arm64 image publication is remotely verified
Provider-backed terraform validate passes after the duplicate region declaration was reconciled; public repository CI now runs validation and the safety suite

View public repository

Read Hybrid-Cloud Kubernetes Disaster Recovery on OCI case study

Distributed Application Platform

Heterogeneous GPU Inference Orchestrator

ValidatedPython / TypeScriptFeatured projectPublic engineering project · Hosted CI and four-image pipeline verified 23 July 2026

A queue-based inference platform that routes vision work toward an Intel OpenVINO worker and language-model work toward an AMD Vulkan worker while keeping API state, model storage, metrics, and hardware-validation boundaries explicit.

Outcome: The latest public commit passed GitHub Actions for four API/queue contract tests, Python lint and compilation, the frontend build, Compose validation, and Kustomize rendering. A separate successful matrix built and published four container images. GPU execution, model provenance, throughput, multi-user security, and a live Kubernetes rollout remain outside the verified result.

Engineering detail and validation

Problem: Heterogeneous GPUs do not share one runtime, workload shape, or scheduling contract. A useful platform has to route jobs by capability, retain job state, expose progress and failure, isolate model artifacts from images, and avoid claiming hardware performance that hosted CI cannot prove.
Solution: A React dashboard submits work to a FastAPI gateway backed by PostgreSQL. Celery dispatches jobs through Redis to separate vision and LLM queues; the workers select OpenVINO, Vulkan, or documented CPU fallbacks. Prometheus and Grafana cover service signals, while Compose and Kustomize describe local and Kubernetes deployment paths.
Architecture: The control plane separates request handling, durable job state, queue dispatch, and status events from the device-specific data plane. Vision jobs target an Intel/OpenVINO worker, LLM jobs target an AMD/Vulkan worker, model files remain on runtime volumes, and metrics feed an operator dashboard.
Scope: Public learning and platform-engineering project. Verified evidence covers contracts, builds, configuration rendering, and image construction; it does not claim production service, GPU performance, or model quality.

Core capabilities

Routes vision and LLM jobs to separate Celery queues and worker contracts
Persists job state and exposes health, metrics, and real-time status events
Selects OpenVINO, Vulkan, or bounded CPU fallbacks without presenting them as equivalent performance
Keeps model weights on runtime volumes instead of embedding them in container layers
Provides Compose and Kustomize deployment descriptions with explicit Secret and GPU-node prerequisites

Validation evidence

Latest GitHub Actions CI run passed on 23 July 2026
Four hosted API and queue-routing tests passed; three live-cluster smoke tests remain opt-in and were not counted as hosted evidence
Ruff lint, Ruff formatting check, and Python compilation passed for service and test code
React and TypeScript frontend built from a clean npm installation
Docker Compose configuration and Kubernetes Kustomize rendering passed
A separate successful matrix built and pushed API, vision-worker, LLM-worker, and frontend images
The current CI audits the API dependency set; full vision and LLM dependency auditing remains incomplete

View public repository

Read Heterogeneous GPU Inference Orchestrator case study

Infrastructure Tool

Kubernetes Operations Audit

ValidatedPythonFeatured projectPublic engineering project · v0.1.0 local suite and GitHub Actions verified 23–24 July 2026

A typed, read-only Python CLI that audits Kubernetes workload, storage, networking, GitOps, and security signals and renders terminal, Markdown, HTML, and JSON reports.

Outcome: An operator can run one read-only scan, inspect a concise terminal result, and publish a sanitized report without converting unavailable integrations into a misleading clean state.

Engineering detail and validation

Problem: A growing Kubernetes environment needs a repeatable health review that separates operational issues from inventory, tolerates missing optional APIs, and never exposes Secret values.
Solution: The official Kubernetes Python client feeds fault-isolated checks for cluster, workload, storage, networking, GitOps, and security signals. Pydantic models keep Rich terminal, Jinja2 Markdown and HTML, and JSON output aligned.
Architecture: A small Kubernetes client adapter supplies isolated checks. Typed findings feed terminal, Markdown, HTML, and JSON renderers; configuration or API failures become explicit report findings.
Scope: Public engineering project at version 0.1.0. Published examples are sanitized; collection is read-only and point-in-time rather than a standing monitor.

Core capabilities

Audits node, workload, storage, networking, GitOps, certificate, external-secret, and security hygiene signals
Produces terminal, Markdown, HTML, and JSON reports from the same typed model
Continues remaining checks when one optional integration fails and records the collection warning
Reports Secret counts without retrieving Secret values

Validation evidence

Local package metadata identifies version 0.1.0
Fresh pytest run passed all 16 mocked cases in 0.21 seconds
Ruff lint passed and all 37 Python files matched Ruff formatting
Strict mypy reported no issues across 30 source files
The latest public GitHub Actions CI run completed successfully on 23 July 2026
Sanitized Markdown and JSON examples are included

View public repository

Read Kubernetes Operations Audit case study

Start with the strongest evidence

Prefer a shorter review?

The homepage selects four projects that best connect professional operations experience with platform engineering.

View featured work Download resume

Start with the strongest work. Explore the rest by domain.

Project results

Secure Always-On Git Platform

Core capabilities

Validation evidence

Hybrid-Cloud Kubernetes Disaster Recovery on OCI

Core capabilities

Validation evidence

Heterogeneous GPU Inference Orchestrator

Core capabilities

Validation evidence

Kubernetes Operations Audit

Core capabilities

Validation evidence

Prefer a shorter review?