// case study

Capstone Phoenix

repo: adekolaemmanuel-hub/capstone-phoenix  ·  status: infrastructure destroyed post-review  ·  stack: Terraform · Ansible · k3s · Argo CD
01TERRAFORM
02ANSIBLE
03K3S
04ARGO CD
05TASKAPP

What it is

Capstone Phoenix is a production-style Kubernetes deployment of TaskApp, a React front end, Flask API, and PostgreSQL database, run on a self-managed k3s cluster on AWS. The goal wasn't just "get it running" — it was to reproduce the shape of a real production stack: infrastructure as code, GitOps delivery, automatic TLS, and resilience under load.

How it's built

Incident log

The debugging is the part most portfolios skip. Here's what actually went wrong, in the order it happened:

AWS account tier limits

Hit account-level resource ceilings mid-build, which meant sizing the cluster around what the account tier actually allowed rather than the original plan.

Private vs. public IP for k3s agents

Agent nodes were initially configured to join the cluster over the wrong IP class, which broke node-to-node communication until traced back to the k3s agent join configuration.

Environment variable naming mismatches

A silent mismatch between the env var names Terraform/Ansible set and what the Flask app expected caused failures that looked like application bugs but were actually infrastructure config drift.

Dynamic home IP

Working from a home connection with a non-static IP meant the AWS security group allowlist had to be updated repeatedly to keep SSH/admin access working.

Outcome

TaskApp ran live at a custom domain with automatic HTTPS, GitOps-driven deploys, and autoscaling in place. The infrastructure was torn down cleanly after review to avoid ongoing AWS costs — the code and configuration remain in the repo, reproducible from a single terraform apply.

← Back home