# Infrastructure Builds — SnS Network Solutions

Actionable infrastructure designs, categorized by the SNS entity that would deliver
each type of work to a client (or internally). Every design defaults to **FOSS** tooling
(≥80% open-source) and uses our existing provider footprint.

## Principles

1. **FOSS-first (80%+ rule).** Prefer open-source over proprietary. Exceptions: Google
   Workspace (mail, calendar, chat, sheets) and AWS-managed services where the FOSS
   equivalent adds unacceptable ops burden.
2. **Proxmox is the hypervisor.** All on-prem VMs and containers run on Proxmox VE.
3. **Automation over clickops.** Ansible for config management. Gitea Actions / KESTRA
   for CI/CD. Infrastructure-as-code where possible.
4. **Security by default.** WireGuard/Tailscale for overlay networking. Fail2ban + UFW
   at every edge. TLS everywhere. Least-privilege.
5. **Simple until proven insufficient.** One VM beats a Kubernetes cluster when you have
   one app to run. Scale up only when the ceiling is hit.
6. **Entity separation.** Each design is tagged to the SNS entity that owns it. Work
   doesn't bleed across entities.

## Provider Inventory

| Provider | Role | Notes |
|----------|------|-------|
| **Proxmox (on-prem)** | Primary hypervisor | KVM VMs + LXC containers. Home lab → client deployments |
| **Linode (Akamai)** | Edge / jump host / light VPS | `172.238.163.85` — current bastion + Tailscale relay |
| **Racknerd** | Cheap dedicated/VPS for non-critical workloads | `racknerd1` 172.245.72.108, `racknerd2` 192.3.165.113 |
| **AWS** | Enterprise cloud, managed services | Use when clients require it or for services with no good FOSS equivalent |
| **Google Workspace** | Email, calendar, chat, docs/sheets | Free tier covers current needs; upgrade to Business Starter when client-facing |

## Folder Structure

```
infra/
├── README.md              ← you are here
├── sns-networking/        ← physical networking, security, on-prem: Proxmox, VMs, hardening, IDS, VPN
├── sns-digital/           ← cloud, web, code: AWS, hosting, CI/CD, dev environments
└── sns-support/           ← managed services: monitoring, backup, RMM, patching
```

## How to use these designs

Each subfolder contains one or more `.md` files describing a buildable design:
- **What it is** — one-paragraph purpose
- **Stack** — specific software, versions/sources, FOSS vs proprietary label
- **Topology** — where it runs (which provider/VM), network diagram if needed
- **Build steps** — enough to reproduce; points to Ansible roles or scripts when they exist
- **Security posture** — what's hardened, what's exposed, trust boundaries
- **Upgrade path** — what to do when this design hits its ceiling

Designs are intentionally simple. Complexity is added only when the simple version fails.