500. Frontend loaded.
GET /api/auth/me worked (JWT, no DB call). Redis rate limiting active. Container status
showed all containers "Up" — monitoring would have shown green while users saw 500s.// Projects
What I've Built
Three systems, each built to understand something specific about infrastructure, delivery, and failure.
01
ML Deployment Platform
How do you turn a 30-minute manual AWS deployment workflow into a repeatable, automated platform?
~30 min
manual AWS console
13 steps
orchestration pipeline
<5 min
automated end-to-end
AWS EC2
deployment target
DeployML — self-service deployment dashboard
Deployment in progress — real-time status via Socket.IO
Architecture note
A Terraform-based production architecture (CloudFront → ALB → ECS Fargate → RDS) is designed
and documented on the feature/aws-production branch. The current deployed
orchestration runs against EC2 using boto3 + Paramiko. The IaC design represents the next evolution, not
the current deployment.
A self-service platform that accepts a GitHub URL and deploys a live ML application on AWS EC2 through a 13-step orchestration pipeline. The backend coordinates EC2 provisioning, Docker deployment, NGINX configuration, and real-time status streaming over Socket.IO — all triggered by a single form submission.
The front end was built with React 19 + Vite. The orchestration layer uses boto3 for AWS provisioning and Paramiko for SSH-based remote execution. A PostgreSQL database tracks deployments and instance state.
Orchestration pipeline
GitHub URL submitted
Flask API receives request, writes to PostgreSQL
EC2 provisioned via boto3
Security groups, key pair, instance launched
SSH connection via Paramiko
Docker + Git installed, repo cloned
Container built and started
docker build → docker run on EC2
Live URL returned
Status streamed to dashboard via Socket.IO
02
AWS DevOps Platform
What does a complete cloud-to-production engineering path look like — infrastructure, delivery, observability, and reliability testing in one project?
0.00%
k6 error rate
1,470
requests sent
20
virtual users
100%
checks passed
End-to-end cloud engineering: Terraform provisions the AWS stack from scratch. GitHub Actions handles build, test, push to GHCR, and SSH-based EC2 deployment. CloudWatch provides dashboards, alarms, log streams, and custom metrics. k6 validates reliability under load before the project was considered complete.
CI/CD pipeline — git push to live
git push → GitHub Actions triggers
Python tests pass
Docker build → push to GHCR
SSH → EC2 pulls image, restarts container
Health check gate — deployment verified
NGINX → Gunicorn → Flask serving requests
AWS infrastructure — Terraform-provisioned stack
IaC security validation
Terraform configuration was scanned with Checkov to identify policy violations. Selected findings were remediated and the configuration was rescanned to verify that the targeted controls passed.
Engineering trade-off
Current: SSH-based deployment from GitHub Actions. Simple, transparent, works for this
scope.
Known limitation: SSH keys in CI, no HTTPS,
single-instance.
Production path: AWS SSM Session Manager, ALB + ACM certificate,
Auto Scaling Group.
03
VoteSecure — DevOps Journey
How do you learn DevOps from first principles — not from tutorials, but by deliberately breaking a real system and documenting what happens?
A full-stack voting platform built as a progressive DevOps project — containerized, proxied, and CI-validated across three phases. The platform uses FastAPI + React 18, PostgreSQL with AES-256 ballot encryption, Redis for rate limiting and JWT blacklisting, and Socket.IO for real-time vote streaming.
The engineering differentiator: six production failures were simulated on purpose. Each incident was reproduced, investigated in depth, documented with root cause and remediation, and used to improve the system. These are not hypothetical exercises — they are full incident reports based on real log output, real error messages, and real recovery steps.
PHASE 1
Containerization
Completed
PHASE 2
Reverse Proxy
Completed
PHASE 3
CI Pipeline
Completed
PHASE 4
AWS Deployment
Upcoming
Architecture — Browser → NGINX → FastAPI → PostgreSQL + Redis
6 documented incident reports — click to
expand
INC-001
PostgreSQL container stopped — DNS deregistered, hostname unresolvable
Resolved
Symptom
All DB-dependent endpoints →
Root cause
When a Docker container stops, it deregisters from the internal bridge
network DNS. The hostname
postgres became unresolvable — not "connection refused" but "no
address associated with hostname." The backend never attempts TCP; DNS fails first.Lesson
Docker DNS fails before TCP. Static health checks that return
200 OK without testing the database are liveness probes — not readiness probes. A green
health endpoint during a DB outage is actively misleading.
INC-002
DB_HOST=localhost — total outage with zero infrastructure failure
Resolved
Symptom
Backend exited at startup — never accepted a single request. NGINX
returned
502 Bad Gateway on every API call. PostgreSQL, Redis, NGINX, and frontend were
all fully healthy. Infrastructure was green; application was dead.Root cause
DB_HOST=localhost set instead of
DB_HOST=postgres. Inside a Docker container, localhost resolves to the
container's own loopback (127.0.0.1). PostgreSQL was running in a separate network
namespace, reachable only by its service name. DNS succeeded; TCP was refused. Backend startup event
failed; Uvicorn exited.Lesson
All infrastructure healthy + application down = configuration error.
502 means dead upstream (check container state). 500 means broken upstream
(check application logs). The error code is the first debugging signal. --force-recreate
is required for env var changes — restart does not apply them.
INC-003
NGINX stripped WebSocket Upgrade headers — real-time feature silently
broken
Resolved
Symptom
Live Results page showed no real-time vote updates. All other features
worked. No 500 errors. Dashboards green. Users would only discover the failure by noticing vote counts
not updating — no alert would catch this.
Root cause
NGINX strips hop-by-hop headers (including
Upgrade and
Connection) before forwarding requests upstream. The browser sent a WebSocket upgrade
request; NGINX removed the headers; the backend received a plain HTTP request and refused the upgrade.
Fix: proxy_set_header Upgrade $http_upgrade; and proxy_http_version 1.1; in
NGINX config.Lesson
Silent partial failures are harder than total outages. Dashboards
stayed green. The feature worked in local dev (no NGINX). Production added a proxy layer that broke
one specific protocol. Test the full stack — not just the application in isolation.
INC-004
CI build failed — Dockerfile error local cache had hidden for weeks
Resolved
Symptom
CI pipeline failed at the Docker build step. The same
docker build succeeded locally. The PR was blocked from merging.Root cause
Local Docker build used a cached layer containing a previously valid
dependency. CI builds from scratch with no cache — it hit an actual package resolution error that
local cache had masked. The Dockerfile had a latent defect that only showed up in a clean build
environment.
Lesson
CI is a clean-room environment — it proves your build is reproducible,
not just that it worked on your machine. "Works locally" is not evidence of a correct Dockerfile.
Periodically build with
--no-cache in local dev to find hidden dependency issues before
CI does.
INC-005
Smoke test failed — wrong GitHub Secret name, silent misconfiguration
Resolved
Symptom
CI smoke test step failed with an authentication error. The application
code and Docker build were both correct. The pipeline passed tests and build, then failed at smoke
test.
Root cause
The workflow referenced a GitHub Secret by an incorrect name. GitHub
does not error on missing secrets — it silently injects an empty string. The application received an
empty database password, failed to authenticate, and the smoke test correctly detected the failure.
Lesson
Secret name mismatches are invisible until runtime. GitHub won't warn
you. Add secret validation at pipeline startup — fail fast with a clear message if a required secret
is empty, rather than letting downstream steps fail with cryptic errors.
INC-006
Pipeline never triggered — wrong branch in workflow trigger
Resolved
Symptom
Code pushed. PR opened. Zero CI workflow runs appeared. No red status,
no yellow status — nothing. The PR showed as ready to merge with no quality gate. Any broken code
could have been merged without detection.
Root cause
Workflow trigger changed from
branches: [main] to
branches: [production]. production does not exist as a branch. The YAML is
syntactically valid — GitHub parses it without error. The trigger simply never fires because no PR
ever targets a production branch.Lesson
A pipeline that fails tells you something is wrong. A pipeline that
doesn't run tells you nothing — and you won't notice it isn't running. Validate CI trigger
configuration on every workflow change. Require status checks in branch protection rules — a missing
check should be as alarming as a failing one.