docs(ansible): document caddy, fail2ban, unattended upgrades

.gitignore

@@ -1,6 +1,11 @@
 ### Ansible ###
 *.retry
 
+# ansible vault pass
+.vault_pass.*
+.vault_pass
+*.vault_pass
+
 ### Terraform ###
 **/.terraform/*
 **/terraform.tfstate

IAAS.md

@@ -0,0 +1,176 @@
+## Summary
+
+Your setup is **primarily IaaS**, with some **PaaS-like behavior** that *you* are building yourself. You consume **SaaS** only for external tooling (e.g. GitHub). This is ideal for learning DevOps end-to-end.
+
+---
+
+## Your current stack, mapped to IaaS / PaaS / SaaS
+
+![Image](https://miro.medium.com/1%2Ax4TscxA6uaN3asAreNg6yw.png)
+
+![Image](https://cdn.prod.website-files.com/65a790f0493b6806e60d6e21/6662b78dc707238ead7be590_64dca66820aece818c886638_Navigating%2520the%2520AWS%2520Cloud%2520Stack.png)
+
+![Image](https://sp-ao.shortpixel.ai/client/to_webp%2Cq_glossy%2Cret_img/https%3A//www.wowza.com/uploads/blog/wowza-on-premises-cloud-continuum-630x417.png)
+
+### 1. Infrastructure layer → **IaaS**
+
+**Terraform + Linode**
+
+What you control:
+
+* Virtual machines
+* Private networking
+* Firewalls
+* Public vs private IPs
+
+What the provider controls:
+
+* Physical servers
+* Data center
+* Hypervisor
+
+**Classification:** ✅ **IaaS**
+
+This is the foundation. Everything else runs *on top* of this.
+
+---
+
+### 2. Server configuration → **Still IaaS**
+
+**Ansible**
+
+What you manage:
+
+* Users, SSH hardening
+* Docker installation
+* Fail2ban
+* Node Exporter
+* System updates
+
+Important insight:
+
+> Configuration management does **not** move you out of IaaS.
+
+You are still managing:
+
+* The OS
+* Security
+* Services
+* Patching
+
+**Classification:** ✅ **IaaS (advanced, well-automated)**
+
+---
+
+### 3. Application runtime → **Self-built PaaS**
+
+**Docker + Gunicorn + env vars**
+
+You’ve created:
+
+* A standard runtime
+* A repeatable deployment model
+* Environment-based configuration
+* Health endpoints
+* Metrics
+
+But:
+
+* You still manage the host
+* You still manage Docker
+* You still manage upgrades and failures
+
+This is the key DevOps insight:
+
+> You are **building a PaaS on top of IaaS**.
+
+**Classification:**
+
+* Conceptually → **PaaS**
+* Practically → **IaaS with a platform layer**
+
+This is exactly how many real platforms started (Heroku included).
+
+---
+
+### 4. CI/CD & tooling → **SaaS**
+
+**GitHub, GitHub Actions**
+
+What you *don’t* manage:
+
+* Build servers
+* Runners
+* Scaling
+* Availability
+
+You just:
+
+* Push code
+* Configure workflows
+* Consume the service
+
+**Classification:** ✅ **SaaS**
+
+---
+
+## Responsibility breakdown (your exact setup)
+
+| Layer             | Example                 | Model                  |
+| ----------------- | ----------------------- | ---------------------- |
+| Hardware          | Linode data center      | SaaS (hidden from you) |
+| VM / Network      | Terraform               | IaaS                   |
+| OS & Security     | Ansible                 | IaaS                   |
+| Container runtime | Docker                  | IaaS                   |
+| App platform      | Your Docker conventions | DIY PaaS               |
+| App code          | Flask / Gunicorn        | PaaS responsibility    |
+| CI/CD             | GitHub Actions          | SaaS                   |
+| Monitoring UI     | Grafana Cloud (if used) | SaaS                   |
+
+---
+
+## Why this is an excellent DevOps learning path
+
+You are learning **all responsibility boundaries**, not just one:
+
+* **IaaS** → networking, firewalls, SSH, Linux
+* **PaaS concepts** → runtime standardization, config via env vars
+* **SaaS consumption** → CI/CD, observability platforms
+
+Many DevOps engineers:
+
+* Use PaaS without understanding IaaS
+* Or manage IaaS without understanding platform design
+
+You’re doing **both**, in the correct order.
+
+---
+
+## Real-world analogy (extended)
+
+* **Linode + Terraform** → You bought land
+* **Ansible** → You built the house and utilities
+* **Docker runtime** → You standardized apartments
+* **Your app** → Tenants move in
+* **GitHub Actions** → External cleaning & maintenance service
+
+---
+
+## What your *next step* could be (optional)
+
+If you want to *move slightly toward PaaS without losing learning value*:
+
+* Add **automatic app restarts**
+* Add **zero-downtime deploys**
+* Add **service discovery / reverse proxy rules**
+* Treat each app as cattle, not pets
+
+That would make your setup:
+
+> **A minimal, production-style PaaS built on IaaS**
+
+If you want, next we can:
+
+* Redraw this as a **single architecture diagram**
+* Or map this directly to **AWS equivalents** (EC2, ECS, EKS, Elastic Beanstalk)
+