How carlcode-dev/verdant works
Verdant is a self-hosted Kubernetes deployment for a small Incident Logger API. Its documented path is Terraform-provisioned EC2 running k3s, which runs the containerized Flask API and exposes it through a NodePort service. API requests can check health, create incidents, or list incidents held in an in-memory collection. The README documents the infrastructure and deployment relationships; sampled app.py shows the API’s request and storage behavior. Other implementation details are not inferred from unsampled files.
Main entry points: service.yaml NodePort Service · app.py Flask API · deployment.yaml Kubernetes Deployment · main.tf Terraform
Components 13
Infrastructure
- Terraform
main.tf - AWS EC2
Cluster Runtime
- k3s Cluster
- Kubernetes Deployment
deployment.yaml - Verdant Pod
deployment.yaml - NodePort Service
service.yaml
Incident API
- Flask API
app.py - Health Check
app.py - Incident Routes
app.py - Incident Collection
app.py
Other components
- Operator
- Docker Hub
- Internet Client
Connections 17
- Operator → Terraform: runs apply
README.md - Terraform → AWS EC2: provisions
README.md - AWS EC2 → k3s Cluster: runs
README.md - Docker Hub → k3s Cluster: image pulled by
README.md - Operator → Kubernetes Deployment: applies manifest
README.md - Operator → NodePort Service: applies manifest
README.md - k3s Cluster → Kubernetes Deployment: runs workload
README.md - Kubernetes Deployment → Verdant Pod: manages
README.md - k3s Cluster → NodePort Service: runs service
README.md - NodePort Service → Internet Client: exposes API
README.md - NodePort Service → Verdant Pod: routes traffic
README.md - Verdant Pod → Flask API: runs
README.md - Internet Client → Health Check: requests health
README.md - Internet Client → Incident Routes: requests incidents
app.py - Flask API → Health Check: dispatches
app.py - Flask API → Incident Routes: dispatches
app.py - Incident Routes → Incident Collection: writes or reads
app.py