One-click ML model deployment from GitHub URL to live AWS infrastructure

A self-service MLOps platform that eliminates manual server configuration. Enter a GitHub repo URL — the platform provisions an EC2 instance, installs Docker, configures NGINX as a reverse proxy, builds the Docker image, and streams real-time deployment progress to a React dashboard via WebSocket.

Platform Infrastructure (Terraform IaC — 10 modules):

• Networking — Custom VPC · Multi-AZ public/private/DB subnets · NAT Gateway
• Compute — ECS Fargate (Flask backend, serverless) · ECR (private container registry) · EC2 (ML app deployment target)
• Frontend — React SPA on S3 + CloudFront (global CDN, free HTTPS)
• Traffic — ALB with path-based routing (/api/* and /socket.io/* → ECS backend) + session stickiness for WebSocket continuity
• Data — RDS PostgreSQL 16 in isolated DB subnets
• Security — Layered security groups · IAM least-privilege · CloudFront origin restriction on ALB · no static credentials anywhere
• Secrets — AWS Secrets Manager for DB credentials, JWT secrets, and SSH keys — injected at ECS runtime via task definition

Application Pipeline (boto3 + Paramiko):

• 13-step automated pipeline: EC2 provisioning → SSH → Docker install → git clone → image build → container run → NGINX config → health check
• Real-time WebSocket deployment logs streamed to React dashboard
• JWT-secured REST API · SQLAlchemy + Alembic migrations · automatic EC2 cleanup on pipeline failure

⚡ Reduces a 30-minute manual EC2 setup to under 5 minutes — fully automated end to end

Production-grade Flask API on AWS — 100% Infrastructure as Code, from provisioning to observability

An end-to-end cloud engineering build: a Flask API on EC2 with every AWS resource — VPC, security groups, IAM roles, S3, CloudWatch — provisioned entirely through Terraform. Every push to main triggers a fully automated GitHub Actions pipeline: test → Docker build → push to GHCR → deploy to EC2 → health-check gate.

Highlights:

• Infrastructure as Code — Terraform-managed VPC, EC2, least-privilege IAM, S3, CloudWatch dashboard & alarms — zero manual console changes
• CI/CD — GitHub Actions, 2 jobs / 8 stages, tests gate every deployment, images published to GitHub Container Registry
• Security by default — non-root Docker container, NGINX security headers, encrypted + versioned S3, scoped IAM policies, no hardcoded credentials anywhere
• IaC security — Terraform configuration scanned with Checkov; selected policy findings were remediated and the configuration rescanned to verify the targeted controls passed
• Observability — CloudWatch dashboard (4 widgets), 3 metric alarms, 4 log streams (bootstrap, NGINX access/error, application)
• Load tested — k6 at 20 concurrent VUs: 0.00% error rate, 100% checks passed, 1,470 requests

⚙️ Documented trade-offs (SSH open for CI/CD, no HTTPS yet, single-instance) with the production fix for each — because a portfolio project should show what you'd change for real production, not pretend it's already there.

One application, evolved phase by phase — the same system growing the way real production infrastructure does

Instead of building disconnected mini-projects, VoteSecure takes a single full-stack voting platform (FastAPI + React + PostgreSQL + Redis) and evolves it through progressive infrastructure phases — each one built, intentionally broken, documented, and shared.

Completed phases:

• Phase 1 — Containerization ✅ — Dockerized frontend + backend, Compose orchestration, health-check-gated startup, persistent volumes
• Phase 2 — Reverse Proxy ✅ — NGINX as the single public entry point, WebSocket-aware routing for Socket.io, backend never exposed to the host
• Phase 3 — Continuous Integration ✅ — GitHub Actions 5-stage fail-fast pipeline (lint → frontend validation → backend image build → frontend image build → full-stack smoke test), validating pushes and pull requests to main

Real incidents, documented like production postmortems:

Six intentional failure simulations across Docker, NGINX, and GitHub Actions — covering dependency outages, service discovery, WebSocket degradation, broken builds, invalid runtime secrets, and a CI workflow that never triggered.

Each report includes the symptom, investigation, root cause, fix, verification, and the monitoring gap it exposed.

Read all six incident reports →

💡 The central lesson so far: a green health check or successful build does not prove the system works. Failures can exist in dependencies, network routing, runtime configuration, WebSocket upgrades, and even the CI trigger itself.

Up next: AWS deployment → monitoring & observability (Prometheus/Grafana) → container registry & CD → Kubernetes.

Following the build-in-public series on LinkedIn.