Work

Systems in production, and the roles behind them. Every figure and case links to its full doc.

Architecture

FIG. 02 · NETWORK enterprise platform · terraform

Public front door, private compute

private vpc: no public ips usershttps public albshared front door privatelinkvpc endpoint service internal nlboptional acm tls fargateprivate tasks

The front door is public; the compute never is. HTTPS terminates at a shared ALB, PrivateLink carries traffic across the account boundary into a VPC with no public IPs, and an internal NLB fans out to Fargate. Packaged as a reusable Terraform module.

alb·privatelink·nlb·fargate·acm·terraform

full doc →

FIG. 03 · CI-CD built twice, independently · org infra + saas fleet

Pipelines that hold no credentials

pull requestreviewable diff terraform planoidc role · per-run human gateapprove to apply terraform applyshort-lived creds awstagged infra

No cloud keys exist anywhere in the pipeline. Every run assumes a short-lived IAM role via GitHub OIDC; plans post on the PR, applies wait for a human. Designed once for an org's shared infrastructure and again for a fleet of client sites, plus a guard job that fails loudly instead of letting a skipped run report green.

github actions·oidc·iam·terraform·reusable workflows

full doc →

FIG. 04 · INFRA multi-tenant saas · in production

One template, a fleet of sites

template repo4 design skins create-clientrepo · secrets · tier client repo ×ntemplate sync prs amplify + acmper-client terraform dns cutovercert-gated shared supabaserls · per-tenant jwt

Tenancy is enforced by the database, not the app. One template provisions each client site: repo, secrets, tiered features, Amplify + ACM via Terraform, DNS withheld until the certificate verifies. Every site shares one Postgres behind row-level security keyed by per-tenant JWTs; template updates fan out as reviewable PRs to the fleet.

astro·github actions·terraform·amplify·cloudflare dns·supabase rls

full doc →

FIG. 05 · OBSERVABILITY homelab · 222 days uptime

Monitoring with zero dependencies

proxmox apiread-only token tiered pollerpython stdlib only sse streamo(1) fan-out live dashboardmesh-only access

Poll at the rate the data actually changes. A dependency-free Python service polls the hypervisor at tiered intervals measured from real API behavior, and streams to the dashboard over SSE with constant fan-out cost. Read-only API role, bound to the WireGuard mesh only. The lab has zero WAN exposure.

proxmox·python stdlib·sse·tailscale·systemd

full doc →

FIG. 06 · INFRA seven production platforms · delivered

One root stack, nine wired children

nested stacks: deployed as one stack paramsper-build config root stackone deploy unit networkvpc edgecf+waf computeasg+alb dataaurora ×7 platformssame template

No child stack knows another's resource IDs. A root stack composes nine children (networking, identity, compute, search, and edge each in their own template) wired together through cross-stack outputs instead of copy-pasted identifiers. The same shape was re-cut across seven production platforms, from the full graph down to a single IAM-governance stack.

cloudformation·nested stacks·cloudfront·waf·cognito·iam

full doc →

FIG. 07 · NETWORK shared org network · in staging

One VPC per org, not per app

3 availability zones module librarygit ref pinned vpc moduleone module call public subnetalb + igw nat gatewayone per az private subnetapp + data workloadsecs · ec2 · rds

One network for the whole organization, not one per app. Public and private subnets split across all three zones, with NAT gateway creation left as a variable rather than a standing cost. The module is hand-rolled with object-typed ingress and egress rules and published for git-source consumption, so a project pins a ref instead of copying the file.

terraform·vpc·nat gateway·s3 backend

full doc →

Notable work

CASE 01 · ALTERNETA sole infra author · 2025-06 → 2025-07

None of the apps, all of the infrastructure

Sole infrastructure author for a small org whose app roadmap was shelved before launch. I built the ground the apps were meant to stand on: a shared 3-AZ VPC, an in-house Terraform module library, and OIDC-based GitHub Actions pipelines that have never held a stored AWS credential. Written, validated, and dry-run against a real account; no application ever deployed on it.

infra·network·ci-cd

CASE 02 · RESTU ILAHI sole infrastructure & delivery author · 2025-12 → 2026-07

A one-off wedding site, refactored into a product

A solo-built, multi-tenant wedding-invitation platform (deliberately hand-built per client rather than self-serve SaaS) with four templated site designs, a shared row-level-secured Postgres layer, and a dispatched pipeline that provisions a new tenant end to end on Terraform and GitHub Actions.

ci-cd·infra·app-delivery

CASE 03 · A GLOBAL AUTOMOTIVE MANUFACTURER infrastructure engineer · 2025-05 → 2026-06

The same thin stack, poured three times

Thin, versioned Terraform stacks consuming shared reference-architecture modules to run three internal application platforms on ECS Fargate with RDS PostgreSQL 17 behind RDS Proxy.

infra·ci-cd

CASE 04 · A GLOBAL AUTOMOTIVE MANUFACTURER platform engineer (networking) · 2026-02 → 2026-07

Public ingress, without public compute

A hub-and-spoke landing-zone network: a public ALB fronting private ECS Fargate services over PrivateLink, plus a hardened SFTP-to-S3 bridge for external file exchange.

network·infra

CASE 05 · A GLOBAL AUTOMOTIVE MANUFACTURER devops engineer (supporting) · 2025-07 → 2026-02

The plumbing nobody notices until it breaks

Focused containerization, delivery-pipeline, and Helm chart contributions to two larger platform teams' systems: a .NET retail-reporting app and a Kubernetes microservice platform.

ci-cd·app-delivery

CASE 06 · AN AWS-PARTNER SOFTWARE HOUSE sole developer (internship) · 2024-02 → 2024-05

What shipped was smaller than what I built

A document repository for researchers, built solo and entirely through the AWS console, including an asynchronous text-extraction pipeline (SQS · Lambda · Textract) I designed and then deliberately cut for cost, folding extraction back into the application once the expected load didn't justify a serverless fan-out. The same platform was rebuilt as infrastructure-as-code in the role that followed.

infra·app-delivery

CASE 07 · AN AWS-PARTNER SOFTWARE HOUSE infrastructure engineer · 2024-07 → 2025-02

The client changes, the skeleton doesn't

Infrastructure engineer across seven production AWS platforms built for a software house's clients. Sole author of most, and the provisioning engineer on the largest: a ministry's AWS landing zone of three workload accounts, whose design came from an AWS principal architect. One nested-stack CloudFormation pattern, re-cut per platform, from a full nine-stack web build down to a single IAM governance stack.

infra·network