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
• 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 (3,546 / 3,546), p95 latency 417ms

⚙️ 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 — CI ✅ — GitHub Actions, 5-stage fail-fast pipeline (lint → frontend validation → backend build → frontend build → smoke test), PR-gated merges to main

Real incidents, documented like production postmortems:

• INC-001 — PostgreSQL container outage (Docker DNS vs. TCP connectivity)
• INC-002 — Service discovery failure (localhost vs. Docker internal DNS)
• INC-003 — NGINX WebSocket upgrade failure (silent fallback to long-polling)

💡 The learning driving this project: availability doesn't guarantee functionality. All three incidents passed basic health checks while the actual feature underneath was broken — that gap is what the incident reports exist to close.

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

Following the build-in-public series on LinkedIn.