Reliable cloud platforms.
Better engineering workflows.

Challenge: Different engineering tasks need repeatable tools and clear data ownership. Stopping workspace compute should preserve project files, while temporary app/test environments need an independent cleanup lifecycle.

Approach: Extended the existing Coder Community deployment with seven versioned use-case templates on Kubernetes and bundled synthetic projects. Recorded live notebook, tooling, pipeline, telemetry and offline task-boundary checks, including basic file retention across stop/start. AI Service Development and QA Automation have published builds and offline checks while their live evidence is reconciled. The separate app/test service remains proposed.

Recorded outcome: Seven use-case templates published for a one-user Coder pilot. Live workflows and one basic stop/start check are recorded for five; recovery and multi-user qualification remain open.

My role: Platform design and pilot operations

• Coder Community One-user pilot Remote-workspace control plane for one trusted user, with seven published use-case templates. Full service qualification remains open. Status: One-user pilot.
• Kubernetes Current workspace backend Current backend for seven published use-case templates. Live workflows and one stop/start file-retention check are recorded for five; recovery and multi-user qualification remain open. Status: Current workspace backend.
• PostgreSQL Connected; restore untested External Coder database; connectivity and migrations are verified, while backup restore is untested. Status: Connected; restore untested.
• Terraform Seven use-case templates published Seven versioned use-case templates are published. AI Service Development and QA Automation have offline checks while their live acceptance records are reconciled. Status: Seven use-case templates published.
• Prometheus Scrape previously verified A Coder control-plane metrics scrape was previously verified. Comprehensive workspace observability remains separate work. Status: Scrape previously verified.

Challenge: Add useful workload logs without replacing existing monitoring or implying fleet-wide coverage.

Approach: Recorded real stdout/stderr from one namespace- and label-selected Kubernetes demo workload through Kubernetes Grafana Alloy, a TLS/Basic Auth Caddy push gateway, dedicated 24-hour Loki, and authenticated Grafana. A separate backend Alloy file canary has exercised the log path; periodic freshness is not established. Existing infrastructure Prometheus/Grafana remains separate, and the log viewer has only a Loki datasource. Selected NAS management and hosted-service endpoints now have TCP reachability checks through the existing metrics stack; these measure connection availability, not storage or application health. The UI uses a separate Caddy proxy and supervised restricted SSH forward; its browser-to-Caddy LAN hop is unencrypted HTTP.

Recorded outcome: Recorded partial deployment for one workload. Loki is single-instance with 24-hour retention and no HA; this is not comprehensive monitoring. AWS is a planned, unprovisioned PoC; Azure is reference-only; application tracing remains future work. Core pipeline records reviewed 20 October 2026; NAS endpoint checks and coverage reviewed 21 October 2026. These are dated observations, not a continuous uptime claim.

My role: Architecture, integration, and staged delivery

• Grafana Alloy Current · Homelab Telemetry collector for receiving, processing, and forwarding observability signals. Status: Current · Homelab.
• Loki Current · Homelab Log aggregation system designed for querying application and infrastructure logs. Status: Current · Homelab.
• Prometheus Existing · separate metrics Metrics collection and time-series database commonly used for alerting and monitoring. Status: Existing · separate metrics.
• AWS Planned Planned cloud target in this architecture study; not deployed. Status: Planned.
• Azure Reference Reference architecture only; this Azure design is not deployed. Status: Reference.
• OpenTelemetry Future Future application tracing; the current design does not collect application traces. Status: Future.

Challenge: When alerts fire, operational knowledge is scattered across runbooks, RCAs, dashboards, and chat history. AI-assisted triage without citations drifts into weakly grounded recommendations.

Approach: Built HARP to turn alerts and Git-tracked operational knowledge into cited evidence packs. AI clients receive read-only context through MCP, while workflow state and remediation approval remain under human control. Under the hood: BM25 + hybrid search, optional OpenRAG semantic retrieval, synthetic monitoring signal paths, and Nero-Camp for approval state.

Recorded outcome: A homelab prototype that assembles cited evidence through read-only MCP, with deterministic BM25 fallback and human approval retained for remediation.

My role: Architecture, build, integration, and reliability design

Recorded project reference: MCP 0.5.0

• H HARP Evidence-first reliability assistant that assembles cited operational context for human review.
• MCP Model Context Protocol connects AI clients to explicitly scoped tools and context.
• OpenRAG Retrieval-augmented generation service for finding relevant source material to ground answers.
• BM25 Lexical ranking algorithm that scores documents by matching query terms.
• Nero-Camp Project-specific infrastructure component in the HARP and homelab environment.

Challenge: Engineering desktops need a private access path and a recovery method that can be tested without disrupting other workloads.

Approach: Cloned an existing Ubuntu cloud-init template, configured XFCE and xrdp, and restricted desktop access to Tailscale. Rehearsed base-VM backup and an isolated restore using synthetic data.

Recorded outcome: Proxmox pilot built, private RDP reachability verified, and single-user use reported by the owner. An isolated base-VM restore passed; session resilience and independent file-version recovery remain open.

My role: Platform design, pilot build, access configuration and recovery testing

