sam/sns-network-solutions
1
0
Fork 0
Code Issues 31 Pull Requests 5 Actions Packages Projects Releases Wiki Activity
8a5d8e6ee2
sns-network-solutions/infra
History
Samuel James 4831152b25 restructure: new corporate structure (Technology Group, Hospitality Group, Properties) 
- Add SnS Technology Group LLC (planned)
- Add SnS Hospitality Group LLC (Kiowa Scott 15%, coffee trailers 2-year plan)
- Add SnS Properties LLC (planned)
- Move 04-foodtruck1 to sns-hospitality-group/indian-food-truck-legacy
- Add Kiowa partnership agreement HTML (Option C split-grant, group-level)
- Add NDA, equity framework, legal services docs
- Add coffee trailers business plan (10 locations, NW IN + S. Michigan)
- Add corporate structure HTML (visual org chart)
- Add Holdings legal docs (certificate, EIN, operating agreement HTML)
2026-08-12 07:33:30 -05:00
..
sns-digital Consolidate 7 divisions to 3: Networking, Digital, Support 2026-07-18 13:08:23 -05:00
sns-networking Consolidate 7 divisions to 3: Networking, Digital, Support 2026-07-18 13:08:23 -05:00
sns-support Consolidate 7 divisions to 3: Networking, Digital, Support 2026-07-18 13:08:23 -05:00
future-stack-decisions.md restructure: new corporate structure (Technology Group, Hospitality Group, Properties) 2026-08-12 07:33:30 -05:00
README.md Consolidate 7 divisions to 3: Networking, Digital, Support 2026-07-18 13:08:23 -05:00

README.md

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.