I build the infrastructure and the pipelines that let a team ship without breaking production.

TaskFlow: a task management platform where nobody touches a server

Sole engineer. 10 weeks.

Most teams lose days to deployments: someone signs in to a server, pulls an image, restarts a container, and hopes. TaskFlow removes that person from the loop.

6 gates before anything reaches production. Lint, unit tests, build, Trivy scan, integration tests, publish. The scan blocks on CRITICAL and HIGH, so a bad image fails the build instead of landing in the registry. One run stopped on 6 high-severity findings, which I traced to npm's own dependencies in the Node base image and documented against each CVE with a review date.

No AWS credentials to leak. GitHub Actions signs in through OIDC and gets credentials that expire with the job. Every pod holds its own scoped IRSA role, 6 in total, and secrets sync from SSM hourly through External Secrets Operator. Port 22 is closed, deploys run through SSM Session Manager, and every session lands in CloudTrail.

CI never writes to Git. ArgoCD Image Updater watches ECR and promotes the SHA-tagged image itself, so branch protection on main holds with no bypass and every running container traces back to its commit.

The cluster corrects itself. 3 nodes across 2 availability zones, HPA scaling 2 to 5 replicas, PodDisruptionBudgets holding 1 replica up through maintenance, NetworkPolicies limiting the backend to frontend pods and ALB health checks. ArgoCD reverts manual drift within a sync cycle.

Metrics and logs from day one. Prometheus and Grafana for cluster and per-pod metrics, Fluent Bit shipping every container log to CloudWatch, all of it provisioned by Terraform rather than installed by hand.

3 things that broke. ECR returned 403 after OIDC succeeded, so authentication passed and authorization failed: I added the 2 actions buildx needs to check existing layers. Pods couldn't reach RDS because the VPC CNI gives pods their own IPs rather than the node's, so I widened the security group rule to the pod CIDR. ArgoCD was silently applying only namespace.yaml until I set directory.recurse and the other 13 manifests appeared.

Cluster torn down for cost. The live demo runs the same images on 1 EC2 instance, and one terraform apply rebuilds the platform.

PulseOps: incident management for multiple organisations, with tenant isolation proven by a test

Live at pulseops-app.online.

When an incident ends, most teams lose the next hour reconstructing it: who was paged, when it was acknowledged, what actually fixed it. PulseOps writes that record as it happens. Declare, tag severity, track on a live timer, and on resolve a blameless postmortem generates itself, pre-filled with the real timeline and response times.

Isolation proven, not assumed. Every organisation's incidents sit in one database. A test asks for another organisation's incident by its exact record ID and expects a 404, since a 403 would confirm the record exists. It is asserted on read, transition and delete, and runs with 28 others on every push.

The isolation sits in the query. Auth verifies the token and extracts the organisation, then every query runs scoped to it. No code path reaches a row without one.

2 pipelines, 2 identities, 0 stored credentials. Terraform assumes an infrastructure role, the deploy workflow a narrower one. Both through OIDC. JWT secrets and the database password live in SSM.

What broke. Terraform and the deploy pipeline were both authoritative over which image version was running. Nothing had failed yet, but the next routine infrastructure change would have rolled back a working deploy with no error and no alert. I split ownership so Terraform controls the service and the pipeline controls the image.

Terraform throughout: a VPC across 2 availability zones, RDS PostgreSQL and Redis in private subnets, ECS on EC2, ECR scanning on push. Every merge tags the image with its commit SHA and rolls out a new task revision. HTTPS went on after launch, on live infrastructure, with no downtime.

I also run its customers. 8 accounts in HubSpot on this platform: onboarding, health scoring, an escalation after our own outage, a quarterly business review and a $65,000 expansion. Read the customer success case study

Banking platform: the infrastructure 3 teams deployed onto

Infrastructure team lead, 23-engineer build. April to May 2026.

Pod 13 shipped a 3-tier banking application: React frontend, a REST API handling auth, accounts and transactions, MySQL behind it. Frontend and backend teams owned their services. I led the 7-person infrastructure team and owned everything those services ran on.

45 AWS resources, none created in the console. A VPC with 6 subnets across 2 availability zones split into public, private and database tiers, an EKS 1.32 cluster scaling 2 to 6 nodes, RDS MySQL with no public endpoint, Route53 and ECR. State in S3.

Delivery ran through the pipeline. A pull request runs fmt, validate and plan so the team reviews the diff; a merge runs apply. ArgoCD syncs both services onto the cluster behind nginx ingress, with cert-manager issuing Let's Encrypt certificates for 3 subdomains.

2 things that broke. The S3 bucket holding Terraform state was deleted, leaving every live resource untracked including a running EKS cluster: I recreated the bucket, restored state and turned on versioning so it couldn't happen twice. Then the backend team's pods couldn't reach the database, and their credentials were fine: the RDS security group had no rule admitting the node group on 3306, so I added it.

Monitoring and incident response on AWS EC2

Monitoring that has never fired is a guess. I broke things on purpose to find out whether mine worked.

4 incidents, every one inside SLA. Nginx down, CPU at 95%, disk past 80%, and an HTTP 502 caught by a synthetic check. Datadog detected each in 1 to 11 minutes, fixes took 3 to 43.

Every alert carries its runbook. The Slack message holds the checks to run, the remediation script path and a link to the runbook, so whoever is on call does not start by working out where to start. The synthetic check also blocks the pipeline, so a deploy cannot land on a service that is already broken.

The repeatable fix runs itself. A nightly cron job clears disk at 02:00 and logs every run, so the most common failure on this server never needs a human. The CPU script sits alongside it, scoped to this lab: in production a scheduled kill of the top process would eventually take out work that was doing its job, so it would need to target a known runaway process or page someone instead.

What broke. While working the disk incident I found the alert was watching the wrong disk, so it would have stayed silent through the exact failure it was written for. I pointed it at the right one and re-ran the drill to confirm.

Distributed inference on AWS: a language model across 3 machines

Built as a take-home for an internship application.

Running a model on one box is easy. The work is splitting it across machines that have to find each other, stay connected, and keep the model off the public internet.

1 machine reachable from outside. Nginx takes requests on port 80 on a public host. Both workers sit in a private subnet with no inbound route, reaching out through NAT only, and talk to the engine over WebSocket on the internal network.

Sized per workload. The caller worker runs TypeScript on a t3.small; only the inference worker needs a t3.medium, because only it holds the model. Terraform throughout, one compose file per machine, so the reviewer could rebuild all 3 machines from the repo.