• Proxmox Virtualization platform for managing virtual machines and Linux containers.
• Ubuntu Linux operating system used by the virtual desktop pilot.
• Tailscale Private network overlay used to reach the homelab desktop remotely.
• xrdp Remote Desktop Protocol server used to access the Ubuntu desktop.
• AWS Planned Planned cloud target in this architecture study; not deployed. Status: Planned.
• Azure Reference Reference architecture only; this Azure design is not deployed. Status: Reference.

Challenge: Kubernetes incidents often start with scattered context across logs, alerts, and cluster state, which slows down first-pass diagnosis.

Approach: Built a containerized Python/FastAPI workflow to structure incident context for Kubernetes triage. AWS Bedrock, Lambda, API Gateway, and EKS describe a proposed deployment path, not a production service.

Recorded outcome: A containerized prototype workflow that turns incident context into a first-pass summary; no EKS integration has been validated, and AWS deployment remains planned.

My role: Prototype design and implementation

• Docker Docker is used in this project's technology stack.
• Kubernetes Kubernetes is used in this project's technology stack.
• Python Python is used in this project's technology stack.
• FastAPI FastAPI is used in this project's technology stack.

Challenge: Teams want AI-assisted document search without pushing sensitive material into a broad public SaaS workflow.

Approach: Set up a private RAG stack with vector search, reranking, and cited answers on self-hosted infrastructure, while using cloud LLM services selectively.

Recorded outcome: A private retrieval environment for testing vector search, reranking, cited answers, and self-hosted operations.

My role: Deployment, integration, and system design

• OpenRAG Retrieval-augmented generation service for finding relevant source material to ground answers.
• Milvus Vector database for storing and searching embeddings used in semantic retrieval.
• LiteLLM Model gateway that provides a common interface for routing requests to language-model providers.
• Bedrock AWS managed service for accessing foundation models through an API.
• Docker Compose Tool for defining and running a multi-container application environment.

Challenge: Portfolio systems are hard to evaluate if they only exist as diagrams or code snippets.

Approach: Built a small self-hosted platform with Proxmox, Kubernetes, storage, and internal tooling so projects can be deployed and operated end to end.

Recorded outcome: A documented substrate for Kubernetes and data services, with explicit network boundaries and GitOps delivery.

My role: Design and operations

• kubeadm Kubernetes tool for bootstrapping and managing cluster control-plane nodes.
• Proxmox Virtualization platform for managing virtual machines and Linux containers.
• GitOps Delivery approach where version-controlled desired state drives infrastructure changes.
• Cilium Kubernetes networking and security platform built on eBPF, with network observability features.

Challenge: Engineering teams need actionable spend insights, not raw billing data — and the infrastructure itself should demonstrate cost awareness.

Approach: Modeled V1 with ECS Fargate + ALB at about $27/month and V2 with EC2 t4g.nano + Caddy at about $6/month. The estimates represent about 78% lower modeled infrastructure cost; both options use the same Lambda + Athena pipeline and GitLab CI lifecycle assumptions.

Recorded outcome: Two modeled deployment designs make the cost and operational trade-offs explicit; savings are estimates, not measured production spend.

My role: FinOps engineer

Recorded project reference: ~78% · ~$27 → ~$6/month

• ECS Fargate Serverless compute option for running ECS containers without managing EC2 hosts.
• EC2 AWS virtual machine compute for running workloads on configurable instances.
• Athena Serverless SQL query service for analyzing data stored in Amazon S3.
• Lambda AWS serverless compute for running functions in response to events or requests.
• Terraform Infrastructure-as-code tool for defining and provisioning cloud resources.

Challenge: Browser and operating-system speech voices vary, making pronunciation inconsistent for language learners.

Approach: Built a static-first learning SPA with reviewed lesson data, deterministic audio manifests, Amazon Polly generation, normal/slow MP3s, client-side progress, and accessible playback controls.

Recorded outcome: A static-first Dutch practice app with pre-generated audio; ordinary playback has no runtime cloud dependency.

My role: Product design, architecture, integration, and release engineering

Recorded project reference: Vite · Laura Neural nl-NL · 406 scoped MP3s

• Vite Frontend development server and build tool for modern web applications.
• Amazon Polly Text-to-speech service that generates spoken audio from text.
• Caddy Web server and reverse proxy with automatic HTTPS support.
• Static-first Site architecture that serves prebuilt pages by default and adds dynamic behavior only where needed.

Challenge: Infrastructure requests can move too quickly from a short brief to an assumed design. Constraints, unresolved questions, and the human decision need to stay visible before anyone treats a plan as ready to build.

Approach: Built a LangGraph workflow around two fixed synthetic homelab patterns: a VM with containers and a single-server K3s design. Deterministic rules validate the request, stale reviews clear when inputs change, and approval generates a five-file pack with a manifest. SQLite stores the business decision record separately from workflow checkpoints.

Recorded outcome: The workbench documents a plan for two fixed synthetic patterns and does not provision infrastructure.

My role: Workflow design, implementation, and integration

• Python Python is used in this project's technology stack.
• LangGraph LangGraph is used in this project's technology stack.
• SQLite SQLite is used in this project's technology stack.
• Human approval Human approval is used in this project's technology stack.
• Synthetic validation Synthetic validation is used in this project's technology stack.