Consolidate 7 divisions to 3: Networking, Digital, Support

- Merge Infrastructure + Secure + Systems → SNS Networking (Business #1)
- Merge Web + Software + Cloud → SNS Digital (planned)
- SNS Support unchanged (planned)
- Add infra/ folder with 16 FOSS-first buildable designs
- Update all agent knowledge, division briefs, legal structure
- Restructure businesses/ from 7 to 3 operating folders
This commit is contained in:
Samuel James 2026-07-18 13:08:23 -05:00
parent 55a80ce6e3
commit b1a35783bb
74 changed files with 2042 additions and 664 deletions

View File

@ -21,5 +21,5 @@ into results.
## Scope
I serve the **holding company** and, through it, every operating subsidiary
(`01-infrastructure` active; `02``07` as they launch). My job scales by adding
specialists beneath me — my role and the chain of command never change.
(`01-networking` active; `02-digital` and `03-support` as they launch). My job
scales by adding specialists beneath me — my role and the chain of command never change.

View File

@ -7,10 +7,11 @@ Durable facts and standing decisions. Daily working history lives in `memory/YYY
James**. Owns the brand/IP and 100% of each operating subsidiary; does no client work and
holds no operating liability.
- **Operating subsidiaries** (one LLC each, formed as each begins real work):
- `01-infrastructure`**SNS Infrastructure LLC** — networking/cabling/wireless — **ACTIVE, Business #1**.
- `02-secure`, `03-support`, `04-systems`, `05-cloud`, `06-web`, `07-software` — planned.
- `01-networking`**SNS Networking LLC** — physical networking, security, on-prem compute — **ACTIVE, Business #1**.
- `02-digital`**SNS Digital LLC** — code, cloud, web, hosting, apps — planned.
- `03-support`**SNS Support LLC** — managed services, RMM, SLAs — planned.
- **Stage:** pre-revenue. Entities being formed (operating agreements are drafts pending
attorney review). Focus is standing up SNS Infrastructure.
attorney review). Focus is standing up SNS Networking.
- **Brand promise:** Reliable Technology. Honest Recommendations. Professional Execution.
- **Values:** Integrity, Excellence, Simplicity, Security, Stewardship.

View File

@ -10,8 +10,8 @@ The person I serve.
## What Sam is building
A holding company that owns one operating subsidiary LLC per division. Business #1,
**SNS Infrastructure LLC** (`01-infrastructure`), is the active focus; Secure, Support,
Systems, Cloud, Web, and Software follow as each earns its launch. Current stage is
**SNS Networking LLC** (`01-networking`), is the active focus; Digital and Support
follow as each earns its launch. Current stage is
**pre-revenue** — forming entities and standing up the first business.
## How Sam wants to be worked with
@ -26,7 +26,7 @@ Systems, Cloud, Web, and Software follow as each earns its launch. Current stage
now, AWS later) and cares what things cost.
## Sam's standing priorities
1. Get SNS Infrastructure legally formed and operating self-sufficiently.
1. Get SNS Networking legally formed and operating self-sufficiently.
2. Keep the entity/liability structure clean (no commingling; approval gates hold).
3. Build reproducible systems that move from `ws` to AWS unchanged.
4. Only add capability (agents, tools, services) when the business actually needs it.

View File

@ -9,29 +9,24 @@ clean. When a request or a business report comes in, I check it against these sc
| # | Entity | Scope — what it does | Boundary — what it does NOT | Liability | Status |
|---|--------|----------------------|-----------------------------|-----------|--------|
| 00 | **SnS Network Solutions Holdings LLC** (parent) | Owns brand/IP + 100% of each subsidiary | No client work; no operating liability | None (by design) | — |
| 01 | **SNS Infrastructure LLC** | Structured cabling, LAN/networking, wireless — the physical wire and foundation | Not cameras/security (Secure), not servers/OS (Systems), not cloud (Cloud) | High (physical/on-site) | **ACTIVE (Business #1)** |
| 02 | **SNS Secure LLC** | Cameras, access control, alarms (physical security) **+** cybersecurity (audits, firewall, monitoring, incident response) | Not the base LAN (that's Infrastructure) | High (physical + cyber E&O) | Planned |
| 03 | **SNS Support LLC** | Managed services, helpdesk, RMM, monitoring, SLAs — maintains what the others build. **ALL recurring/managed contracts live here** | Not net-new build (that's the builder division) | MedHigh (SLA) | Planned |
| 04 | **SNS Systems LLC** | On-prem servers, Linux, virtualization, on-prem compute/storage | Not the wire (Infra), not off-prem (Cloud), not ongoing management (Support) | Medium | Planned |
| 05 | **SNS Cloud LLC** | AWS/Azure, hybrid, off-prem compute, migrations | Not on-prem (Systems); managed cloud is handed to Support | Medium | Planned |
| 06 | **SNS Web LLC** | Websites, hosting, domains, digital presence | Managed hosting SLAs coordinate with Support | LowMed | Planned |
| 07 | **SNS Software LLC** | Custom apps, automation, integrations (client owns the code) | Not off-the-shelf resale | Medium | Planned |
| 01 | **SNS Networking LLC** | Physical networking, cabling, wireless, security (cameras, access control, cyber), on-prem servers/virtualization/Linux — if it touches the network, protects it, or runs on-prem compute | Not cloud/off-prem (Digital), not recurring managed contracts (Support), not websites/apps/code (Digital) | High (physical + cyber E&O) | **ACTIVE (Business #1)** |
| 02 | **SNS Digital LLC** | Cloud infrastructure (AWS/Azure), websites, hosting, custom software, automation, CI/CD — anything code, cloud, or web | Not physical/on-site work (Networking), not recurring managed contracts (Support) | Medium (professional E&O) | Planned |
| 03 | **SNS Support LLC** | Managed services, helpdesk, RMM, monitoring, SLAs — maintains what Networking and Digital build. **ALL recurring/managed contracts live here** | Not net-new build (that's Networking or Digital) | MedHigh (SLA) | Planned |
## Boundary rules (the lines I enforce)
- **Build vs. maintain:** a division *builds*; **Support** *maintains*. Any recurring or
managed contract belongs to Support — not the builder.
- **Where the compute lives:** the wire = **Infrastructure** · on-prem servers = **Systems**
· off-prem = **Cloud**.
- **Security is its own entity:** cameras / access control / cyber = **Secure**, even on an
Infrastructure job site.
- **One job may touch several entities** — then it is **split**, and each part is scoped,
- **Build vs. maintain:** Networking and Digital *build*; **Support** *maintains*. Any
recurring or managed contract belongs to Support — not the builder.
- **Physical vs. digital:** On-site work (wire, servers, cameras, firewalls) =
**Networking**. Remote/code/cloud work (apps, websites, AWS) = **Digital**.
- **One job may touch multiple entities** — then it is **split**, and each part is scoped,
contracted, and billed under its own LLC. Never run one entity's work under another's name.
## Scope-bleed examples (catch and correct these)
- A camera install being run under Infrastructure → belongs to **Secure**.
- A "manage our network monthly" ask landing on Infrastructure → the managed part is **Support**.
- A cloud migration filed under Systems → **Cloud**.
- A hosting-with-SLA website job under Web → build is **Web**, the SLA/managed part is **Support**.
- A "manage our network monthly" ask landing on Networking → the managed part is **Support**.
- A cloud migration filed under Networking → belongs to **Digital**.
- A hosting-with-SLA website job under Digital → build is **Digital**, the SLA/managed part is **Support**.
- A camera install being scoped as Digital work → physical install belongs to **Networking**.
- A client wanting a custom app + on-prem server → server is **Networking**, app is **Digital**.
## What each business reports on (when it reports)
Work in progress · new requests/leads · blockers · anything crossing entity lines · anything

View File

@ -15,9 +15,9 @@
| Business Entity Report | ~$32 every 2 years, per entity |
## What $1,000 covers
Comfortably: forming the **parent Holdings LLC** (~$95) and **SNS Infrastructure LLC** (~$95),
Comfortably: forming the **parent Holdings LLC** (~$95) and **SNS Networking LLC** (~$95),
with buffer for optional attorney review, a business bank account, and incidentals. It does
**not** stretch to forming all seven subsidiaries at once — and it shouldn't (entities are
**not** stretch to forming all three subsidiaries at once — and it shouldn't (entities are
formed only as each begins real work).
## Rule for me (Chief)

View File

@ -14,7 +14,7 @@ good ones. This is analysis for Sam's decision, not a green light.
4. **Reality check:** who is the customer (ICP), do they actually have this problem, and
will they pay for it?
5. **Rough economics:** cost, effort, expected return, and **opportunity cost** vs. Sam's
standing priority (stand up SNS Infrastructure first).
standing priority (stand up SNS Networking first).
6. **If pursue:** the single smallest next step — ideally a test doable inside ~7 days.
## Output

View File

@ -8,8 +8,7 @@ Durable facts and standing standards. Working history lives in `projects/researc
## Business context (enough to make research relevant)
- SnS Network Solutions is an Indiana **holding company** (South Bend / St. Joseph County)
that owns operating subsidiaries: **Infrastructure** (active), plus Secure, Support,
Systems, Cloud, Web, Software.
that owns operating subsidiaries: **Networking** (active), plus Digital and Support.
- Common research areas: Indiana business/licensing rules, vendor and pricing comparisons,
competitors, tooling, and technology/regulatory questions relevant to those divisions.
- Chief owns the full entity-scope detail; I just need enough context to research the right thing.

View File

@ -50,7 +50,7 @@ for diagrams/tables, and a plain-language path for non-expert readers.
alternative where needed.
## Entity scoping
Documents belong to a specific SNS LLC (Infrastructure, Secure, etc.) or the Holdings parent.
Documents belong to a specific SNS LLC (Networking, Digital, Support) or the Holdings parent.
Chief tells me which; I keep that entity's name and details consistent and never mix entities in
one binding document unless it's explicitly a multi-party document.

View File

@ -20,15 +20,11 @@ This is the parent company.
The parent company represents engineering excellence and serves as the umbrella organization for all future divisions.
Examples of future divisions include:
The operating divisions are:
- SNS Infrastructure
- SNS Secure
- SNS Systems
- SNS Software
- SNS Web
- SNS Cloud
- SNS Support
- SNS Networking — physical networking, security, on-prem compute
- SNS Digital — code, cloud, web, hosting, apps
- SNS Support — managed services, RMM, SLAs
The parent company should NEVER compete with its own divisions.
@ -382,26 +378,14 @@ From structured cabling and Cisco networking to Linux systems, managed services,
SnS Network Solutions
├── SNS Infrastructure
(Networking, Cabling, Wireless)
├── SNS Networking
(Physical networking, cabling, wireless, security, on-prem servers/virtualization)
├── SNS Secure
(Security Cameras, Access Control, Cyber Security)
├── SNS Systems
(Linux, Servers, Virtualization, Managed Services)
├── SNS Software
(Custom Business Applications)
├── SNS Web
(Websites, Hosting, Digital Presence)
├── SNS Cloud
(AWS, Azure, Hybrid Infrastructure)
├── SNS Digital
(Cloud infrastructure, websites, hosting, custom software, automation)
└── SNS Support
(Managed Services)
(Managed services, RMM, monitoring, SLAs)
---

View File

@ -11,8 +11,8 @@
- **Isn't:** an operating business. It does **no client work**, has **no employees
doing billable work**, and carries **no operating liability**. Keeping it that
way (no commingling, no client contracts) is what keeps the liability shield intact.
- **Owns:** `01-infrastructure` (SNS Infrastructure LLC, active) and — as each
launches — `02-secure` … `07-software`.
- **Owns:** `01-networking` (SNS Networking LLC, active) and — as each
launches — `02-digital`, `03-support`.
## TODO → Form the Holding Company (do FIRST — see legal-structure.md Steps 13, 6)
- [ ] Confirm name availability on INBiz: **SnS Network Solutions Holdings LLC**
@ -24,7 +24,7 @@
- [ ] (Optional) Assumed business name if trading publicly as "SnS Network Solutions"
## TODO → Own the Subsidiaries
- [ ] For each subsidiary: record **Holdings LLC as sole member** in its operating agreement
- [ ] For each subsidiary (Networking, Digital, Support): record **Holdings LLC as sole member** in its operating agreement
- [ ] Keep parent and subsidiary funds strictly separate (no commingling)
- [ ] Hold the brand, domain, and core IP at the parent level

View File

@ -3,13 +3,15 @@
**Entity:** SnS Network Solutions Holdings LLC · **Accent:** Parent Cyan `#10C8D8`
The parent **holding company***not* an operating business. It owns the brand/IP
and 100% of every subsidiary LLC (`01-infrastructure` … `07-software`), signs no
client work, and carries no operating liability. That separation is what protects
each subsidiary from the others' liability.
and 100% of every subsidiary LLC, signs no client work, and carries no operating
liability. That separation is what protects each subsidiary from the others' liability.
This is its working folder (master brand assets + holding-company setup). It sits
**unnumbered** on purpose — it's the owner of the numbered operating subsidiaries,
not one of them.
**Subsidiaries owned:**
- `01-networking` — SNS Networking LLC (active)
- `02-digital` — SNS Digital LLC (planned)
- `03-support` — SNS Support LLC (planned)
This is its working folder (master brand assets + holding-company setup).
- Setup checklist → [`00-sns-holding.md`](./00-sns-holding.md)
- Master brand sheet + logo prompt → [`branding.html`](./branding.html)

View File

@ -1,37 +0,0 @@
# 01 · SNS Infrastructure — Scaffold / Research / TODO
**Status:** Business #1**ACTIVE** · **Tagline:** *The Physical Foundation*
**Entity:** SNS Infrastructure LLC (operating subsidiary of SnS Network Solutions Holdings LLC)
**Liability tier:** High (physical / on-site low-voltage work)
**Signature accent:** Signal Blue `#1E6FFF` — see [`branding.html`](./branding.html)
**Formal brief:** [`../../divisions/sns-infrastructure.md`](../../divisions/sns-infrastructure.md)
> This division is furthest along — its scaffold/research/todo already lives in the
> files below. This page is the index that ties them together.
## Working Documents
- [`../../divisions/sns-infrastructure.md`](../../divisions/sns-infrastructure.md) — formal brief / scope (in `divisions/`)
- [`sns-infrastructure-hiring.md`](./sns-infrastructure-hiring.md) — operator hiring plan
- [`operator-compensation-proposal.md`](./operator-compensation-proposal.md) — pay proposal
- [`cash-flow-model.md`](./cash-flow-model.md) + [`cash-flow-model.csv`](./cash-flow-model.csv) — 12-month projection
- [`branding-prompt.md`](./branding-prompt.md) — full logo prompt + variants
- [`branding.html`](./branding.html) — color sheet + copy-ready logo prompt
## TODO → Launch (see [`../../divisions/legal-structure.md`](../../divisions/legal-structure.md))
- [ ] Form SNS Infrastructure LLC on INBiz (owner: Holdings LLC)
- [ ] EIN + subsidiary operating agreement (Holdings as sole member)
- [ ] Business bank account (separate — protects the liability shield)
- [ ] Insurance: general liability + workers' comp (field/low-voltage class codes)
- [ ] Confirm South Bend / St. Joseph County low-voltage / cabling licensing
- [ ] Secure the ~$6580k loan runway (personal guarantee likely)
- [ ] Hire the builder-operator; set up Field Nation / Work Market for labor
- [ ] Vendor accounts (Graybar, ADI, Wesco/Anixter) + Fluke certifier
- [ ] Finalize logo from the branding prompt (deliver true vector)
## Milestones
Track build milestones here once the operator is onboarded and the plan is live
(see hiring plan §11 "Standing On Its Own" for the trigger to start Business #2).
## Legal & Insurance
Store formation docs, EIN letter, operating agreement, and insurance policies in a
`legal/` folder here when this splits into its own repo.

View File

@ -1,3 +0,0 @@
# SNS Infrastructure
See [`01-infrastructure.md`](./01-infrastructure.md) for scaffold, research, and TODO.

View File

@ -0,0 +1,77 @@
# 01 · SNS Networking — Scaffold / Research / TODO
**Status:** Business #1**ACTIVE** · **Tagline:** *The Connected Foundation*
**Entity:** SNS Networking LLC (operating subsidiary of SnS Network Solutions Holdings LLC)
**Liability tier:** High (physical/on-site + cyber E&O)
**Signature accent:** Signal Blue `#1E6FFF`
**Formal brief:** [`../../divisions/sns-networking.md`](../../divisions/sns-networking.md)
> **Consolidates:** former Infrastructure + Secure + Systems divisions into one entity.
> If it touches the network, protects the network, or runs on-prem compute — it's Networking.
## Scope
**Physical networking & cabling**
- Structured cabling (Cat6/6A, fiber) and certification
- Enterprise networking (Cisco, MikroTik, Ubiquiti) — routing, switching, VLANs
- Wireless design, site surveys, Wi-Fi deployment
- Rack build-outs, patch panels, cable management, labeling
- Network documentation: IP schemes, rack diagrams, cable maps
**Security (physical + cyber)**
- IP cameras (design, install, NVR/VMS), access control, alarms
- Firewalls/UTM, VPN, network segmentation
- Security audits, hardening, monitoring, incident response
- Awareness training
**On-prem systems**
- Linux server design, deployment, administration
- Virtualization (Proxmox, KVM) and containers
- Self-hosted infrastructure (identity, files, backups)
- Storage, NAS/SAN, disaster-recovery design
- Ansible automation for repeatable builds
## Boundary Rules
- **Build, don't maintain.** Project/build work lives here. Recurring managed contracts
(SLAs, monthly monitoring, helpdesk) belong to **SNS Support**.
- **Not cloud.** Off-prem compute (AWS, Azure, hosted) belongs to **SNS Digital**.
- **Not software/web.** Custom apps, websites, and hosting belong to **SNS Digital**.
## Working Documents (carried from former Infrastructure)
- [`sns-infrastructure-hiring.md`](./sns-infrastructure-hiring.md) — operator hiring plan
- [`operator-compensation-proposal.md`](./operator-compensation-proposal.md) — pay proposal
- [`cash-flow-model.md`](./cash-flow-model.md) + [`cash-flow-model.csv`](./cash-flow-model.csv) — 12-month projection
- [`branding-prompt.md`](./branding-prompt.md) — logo prompt + variants
## TODO → Launch
- [ ] Confirm name availability: **SNS Networking LLC** (or retain SNS Infrastructure LLC and file assumed name)
- [ ] Form LLC on INBiz (owner: Holdings LLC) · EIN · operating agreement
- [ ] Business bank account (separate from Holdings)
- [ ] Insurance: general liability + cyber E&O + workers' comp (field/low-voltage class)
- [ ] Confirm Indiana low-voltage / alarm / security licensing requirements
- [ ] Secure the ~$6580k loan runway (personal guarantee likely)
- [ ] Hire the builder-operator; set up Field Nation / Work Market for labor
- [ ] Vendor accounts (Graybar, ADI, Wesco/Anixter) + Fluke certifier
- [ ] Finalize combined logo/branding for the consolidated entity
## TODO → Security Service Line (formerly SNS Secure)
- [ ] Confirm Indiana alarm/security licensing — blocker for physical security work
- [ ] Decide launch shape: physical-first, cyber-first, or both
- [ ] Pick core product lines (cameras, access control, firewall/UTM vendors)
- [ ] Draft pricing + service packages (project vs. monitoring handoff to Support)
## TODO → Systems Service Line (formerly SNS Systems)
- [ ] Define standard reference builds (hypervisor, backup, identity, monitoring)
- [ ] Build the Ansible baseline / IaC repo
- [ ] Pricing: project builds vs. handoff-to-Support maintenance
## Milestones
Track build milestones here once the operator is onboarded and the plan is live.
## Legal & Insurance
- **Licensing flag:** Indiana may require a state license to sell/install/monitor
burglar/fire/electronic security, access control, and CCTV — verify before physical
security work.
- Store formation docs, EIN letter, operating agreement, licenses, and insurance
policies in `docs/` when this splits into its own repo.

View File

@ -0,0 +1,3 @@
# SNS Networking
See [`01-networking.md`](./01-networking.md) for scaffold, research, and TODO.

View File

Before

Width:  |  Height:  |  Size: 3.0 MiB

After

Width:  |  Height:  |  Size: 3.0 MiB

View File

Before

Width:  |  Height:  |  Size: 2.8 MiB

After

Width:  |  Height:  |  Size: 2.8 MiB

View File

Before

Width:  |  Height:  |  Size: 1.2 MiB

After

Width:  |  Height:  |  Size: 1.2 MiB

View File

@ -0,0 +1,68 @@
# 02 · SNS Digital — Scaffold / Research / TODO
**Status:** Planned · **Tagline:** *Engineered for the Cloud*
**Entity:** SNS Digital LLC (operating subsidiary of SnS Network Solutions Holdings LLC)
**Liability tier:** Medium (professional E&O — all remote/keyboard work)
**Signature accent:** Sky `#38BDF8`
**Formal brief:** [`../../divisions/sns-digital.md`](../../divisions/sns-digital.md)
> **Consolidates:** former Web + Software + Cloud divisions into one entity.
> If it's code, cloud, or a website — it's Digital.
## Scope
**Cloud infrastructure**
- AWS/Azure architecture and deployment
- Hybrid infrastructure (on-prem ↔ cloud) and migrations
- Infrastructure-as-code, automation, CI/CD
- Cloud networking, security, cost optimization
- Backup, DR, business-continuity in the cloud
**Web & hosting**
- Website design and development (open-source stacks)
- Managed/self-hosted hosting and domains
- Email and DNS setup
- Performance, SEO fundamentals, accessibility compliance
- Maintenance and content update workflows
**Custom software**
- Custom web/business applications
- Business process automation and internal tooling
- API integrations between existing systems
- Data pipelines, reporting, dashboards
- Scripting/automation handed off with documentation
## Boundary Rules
- **Build, don't maintain.** Project/build work lives here. Recurring managed contracts
(hosting SLAs, monitoring, helpdesk) belong to **SNS Support**.
- **Not physical.** On-site networking, servers, cabling, security cameras belong to
**SNS Networking**.
- **IP terms matter.** The parent favors client code ownership (open-standards principle) —
specify who owns delivered code in every contract.
- **"SNS" collision.** Also = AWS Simple Notification Service — keep technical
proposals/docs unambiguous.
## TODO → Plan
- [ ] Define the standard tech stack: Hugo/static, WordPress (if forced), Docker Compose
- [ ] Standardize IaC tooling (Terraform) + CI/CD baseline (Gitea Actions + KESTRA)
- [ ] AWS landing-zone / account-structure templates
- [ ] Standard contract with explicit IP/ownership + licensing terms — attorney review
- [ ] Pricing models: project fixed-bid, time-and-materials, hosting/maintenance tiers
- [ ] Accessibility (WCAG) baseline as standard deliverable for web work
- [ ] Get E&O / professional liability insurance quotes
- [ ] Finalize combined logo/branding
## TODO → Launch
- [ ] Form SNS Digital LLC on INBiz (owner: Holdings LLC) · EIN · operating agreement
- [ ] Separate business bank account
- [ ] Bind E&O / professional liability insurance
- [ ] Domain/DNS/email provisioning workflow
## Milestones
_TBD — populate once the plan above is complete._
## Legal & Insurance
- All professional/E&O liability. No physical premises risk.
- Define cloud account ownership up front per client (client-owned preferred).
- Store formation docs, client contracts (IP terms), and insurance in `docs/`.

View File

@ -0,0 +1,3 @@
# SNS Digital
See [`02-digital.md`](./02-digital.md) for scaffold, research, and TODO.

View File

@ -1,38 +0,0 @@
# 02 · SNS Secure — Scaffold / Research / TODO
**Status:** Planned · natural **Business #2** front-runner · **Tagline:** *Protected by Design*
**Entity:** SNS Secure LLC (operating subsidiary of SnS Network Solutions Holdings LLC)
**Liability tier:** **High** — highest combined exposure of any division (physical install + cyber E&O)
**Signature accent:** Amber `#F5A623` — see [`branding.html`](./branding.html)
**Formal brief:** [`../../divisions/sns-secure.md`](../../divisions/sns-secure.md)
## Scaffold / Research
- **Two service lines, two risk profiles:**
- *Physical* — IP cameras (design/install, NVR/VMS), access control, alarm/intrusion.
- *Cyber* — audits, hardening, firewall/UTM, monitoring, incident response, training.
- **Insurance is split:** general liability (physical install) **+** cyber errors & omissions (E&O). Different products.
- **Licensing flag:** 2026 guidance suggests Indiana now requires a **state license to sell/install/monitor** burglar/fire/electronic security, access control, and CCTV — **verify before any physical work**.
- **Possible future split:** *Secure (Physical)* vs. *Secure (Cyber)*.
- Depends on **00-Infrastructure** as the network substrate; sells into the same client base.
## TODO → Plan (do before creating milestones)
- [ ] Confirm Indiana alarm/security licensing requirements (state + local) — blocker for physical work
- [ ] Decide launch shape: physical-first, cyber-first, or both
- [ ] Get insurance quotes: GL **and** cyber E&O
- [ ] Pick core product lines / vendor partners (cameras, access control, firewall/UTM)
- [ ] Draft pricing + service packages (project vs. monitoring/recurring)
- [ ] Define go-to-market (cross-sell from Infrastructure clients?)
- [ ] Staffing: certified installer(s) + cyber skillset (or contractor model)
- [ ] Finalize logo from [`branding.html`](./branding.html) prompt
## TODO → Launch (see [`../../divisions/legal-structure.md`](../../divisions/legal-structure.md))
- [ ] Form SNS Secure LLC on INBiz (owner: Holdings LLC) · EIN · operating agreement
- [ ] Separate business bank account
- [ ] Bind GL + cyber E&O insurance
- [ ] Obtain required security/alarm license(s)
## Milestones
_TBD — populate once the plan above is complete._
## Legal & Insurance
Store formation docs, licenses, and insurance policies in a `legal/` folder here.

View File

@ -1,3 +0,0 @@
# SNS Secure
See [`02-secure.md`](./02-secure.md) for scaffold, research, and TODO.

View File

@ -1,28 +1,41 @@
# 03 · SNS Support — Scaffold / Research / TODO
**Status:** Planned · natural **Business #2/#3** candidate · **Tagline:** *Always On*
**Status:** Planned · natural **Business #2** candidate · **Tagline:** *Always On*
**Entity:** SNS Support LLC (operating subsidiary of SnS Network Solutions Holdings LLC)
**Liability tier:** **MediumHigh**SLA/contractual exposure + recurring revenue worth ring-fencing
**Signature accent:** Orange `#F97316` — see [`branding.html`](./branding.html)
**Liability tier:** MediumHigh (SLA/contractual exposure + recurring revenue worth ring-fencing)
**Signature accent:** Orange `#F97316`
**Formal brief:** [`../../divisions/sns-support.md`](../../divisions/sns-support.md)
## Scaffold / Research
- **The recurring-revenue engine** — maintains what every other division builds; where the brand's "long-term partnership" promise actually lives.
- **Consolidation rule:** ALL managed-service contracts live here (pulling the overlaps out of Systems and Cloud). Systems/Cloud build; Support maintains.
- **Services:** managed IT / helpdesk, RMM, patch management, backup monitoring + DR testing, SLA response/escalation, recurring health reporting.
- **Main risks:** downtime and data-loss claims → SLA terms + E&O coverage are critical.
- Turns one-time projects from all divisions into durable monthly relationships.
## Scope
## TODO → Plan (do before creating milestones)
The **recurring-revenue engine** — maintains what Networking and Digital build.
Where the brand's "long-term partnership" promise actually lives.
**Services:**
- Managed IT / helpdesk and remote monitoring (RMM)
- Patch management and preventive maintenance
- Backup monitoring and disaster-recovery testing
- SLA-based response and escalation
- Recurring documentation and health reporting
- Monitoring, alerting, and uptime management
## Boundary Rules
- **Maintain, don't build.** Net-new build work (networking, cloud, apps) belongs to
**Networking** or **Digital**. Support takes over after handoff.
- **ALL recurring/managed contracts live here.** This is the single home for SLA-based
work, regardless of which division built the original system.
- Turns one-time projects from Networking and Digital into durable monthly relationships.
## TODO → Plan
- [ ] Define SLA tiers (response/resolution times, coverage hours) + pricing per seat/device/site
- [ ] Choose RMM + PSA/ticketing + backup/monitoring toolstack
- [ ] Draft the managed-services agreement (SLA, liability caps, data handling) — attorney review
- [ ] Choose RMM + PSA/ticketing + backup/monitoring toolstack (MeshCentral, Prometheus, PBS)
- [ ] Draft managed-services agreement (SLA, liability caps, data handling) — attorney review
- [ ] Decide staffing / after-hours coverage model (in-house vs. contracted NOC)
- [ ] Map cross-sell handoff from Infrastructure/Systems/Cloud projects
- [ ] Map cross-sell handoff from Networking and Digital projects
- [ ] Get E&O insurance quotes
- [ ] Finalize logo from [`branding.html`](./branding.html) prompt
## TODO → Launch (see [`../../divisions/legal-structure.md`](../../divisions/legal-structure.md))
## TODO → Launch
- [ ] Form SNS Support LLC on INBiz (owner: Holdings LLC) · EIN · operating agreement
- [ ] Separate business bank account
- [ ] Bind E&O + general liability insurance
@ -31,4 +44,6 @@
_TBD — populate once the plan above is complete._
## Legal & Insurance
Store formation docs, client MSAs/SLAs, and insurance policies in a `legal/` folder here.
- SLA commitments create contractual exposure; downtime and data-loss claims are the main risks.
- Contracts and E&O coverage are critical.
- Store formation docs, client MSAs/SLAs, and insurance policies in `docs/`.

View File

@ -1,33 +0,0 @@
# 04 · SNS Systems — Scaffold / Research / TODO
**Status:** Planned · **Tagline:** *Systems That Endure*
**Entity:** SNS Systems LLC (operating subsidiary of SnS Network Solutions Holdings LLC)
**Liability tier:** **Medium** — mostly configuration/professional work; E&O matters more than premises liability
**Signature accent:** Emerald `#10B981` — see [`branding.html`](./branding.html)
**Formal brief:** [`../../divisions/sns-systems.md`](../../divisions/sns-systems.md)
## Scaffold / Research
- **The on-prem compute layer** — the clearest expression of the parent's open-source, Linux-first philosophy.
- **Services:** Linux server design/admin, virtualization (Proxmox, KVM, VMware) + containers, self-hosted infra (mail, files, identity, backups), storage/NAS/SAN + DR design, Ansible automation for repeatable documented builds.
- **Boundary line:** Systems = on-prem servers/OS/virtualization. Infrastructure = the wire/LAN. Cloud = off-prem compute.
- **Managed work goes to Support**, not here — Systems builds, Support maintains.
- Until active, can run as an assumed name of an existing operating sub or the parent.
## TODO → Plan (do before creating milestones)
- [ ] Define standard reference builds (hypervisor stack, backup stack, identity, monitoring)
- [ ] Build the Ansible baseline / IaC repo for repeatable deployments
- [ ] Pricing: project builds vs. handoff-to-Support maintenance
- [ ] Vendor/hardware sourcing (servers, storage) + open-source stack decisions
- [ ] Get E&O insurance quotes
- [ ] Finalize logo from [`branding.html`](./branding.html) prompt
## TODO → Launch (see [`../../divisions/legal-structure.md`](../../divisions/legal-structure.md))
- [ ] Form SNS Systems LLC on INBiz (owner: Holdings LLC) · EIN · operating agreement
- [ ] Separate business bank account
- [ ] Bind E&O + general liability insurance
## Milestones
_TBD — populate once the plan above is complete._
## Legal & Insurance
Store formation docs and insurance policies in a `legal/` folder here.

View File

@ -1,3 +0,0 @@
# SNS Systems
See [`04-systems.md`](./04-systems.md) for scaffold, research, and TODO.

View File

@ -1,78 +0,0 @@
<!DOCTYPE html>
<!-- SNS Systems — color scheme + logo prompt. Inherits parent brand (../../ai-core/knowledge/sns.md). -->
<html lang="en">
<head>
<meta charset="UTF-8">
<meta name="viewport" content="width=device-width, initial-scale=1.0">
<title>SNS Systems — Brand Sheet</title>
<style>
:root{--navy:#0A1628;--darkgray:#20252B;--white:#F6F7F9;--parent-cyan:#10C8D8;--accent:#10B981;/* Emerald */}
*{box-sizing:border-box;margin:0;padding:0}
body{background:var(--navy);color:var(--white);font-family:"IBM Plex Sans",Inter,system-ui,Arial,sans-serif;line-height:1.5;padding:48px 24px}
.wrap{max-width:920px;margin:0 auto}
h1{font-family:Oxanium,Sora,Rajdhani,system-ui,sans-serif;font-weight:700;font-size:2.2rem;letter-spacing:.5px}
h1 .light{font-weight:300;color:var(--accent)}
.tag{color:var(--parent-cyan);font-size:1.05rem;margin:4px 0}
.accent-bar{height:6px;width:120px;background:var(--accent);border-radius:3px;margin:14px 0 32px}
h2{font-family:Oxanium,Sora,sans-serif;font-weight:600;font-size:1.15rem;margin:34px 0 14px;text-transform:uppercase;letter-spacing:1.5px}
.grid{display:grid;grid-template-columns:repeat(auto-fill,minmax(150px,1fr));gap:14px}
.sw{border-radius:10px;overflow:hidden;border:1px solid rgba(255,255,255,.1)}
.chip{height:88px}
.meta{padding:10px 12px;background:var(--darkgray);font-size:.82rem}
.meta b{display:block;font-size:.9rem;margin-bottom:2px}
.hex{font-family:"IBM Plex Mono",monospace;color:var(--parent-cyan)}
.signature{grid-column:1/-1}
.signature .chip{height:120px;display:flex;align-items:flex-end;padding:12px}
.signature .lbl{background:rgba(10,22,40,.55);color:#fff;padding:4px 10px;border-radius:6px;font-size:.8rem}
.type{background:var(--darkgray);border-radius:10px;padding:18px 20px}
.type p{margin:4px 0;font-size:.95rem}
.promptbox{position:relative;background:#0d1a30;border:1px solid rgba(16,185,129,.4);border-radius:10px;padding:20px;margin-top:12px}
pre{white-space:pre-wrap;font-family:"IBM Plex Mono",ui-monospace,monospace;font-size:.85rem;color:#dfe7f5}
button{position:absolute;top:12px;right:12px;background:var(--accent);color:#06231a;border:0;padding:8px 14px;border-radius:6px;font-size:.8rem;cursor:pointer;font-weight:700}
button:active{transform:translateY(1px)}
</style>
</head>
<body>
<div class="wrap">
<h1>SNS <span class="light">Systems</span></h1>
<div class="tag">Systems That Endure</div>
<div class="accent-bar"></div>
<h2>Signature Accent</h2>
<div class="grid">
<div class="sw signature"><div class="chip" style="background:#10B981"><span class="lbl">Emerald &nbsp; <span class="hex">#10B981</span></span></div></div>
</div>
<h2>Base Palette (constant across all SNS brands)</h2>
<div class="grid">
<div class="sw"><div class="chip" style="background:#0A1628"></div><div class="meta"><b>Primary Navy</b><span class="hex">#0A1628</span></div></div>
<div class="sw"><div class="chip" style="background:#20252B"></div><div class="meta"><b>Dark Gray</b><span class="hex">#20252B</span></div></div>
<div class="sw"><div class="chip" style="background:#F6F7F9"></div><div class="meta" style="color:#20252B;background:#F6F7F9"><b>White</b><span class="hex" style="color:#00A8C6">#F6F7F9</span></div></div>
<div class="sw"><div class="chip" style="background:#10C8D8"></div><div class="meta"><b>Parent Cyan</b><span class="hex">#10C8D8</span></div></div>
</div>
<h2>Typography</h2>
<div class="type">
<p><b>Display:</b> Oxanium / Sora / Rajdhani — geometric, "SNS" heavier.</p>
<p><b>Body:</b> IBM Plex Sans / Inter — clean, highly legible.</p>
<p><b>Rule:</b> flat, no gradients, works in 1-color, black &amp; white, embroidery, laser, vinyl.</p>
</div>
<h2>ChatGPT Logo Prompt</h2>
<div class="promptbox">
<button onclick="navigator.clipboard.writeText(document.getElementById('p').innerText)">Copy</button>
<pre id="p">Design a minimal, geometric logo for "SNS Systems," a professional Linux server, virtualization, and systems-engineering company. Flat vector style, no gradients, no 3D, no shadows — clean, precise, architectural and timeless, like the mark of a serious engineering firm rather than consumer tech.
Symbol: an abstract geometric mark suggesting stable, enduring layered systems — precise stacked modular blocks forming a solid column or module, implying servers and durable infrastructure abstractly. Engineered, modular, and recognizable without text.
Color: deep navy #0A1628 as the primary, a single emerald accent #10B981, and white #F6F7F9. Two colors maximum. Must also read cleanly in solid one-color and in pure black-and-white.
Typography: pair the icon with a clean geometric sans-serif wordmark "SNS Systems" (in the style of Oxanium / Sora / IBM Plex Sans) — "SNS" heavier, "Systems" lighter.
Layout: horizontal lockup, icon left and wordmark right, on a plain flat background. High contrast, generous negative space, centered, logo-sheet presentation.
Avoid: literal server towers, penguins/Tux, computer monitors, terminals, gears, globes, lightning bolts, clip art, gradients, drop shadows, mascots, and generic IT imagery.</pre>
</div>
</div>
</body>
</html>

View File

@ -1,34 +0,0 @@
# 05 · SNS Cloud — Scaffold / Research / TODO
**Status:** Planned · **Tagline:** *Infrastructure Without Limits*
**Entity:** SNS Cloud LLC (operating subsidiary of SnS Network Solutions Holdings LLC)
**Liability tier:** **Medium** — professional liability; client cloud spend + data handling create fiduciary/contractual responsibility
**Signature accent:** Sky `#38BDF8` — see [`branding.html`](./branding.html)
**Formal brief:** [`../../divisions/sns-cloud.md`](../../divisions/sns-cloud.md)
## Scaffold / Research
- **The scale layer** — anything hosted off-premises; the scalable extension of SNS Systems.
- **Services:** AWS/Azure architecture + deployment, hybrid (on-prem ↔ cloud) migration, IaC + CI/CD automation, cloud networking/security/cost optimization, backup/DR/business-continuity in the cloud.
- **Boundary line:** Cloud = off-prem compute. Systems = on-prem. Infrastructure = the LAN/wire.
- **Naming caution:** "SNS" also = **AWS Simple Notification Service** — keep technical proposals/docs unambiguous.
- **Define account ownership** up front — who owns the client's cloud account (client-owned preferred, per open-standards principle).
## TODO → Plan (do before creating milestones)
- [ ] Standardize IaC tooling (Terraform/CloudFormation) + CI/CD baseline
- [ ] Define landing-zone / account-structure + security baseline templates
- [ ] Pricing: project vs. managed cloud (coordinate managed with Support)
- [ ] Decide primary platform focus (AWS-first per parent's stated preference)
- [ ] Cost-optimization / billing-transparency offering
- [ ] Get E&O insurance quotes
- [ ] Finalize logo from [`branding.html`](./branding.html) prompt
## TODO → Launch (see [`../../divisions/legal-structure.md`](../../divisions/legal-structure.md))
- [ ] Form SNS Cloud LLC on INBiz (owner: Holdings LLC) · EIN · operating agreement
- [ ] Separate business bank account
- [ ] Bind E&O + general liability insurance
## Milestones
_TBD — populate once the plan above is complete._
## Legal & Insurance
Store formation docs and insurance policies in a `legal/` folder here.

View File

@ -1,3 +0,0 @@
# SNS Cloud
See [`05-cloud.md`](./05-cloud.md) for scaffold, research, and TODO.

View File

@ -1,33 +0,0 @@
# 06 · SNS Web — Scaffold / Research / TODO
**Status:** Planned · **Tagline:** *Your Presence, Engineered*
**Entity:** SNS Web LLC (operating subsidiary of SnS Network Solutions Holdings LLC)
**Liability tier:** **LowMedium** — mainly professional liability; uptime/SLA terms if hosting
**Signature accent:** Magenta `#EC4899` — see [`branding.html`](./branding.html)
**Formal brief:** [`../../divisions/sns-web.md`](../../divisions/sns-web.md)
## Scaffold / Research
- **The public-facing layer** — websites/hosting/presence treated as engineered infrastructure, not disposable design work. Often the **entry-point service** that leads clients toward Infrastructure, Systems, or Support.
- **Services:** site design/dev (favor open-source stacks), managed/self-hosted hosting + domains, email/DNS, performance + SEO fundamentals + **accessibility compliance**, maintenance/content workflows.
- Hosting introduces recurring-revenue + data-responsibility → **coordinate managed hosting SLAs with SNS Support**.
- Lowest liability of the divisions — a candidate for early, low-risk revenue.
## TODO → Plan (do before creating milestones)
- [ ] Pick the standard open-source stack (CMS/static/framework) + hosting model
- [ ] Define packages: build-only vs. build + managed hosting/maintenance
- [ ] Accessibility (WCAG) baseline as a standard deliverable
- [ ] Pricing + recurring hosting/maintenance tiers (coordinate with Support)
- [ ] Domain/DNS/email provisioning workflow
- [ ] Get professional liability insurance quotes
- [ ] Finalize logo from [`branding.html`](./branding.html) prompt
## TODO → Launch (see [`../../divisions/legal-structure.md`](../../divisions/legal-structure.md))
- [ ] Form SNS Web LLC on INBiz (owner: Holdings LLC) · EIN · operating agreement
- [ ] Separate business bank account
- [ ] Bind professional liability insurance
## Milestones
_TBD — populate once the plan above is complete._
## Legal & Insurance
Store formation docs and insurance policies in a `legal/` folder here.

View File

@ -1,3 +0,0 @@
# SNS Web
See [`06-web.md`](./06-web.md) for scaffold, research, and TODO.

View File

@ -1,32 +0,0 @@
# 07 · SNS Software — Scaffold / Research / TODO
**Status:** Planned · **Tagline:** *Software Engineered to Fit*
**Entity:** SNS Software LLC (operating subsidiary of SnS Network Solutions Holdings LLC)
**Liability tier:** **Medium** — professional liability / E&O; IP ownership + licensing terms matter
**Signature accent:** Violet `#7C5CFC` — see [`branding.html`](./branding.html)
**Formal brief:** [`../../divisions/sns-software.md`](../../divisions/sns-software.md)
## Scaffold / Research
- **The problem-solving layer** — custom business applications + automation built to solve a specific client problem; not off-the-shelf products resold.
- **Services:** custom web/business apps, business-process automation + internal tooling, API integrations between existing systems, data pipelines/reporting/dashboards, scripting/automation handed off with documentation.
- **IP terms are the key contract issue:** the parent favors **client code ownership** (open-standards principle) — specify who owns delivered code in every contract.
- Until active, can run as an assumed name of an existing operating sub.
## TODO → Plan (do before creating milestones)
- [ ] Define the standard stack + delivery process (repos, CI/CD, handoff docs)
- [ ] Standard contract with explicit IP/ownership + licensing terms — attorney review
- [ ] Pricing model: fixed-bid vs. time-and-materials vs. retainer
- [ ] Decide scope guardrails (avoid open-ended custom builds without change control)
- [ ] Get E&O / professional liability insurance quotes
- [ ] Finalize logo from [`branding.html`](./branding.html) prompt
## TODO → Launch (see [`../../divisions/legal-structure.md`](../../divisions/legal-structure.md))
- [ ] Form SNS Software LLC on INBiz (owner: Holdings LLC) · EIN · operating agreement
- [ ] Separate business bank account
- [ ] Bind E&O / professional liability insurance
## Milestones
_TBD — populate once the plan above is complete._
## Legal & Insurance
Store formation docs, client contracts (IP terms), and insurance policies in a `legal/` folder here.

View File

@ -1,3 +0,0 @@
# SNS Software
See [`07-software.md`](./07-software.md) for scaffold, research, and TODO.

View File

@ -2,8 +2,7 @@
The **parent holding company** plus its **operating subsidiaries**. `divisions/`
holds the formal one-page briefs; the working scaffold, research, todo, branding,
and (later) milestones live here. Each subsidiary is a self-contained unit that can
lift out into its own repo (with its own `legal/` folder) when it launches.
and (later) milestones live here.
## Parent (holding company — not an operating business)
@ -11,18 +10,26 @@ lift out into its own repo (with its own `legal/` folder) when it launches.
|--------|--------|--------|------|
| [`00-sns-holding/`](./00-sns-holding/) | SnS Network Solutions Holdings LLC | Parent Cyan `#10C8D8` | Owns the brand + 100% of every subsidiary; no client work, no operating liability |
## Operating subsidiaries (numbered by importance)
## Operating subsidiaries
| # | Business | Tagline | Accent | Status |
|---|----------|---------|--------|--------|
| [01](./01-infrastructure/) | SNS Infrastructure | The Physical Foundation | Signal Blue `#1E6FFF` | **Active** |
| [02](./02-secure/) | SNS Secure | Protected by Design | Amber `#F5A623` | Planned |
| [03](./03-support/) | SNS Support | Always On | Orange `#F97316` | Planned |
| [04](./04-systems/) | SNS Systems | Systems That Endure | Emerald `#10B981` | Planned |
| [05](./05-cloud/) | SNS Cloud | Infrastructure Without Limits | Sky `#38BDF8` | Planned |
| [06](./06-web/) | SNS Web | Your Presence, Engineered | Magenta `#EC4899` | Planned |
| [07](./07-software/) | SNS Software | Software Engineered to Fit | Violet `#7C5CFC` | Planned |
| # | Business | Tagline | Accent | Combines (former divisions) | Status |
|---|----------|---------|--------|----------------------------|--------|
| [01](./01-networking/) | SNS Networking | The Connected Foundation | Signal Blue `#1E6FFF` | Infrastructure + Secure + Systems | **Active** |
| [02](./02-digital/) | SNS Digital | Engineered for the Cloud | Sky `#38BDF8` | Web + Software + Cloud | Planned |
| [03](./03-support/) | SNS Support | Always On | Orange `#F97316` | Unchanged | Planned |
Each folder contains: a scaffold/todo doc, a `branding.html` color sheet + logo
prompt, a `branding/` assets folder, and a `README.md`. Milestones get added once
the plan is set.
## Why 3 instead of 7
- **Networking** covers everything physical + on-prem: same job site, same skill set,
same insurance pool (GL + cyber E&O). Cabling, firewalls, cameras, and servers are
one delivery team.
- **Digital** covers everything remote/code/cloud: same delivery model (keyboard, not
ladder), same insurance category (professional E&O). Cloud infra, websites, and
custom apps are one team.
- **Support** stays separate: it's the only division with recurring-revenue SLAs and a
different contract structure (ongoing responsibility vs. project-and-done).
## Folder contents
Each folder contains: a scaffold/todo doc, branding assets, and working documents.
Milestones get added once the plan is set.

View File

@ -13,72 +13,58 @@ real billable work** — not all at once (per-entity bookkeeping is the real cos
**Formal documents in this folder:**
- [`sns-network-solutions.md`](./sns-network-solutions.md) — parent company brief
- [`sns-infrastructure.md`](./sns-infrastructure.md) + the six division briefs below
- [`sns-networking.md`](./sns-networking.md), [`sns-digital.md`](./sns-digital.md), [`sns-support.md`](./sns-support.md) — division briefs
- [`legal-structure.md`](./legal-structure.md) — Indiana holding-company formation plan
- [`investment-research.md`](./investment-research.md) — owner investment research (reference)
> Full brand foundation lives at [`../ai-core/knowledge/sns.md`](../ai-core/knowledge/sns.md); working scaffold, branding,
> and milestones live under [`../businesses/`](../businesses/).
> **Status:** **SNS Infrastructure is Business #1 and now lives in its own folder:
> [`../businesses/01-infrastructure/`](../businesses/01-infrastructure/).** The owner
> will stand it up and get it running self-sufficiently — intentionally kept
> right-sized, not scaled aggressively — before starting Business #2.
> **Status:** **SNS Networking is Business #1 and lives in:
> [`../businesses/01-networking/`](../businesses/01-networking/).** The owner
> will stand it up and get it running self-sufficiently before starting Business #2.
---
## Division Index
**Launch order is sequential and owner-chosen — one business at a time.**
Business #1 is **SNS Infrastructure** (active). When it stands on its own, the
owner selects Business #2. The **liability tier** below is a *separate* signal: it
tells you how urgently each division needs its own LLC *once launched* (and
suggests a sensible order), but it is **not** a committed launch sequence.
Business #1 is **SNS Networking** (active). When it stands on its own, the
owner selects Business #2.
| Order | Division | Entity | Focus | Tagline | Liability Tier |
|-------|----------|--------|-------|---------|----------------|
| **#1 — ACTIVE** | [SNS Infrastructure](./sns-infrastructure.md) | SNS Infrastructure LLC | Networking, cabling, wireless | *The Physical Foundation* | High (physical/on-site) |
| #2+ (TBD) | [SNS Secure](./sns-secure.md) | SNS Secure LLC | Cameras, access control, cyber | *Protected by Design* | High (physical + cyber E&O) |
| #2+ (TBD) | [SNS Support](./sns-support.md) | SNS Support LLC | Managed services | *Always On* | MediumHigh (SLA) |
| #2+ (TBD) | [SNS Systems](./sns-systems.md) | SNS Systems LLC | Linux, servers, virtualization | *Systems That Endure* | Medium |
| #2+ (TBD) | [SNS Cloud](./sns-cloud.md) | SNS Cloud LLC | AWS, Azure, hybrid | *Infrastructure Without Limits* | Medium |
| #2+ (TBD) | [SNS Web](./sns-web.md) | SNS Web LLC | Sites, hosting, presence | *Your Presence, Engineered* | LowMedium |
| #2+ (TBD) | [SNS Software](./sns-software.md) | SNS Software LLC | Custom applications | *Software Engineered to Fit* | Medium |
When the owner does pick Business #2, the higher liability tiers (Secure, Support)
are the natural front-runners — but that's a suggestion, not a commitment. Full
rationale in [`legal-structure.md`](./legal-structure.md).
| # | Division | Entity | Combines | Focus | Tagline | Liability |
|---|----------|--------|----------|-------|---------|-----------|
| **01 — ACTIVE** | [SNS Networking](./sns-networking.md) | SNS Networking LLC | Infra + Secure + Systems | Physical networking, security, on-prem compute | *The Connected Foundation* | High |
| 02 (TBD) | [SNS Digital](./sns-digital.md) | SNS Digital LLC | Web + Software + Cloud | Code, cloud, websites, hosting, custom apps | *Engineered for the Cloud* | Medium |
| 03 (TBD) | [SNS Support](./sns-support.md) | SNS Support LLC | — | Managed services, RMM, SLAs | *Always On* | MediumHigh |
---
## Boundary Notes (resolve before launch)
## Why 3 Divisions (Not 7)
These divisions overlap in the source brand doc and need clear service lines so
they don't compete internally:
The original 7-division model over-segmented for a pre-revenue solo operation.
The consolidation groups by:
- **Managed Services** appears under *Systems*, *Support*, and *Cloud*. Consolidate
all recurring/managed-service contracts under **SNS Support** as the single
"always-on" revenue engine; Systems and Cloud deliver project/build work that
Support then maintains.
- **SNS Secure** blends physical security (cameras, access control — low-voltage
install) and cybersecurity (audits, monitoring, hardening) — different
insurance, licensing, and liability. Consider a future split into
*Secure (Physical)* and *Secure (Cyber)*.
- **Cloud vs. Systems vs. Infrastructure** — draw the line at where compute lives:
Infrastructure = the wire and the LAN, Systems = on-prem servers/OS/virtualization,
Cloud = anything hosted off-prem.
- **Delivery model:** Networking = on-site/physical. Digital = remote/keyboard. Support = ongoing/recurring.
- **Insurance pool:** Networking = GL + cyber E&O + workers' comp. Digital = professional E&O only. Support = E&O + SLA contractual.
- **Skill set:** Each division is one team, not fragments of work that share a job site.
---
## Boundary Rules
- **Build vs. maintain:** Networking and Digital *build*; **Support** *maintains*.
Any recurring/managed contract belongs to Support — not the builder.
- **Physical vs. digital:** On-site work (wire, servers, cameras) = **Networking**.
Remote/code/cloud work = **Digital**.
- **One job may touch multiple entities** — split it, scope each part under its own LLC.
---
## Brand Inheritance (all divisions)
- **Colors:** Navy `#0A1628`, Cyan `#10C8D8`, Secondary Blue `#00A8C6`, Accent `#4CE0D2`, White `#F6F7F9`, Dark Gray `#20252B`
- **Accent-per-division system:** one shared identity; each business keeps the navy
base and gets a signature accent — parent = Cyan `#10C8D8`, Infrastructure =
Signal Blue `#1E6FFF`, Secure = Amber, Systems = Emerald, Software = Violet, Web =
Magenta, Cloud = Sky, Support = Orange. Each business's `branding.html`
(color sheet + logo prompt) and `branding-prompt.md` carry its signature accent —
see [`../businesses/`](../businesses/).
- **Per-division accents:** Networking = Signal Blue `#1E6FFF`, Digital = Sky `#38BDF8`, Support = Orange `#F97316`
- **Type:** Geometric, legible open-source fonts (IBM Plex Sans / Inter for body; Oxanium / Sora / Rajdhani for display)
- **Voice:** Professional, clear, educational, transparent — never flashy or sales-driven
- **Logo lockup:** `SNS` wordmark + division descriptor (endorsed sub-brand — the parent brand always shows; a subsidiary never gets a standalone logo that hides SnS)
- **Logo lockup:** `SNS` wordmark + division descriptor (endorsed sub-brand — the parent brand always shows)

View File

@ -17,33 +17,31 @@ separate operating LLC for each division.
```
SnS Network Solutions Holdings LLC ← parent; owns the brand + all subsidiaries,
│ signs no client work, holds no operating liability
├── SNS Infrastructure LLC ← Business #1 (ACTIVE — owner's chosen first business)
├── SNS Secure LLC (High liability — physical install + cyber E&O)
├── SNS Support LLC (MedHigh — SLA/recurring-revenue)
├── SNS Systems LLC ┐
├── SNS Cloud LLC │ formed when each becomes an active business
├── SNS Web LLC │ (lower liability)
└── SNS Software LLC ┘
├── SNS Networking LLC ← Business #1 (ACTIVE) — physical networking, security, on-prem
├── SNS Digital LLC ← Business #2 (planned) — code, cloud, web, hosting, apps
└── SNS Support LLC ← Business #3 (planned) — managed services, RMM, SLAs
```
**Why 3 instead of 7:** The original 7-division model over-segmented for a pre-revenue
solo operation. Consolidation groups by delivery model (physical / digital / recurring),
insurance pool, and skill set. Each division is one team, not fragments.
**Launch order vs. liability tier — two different things:**
- **Launch order** is the owner's choice, one business at a time. **Business #1 is
SNS Infrastructure** (active); Business #2 is chosen once #1 stands on its own.
SNS Networking** (active); Business #2 is chosen once #1 stands on its own.
- **Liability tier** signals how urgently a division needs its own LLC *once
launched* and suggests a sensible order for later businesses — it is **not** the
launch sequence.
launched* — it is **not** the launch sequence.
**How it protects you:** each operating LLC's liability is walled off from the
others and from the parent. The parent owns the subsidiaries (and the brand/IP)
but does no client work, so a lawsuit against one division can't reach the assets
of another division or the parent.
### Do NOT form all 7 subsidiaries on day one
### Do NOT form all 3 subsidiaries on day one
Indiana's per-entity fees are cheap, but each LLC still needs its own **bank
account, bookkeeping, and tax prep** — that's the real cost. Form the **parent +
your first operating subsidiary now**, then add one subsidiary each time a
division begins doing real, billable work. The holding structure is built to
grow this way.
division begins doing real, billable work.
---
@ -53,8 +51,7 @@ Legend: 🌐 = fully online · 🏦 = may require phone/branch · 📄 = interna
### 1. Pre-filing prep — 🌐
- Search your names on INBiz to confirm availability: **SnS Network Solutions
Holdings LLC** and your first subsidiary, **SNS Infrastructure LLC** (Business #1).
- Decide which division launches first (that's your first operating subsidiary).
Holdings LLC** and your first subsidiary, **SNS Networking LLC** (Business #1).
- Decide registered agent: **yourself at your South Bend address = free**, or a
service ($100300/yr). One agent can cover all entities.
- **Fee:** $0 · **Time:** ~1 hour
@ -68,7 +65,7 @@ Legend: 🌐 = fully online · 🏦 = may require phone/branch · 📄 = interna
- IRS online EIN Assistant (irs.gov). Free, issued immediately.
- **Fee:** **$0** · **Time:** ~15 min
### 4. Form your first operating subsidiary — "SNS Infrastructure LLC" (Business #1) — 🌐
### 4. Form your first operating subsidiary — "SNS Networking LLC" (Business #1) — 🌐
- File Articles of Organization on INBiz.
- **Ownership:** the member/owner is **SnS Network Solutions Holdings LLC** — this
is what makes it a subsidiary. (Recorded in the operating agreement, Step 6.)
@ -101,8 +98,9 @@ Legend: 🌐 = fully online · 🏦 = may require phone/branch · 📄 = interna
- **Fee:** $025 · **Time:** ~1 day per account
### 9. Insurance — 🏦
- General liability + professional/E&O for each operating sub; **cyber liability**
for Secure and Support.
- **SNS Networking:** General liability + cyber E&O + workers' comp (field/low-voltage).
- **SNS Digital:** Professional E&O.
- **SNS Support:** E&O + general liability (SLA contractual coverage).
- Requires quotes (not instant/online).
- **Fee:** varies (~$5002,000+/yr per policy) · **Time:** a few days to quote/bind
@ -110,8 +108,8 @@ Legend: 🌐 = fully online · 🏦 = may require phone/branch · 📄 = interna
- If collecting sales tax, hiring, or withholding: file **BT-1** on INBiz
(**~$25** for a Registered Retail Merchant Certificate).
- Check **City of South Bend** and **St. Joseph County** for any local business
registration and **low-voltage/alarm licensing** before SNS Secure or SNS
Infrastructure does physical work (see notes below).
registration and **low-voltage/alarm licensing** before SNS Networking does
physical security work.
- **Fee:** ~$25 (BT-1 if needed) + local · **Time:** varies
---
@ -134,11 +132,6 @@ Legend: 🌐 = fully online · 🏦 = may require phone/branch · 📄 = interna
**~12 weeks** end-to-end including bank accounts and operating agreements
(longer if you have an attorney draft the agreements).
**Can it all be done online?** **Yes for every government filing** — formation,
EINs, assumed names, BT-1, and biennial reports all run through INBiz + IRS.
Only the bank accounts and insurance may need a phone call or branch visit, and
the operating agreements are internal documents you (or your attorney) prepare.
---
## Ongoing Compliance (per entity)
@ -156,21 +149,17 @@ the operating agreements are internal documents you (or your attorney) prepare.
## Launch Order & Liability Tiers
**Launch order (owner's choice — one business at a time):**
1. **SNS Infrastructure — Business #1 (ACTIVE).** Networking/cabling/wireless; see
[`businesses/01-infrastructure/`](../businesses/01-infrastructure/).
1. **SNS Networking — Business #1 (ACTIVE).** Physical networking, security, on-prem;
see [`../businesses/01-networking/`](../businesses/01-networking/).
2. **Business #2+ — TBD.** Chosen once Business #1 stands on its own.
**Liability tiers (how urgently each needs its own LLC once launched — a separate
signal from launch order, and a suggested ordering for later businesses):**
- **High:** *SNS Secure* (physical install + cyber E&O), *SNS Infrastructure*
(on-site/low-voltage work).
**Liability tiers:**
- **High:** *SNS Networking* (physical install + cyber E&O + workers' comp).
- **MediumHigh:** *SNS Support* (SLA contracts + recurring revenue worth ring-fencing).
- **Medium / Lower:** *SNS Systems, Cloud, Web, Software* — form each when it
becomes an active business. Until then they can run as assumed names of an
existing operating sub or the parent.
- **Medium:** *SNS Digital* (professional E&O only, all remote work).
When picking Business #2, the higher tiers (Secure, Support) are natural
front-runners — a suggestion, not a commitment.
When picking Business #2, Support is the natural front-runner — it's the
recurring-revenue engine that makes the business durable.
---
@ -179,11 +168,11 @@ front-runners — a suggestion, not a commitment.
S-corp taxation can cut self-employment tax (CPA question).
- **Contractor licensing is local, not statewide** — no Indiana general
contractor license; check City of South Bend & St. Joseph County for
low-voltage/cabling/construction rules (Infrastructure & Secure).
low-voltage/cabling/construction rules (Networking).
- **Alarm/security licensing — verify.** Sources conflict; recent (2026) guidance
indicates Indiana now requires a **state license to sell/install/monitor
burglar, fire, and electronic security systems, access control, and CCTV**.
Confirm before SNS Secure does physical work.
Confirm before SNS Networking does physical security work.
- **FinCEN BOI:** domestic US LLCs are **currently exempt** (interim rule since
March 2025). No BOI filing needed now — but the rule has changed before, so
re-check at formation.

View File

@ -1,26 +0,0 @@
# SNS Cloud
**Parent:** SnS Network Solutions · **Tagline:** *Infrastructure Without Limits*
## Scope
Anything hosted off-premises: public cloud, hybrid, and cloud-native
infrastructure. The scalable extension of SNS Systems.
## Services
- AWS and Azure architecture and deployment
- Hybrid infrastructure (on-prem ↔ cloud) and migration
- Infrastructure-as-code, automation, and CI/CD
- Cloud networking, security, and cost optimization
- Backup, DR, and business-continuity in the cloud
## Positioning
The scale layer. Line vs. neighbors: **Infrastructure** = the LAN/wire,
**Systems** = on-prem compute, **Cloud** = off-prem compute. Naming note: "SNS"
also = AWS Simple Notification Service — keep internal docs unambiguous.
## Liability & Ops Notes
- **Medium** — professional liability; client cloud spend and data handling
create fiduciary/contractual responsibility. Define who owns the cloud account.
- **Entity:** operating subsidiary **SNS Cloud LLC** under SnS Network Solutions
Holdings LLC. **Liability tier: Medium** — form its own LLC when this becomes an
active business.

49
divisions/sns-digital.md Normal file
View File

@ -0,0 +1,49 @@
# SNS Digital
**Parent:** SnS Network Solutions · **Tagline:** *Engineered for the Cloud*
## Scope
Everything code, cloud, and web. If it runs off-prem, lives in a browser, or is
custom software — it's Digital.
> **Consolidates:** former Web + Software + Cloud divisions.
## Services
**Cloud Infrastructure**
- AWS and Azure architecture and deployment
- Hybrid infrastructure (on-prem ↔ cloud) and migration
- Infrastructure-as-code, automation, and CI/CD
- Cloud networking, security, and cost optimization
- Backup, DR, and business-continuity in the cloud
**Web & Hosting**
- Website design and development (favor open-source stacks)
- Managed/self-hosted hosting and domains
- Email and DNS setup
- Performance, SEO fundamentals, and accessibility compliance
- Maintenance and content update workflows
**Custom Software**
- Custom web/business applications
- Business process automation and internal tooling
- API integrations between existing systems
- Data pipelines, reporting, and dashboards
- Scripting/automation handed off with documentation
## Positioning
The digital layer. Where Networking provides the physical substrate, Digital builds
what runs on top of it — and beyond it into the cloud. Often the entry-point
service (a website) that leads clients toward Networking or Support later.
## Liability & Ops Notes
- **Medium** — professional liability / E&O across all service lines. No physical
premises risk. IP ownership and licensing terms are the key contract issue
(parent favors client code ownership per open-standards principle).
- Hosting introduces recurring-revenue and data-responsibility — coordinate managed
hosting SLAs with SNS Support.
- **Naming caution:** "SNS" also = AWS Simple Notification Service — keep technical
proposals/docs unambiguous.
- **Entity:** operating subsidiary **SNS Digital LLC** under SnS Network Solutions
Holdings LLC. **Liability tier: Medium** — form its own LLC when this becomes an
active business.

View File

@ -1,26 +0,0 @@
# SNS Infrastructure
**Parent:** SnS Network Solutions · **Tagline:** *The Physical Foundation*
## Scope
The physical and logical backbone every other division depends on. If it carries
a signal, SNS Infrastructure designs, installs, and documents it.
## Services
- Structured cabling (Cat6/6A, fiber) and certification
- Enterprise networking (Cisco, MikroTik, Ubiquiti) — routing, switching, VLANs
- Wireless design, site surveys, and Wi-Fi deployment
- Rack build-outs, patch panels, cable management, labeling
- Network documentation: IP schemes, rack diagrams, cable maps
## Positioning
The foundation layer. Projects here are the substrate that Systems, Secure,
Cloud, and Support build on. Sells to any client with a physical premises.
## Liability & Ops Notes
- **High** — on-site physical/low-voltage work, ladders, client premises.
- Needs general liability + likely low-voltage licensing (state-dependent).
- **Entity:** operating subsidiary **SNS Infrastructure LLC** under SnS Network
Solutions Holdings LLC. **This is Business #1 (active)** — the owner's chosen
first business; see [`sns-infrastructure-hiring.md`](../businesses/01-infrastructure/sns-infrastructure-hiring.md).
**Liability tier: High** (physical/on-site work) — carries its own GL + workers' comp.

View File

@ -37,19 +37,16 @@ real billable work (see [`legal-structure.md`](./legal-structure.md)):
| Division | Entity | Focus | Status |
|----------|--------|-------|--------|
| [SNS Infrastructure](./sns-infrastructure.md) | SNS Infrastructure LLC | Networking, cabling, wireless | **Active (Business #1)** |
| [SNS Secure](./sns-secure.md) | SNS Secure LLC | Cameras, access control, cyber | Planned |
| [SNS Support](./sns-support.md) | SNS Support LLC | Managed services | Planned |
| [SNS Systems](./sns-systems.md) | SNS Systems LLC | Linux, servers, virtualization | Planned |
| [SNS Cloud](./sns-cloud.md) | SNS Cloud LLC | AWS, Azure, hybrid | Planned |
| [SNS Web](./sns-web.md) | SNS Web LLC | Sites, hosting, presence | Planned |
| [SNS Software](./sns-software.md) | SNS Software LLC | Custom applications | Planned |
| [SNS Networking](./sns-networking.md) | SNS Networking LLC | Physical networking, security, on-prem compute | **Active (Business #1)** |
| [SNS Digital](./sns-digital.md) | SNS Digital LLC | Code, cloud, web, hosting, custom apps | Planned |
| [SNS Support](./sns-support.md) | SNS Support LLC | Managed services, RMM, SLAs | Planned |
## Brand Identity (inherited by all divisions)
Navy `#0A1628` base + parent accent **Cyan `#10C8D8`**; each division keeps the navy
base and takes its own signature accent. Geometric, legible open-source type
(IBM Plex Sans / Inter; Oxanium / Sora / Rajdhani). Endorsed sub-brand lockup — the
`SNS` parent mark always shows. Full palette, typography, and logo direction in
base and takes its own signature accent (Networking = Signal Blue, Digital = Sky,
Support = Orange). Geometric, legible open-source type (IBM Plex Sans / Inter;
Oxanium / Sora / Rajdhani). Endorsed sub-brand lockup — the `SNS` parent mark always
shows. Full palette, typography, and logo direction in
[`../ai-core/knowledge/sns.md`](../ai-core/knowledge/sns.md).
## Liability & Ops Notes

View File

@ -0,0 +1,45 @@
# SNS Networking
**Parent:** SnS Network Solutions · **Tagline:** *The Connected Foundation*
## Scope
Everything physical, on-prem, and security-related. If it touches the network,
protects the network, or runs compute on-premises — it's Networking.
> **Consolidates:** former Infrastructure + Secure + Systems divisions.
## Services
**Physical Networking & Cabling**
- Structured cabling (Cat6/6A, fiber) and certification
- Enterprise networking (Cisco, MikroTik, Ubiquiti) — routing, switching, VLANs
- Wireless design, site surveys, and Wi-Fi deployment
- Rack build-outs, patch panels, cable management, labeling
- Network documentation: IP schemes, rack diagrams, cable maps
**Security (Physical + Cyber)**
- IP camera systems (design, install, NVR/VMS)
- Access control (door controllers, badge/credential systems)
- Alarm and intrusion integration
- Firewalls/UTM deployment, VPN, network segmentation
- Security audits, hardening, monitoring, incident response
- Awareness training
**On-Prem Systems**
- Linux server design, deployment, and administration
- Virtualization (Proxmox, KVM) and containers
- Self-hosted infrastructure (identity, files, backups)
- Storage, NAS/SAN, and disaster-recovery design
- Ansible automation for repeatable, documented builds
## Positioning
The foundation layer. Projects here are the substrate that Digital builds on and
Support maintains. Sells to any client with physical premises or on-prem compute needs.
Same job site, same skill set, same insurance pool — one delivery team.
## Liability & Ops Notes
- **High** — physical/on-site low-voltage work (GL + workers' comp) combined with
cyber errors & omissions (E&O). Two insurance products, one entity.
- Physical security install may require Indiana state licensing (verify before work).
- **Entity:** operating subsidiary **SNS Networking LLC** under SnS Network Solutions
Holdings LLC. **This is Business #1 (active).**

View File

@ -1,31 +0,0 @@
# SNS Secure
**Parent:** SnS Network Solutions · **Tagline:** *Protected by Design*
## Scope
Everything that protects the client — physically and digitally. Reflects the
parent's "security by design" principle as a dedicated business unit.
## Services
**Physical Security**
- IP camera systems (design, install, NVR/VMS)
- Access control (door controllers, badge/credential systems)
- Alarm and intrusion integration
**Cybersecurity**
- Security audits and hardening
- Firewall/UTM deployment and policy
- Monitoring, incident response, and awareness training
## Positioning
The trust layer. Distinct from Infrastructure (which builds the network) by
focusing on protecting it and the people/premises around it.
## Liability & Ops Notes
- **High on both fronts** — physical install liability + cyber errors &
omissions (E&O) exposure. These are different insurance products.
- Physical security install may require state licensing.
- **Entity:** operating subsidiary **SNS Secure LLC** under SnS Network Solutions
Holdings LLC. **Liability tier: High** — highest combined exposure of any division
(physical install + cyber E&O), so form its own LLC promptly when launched.
Strong candidate for Business #2. Possible future split into Physical vs. Cyber.

View File

@ -1,26 +0,0 @@
# SNS Software
**Parent:** SnS Network Solutions · **Tagline:** *Software Engineered to Fit*
## Scope
Custom business applications and automation built to solve a specific client
problem — not off-the-shelf products resold.
## Services
- Custom web/business applications
- Business process automation and internal tooling
- API integrations between existing systems
- Data pipelines, reporting, and dashboards
- Scripting/automation handed off with documentation
## Positioning
The problem-solving layer. Where the other divisions deploy infrastructure,
Software makes it do something specific to the client's operation.
## Liability & Ops Notes
- **Medium** — professional liability / E&O; IP ownership and licensing terms
matter. Contracts should specify who owns delivered code (parent favors client
ownership per the open-standards principle).
- **Entity:** operating subsidiary **SNS Software LLC** under SnS Network Solutions
Holdings LLC. **Liability tier: Medium** — form its own LLC when this becomes an
active business; until then it can run as an assumed name of an existing operating sub.

View File

@ -3,9 +3,8 @@
**Parent:** SnS Network Solutions · **Tagline:** *Always On*
## Scope
Ongoing managed services — the recurring-revenue engine that maintains what the
other divisions build. Recommended single home for **all** managed-service
contracts (consolidating overlaps from Systems and Cloud).
Ongoing managed services — the recurring-revenue engine that maintains what
Networking and Digital build. The single home for **all** managed-service contracts.
## Services
- Managed IT / helpdesk and remote monitoring (RMM)
@ -13,10 +12,11 @@ contracts (consolidating overlaps from Systems and Cloud).
- Backup monitoring and disaster-recovery testing
- SLA-based response and escalation
- Recurring documentation and health reporting
- Monitoring, alerting, and uptime management
## Positioning
The relationship layer — where "long-term partnership" (a core brand promise)
actually lives. Turns one-time projects from every division into durable,
actually lives. Turns one-time projects from Networking and Digital into durable,
recurring client relationships.
## Liability & Ops Notes
@ -24,5 +24,4 @@ recurring client relationships.
data-loss claims are the main risks. Contracts and E&O coverage are critical.
- **Entity:** operating subsidiary **SNS Support LLC** under SnS Network Solutions
Holdings LLC. **Liability tier: MediumHigh** (SLA/contractual exposure +
recurring revenue worth ring-fencing) — form its own LLC when launched. A natural
Business #2/#3 candidate.
recurring revenue worth ring-fencing) — form its own LLC when launched.

View File

@ -1,25 +0,0 @@
# SNS Systems
**Parent:** SnS Network Solutions · **Tagline:** *Systems That Endure*
## Scope
Servers, operating systems, and virtualization — the compute layer, on-premises.
The clearest expression of the parent's open-source, Linux-first philosophy.
## Services
- Linux server design, deployment, and administration
- Virtualization (Proxmox, KVM, VMware) and containers
- Self-hosted infrastructure (mail, files, identity, backups)
- Storage, NAS/SAN, and disaster-recovery design
- Automation (Ansible) for repeatable, documented builds
## Positioning
The engine room. Builds the on-prem compute that Support then maintains and that
Cloud extends off-premises. Draw the line: Systems = on-prem servers/OS.
## Liability & Ops Notes
- **Medium** — mostly configuration/professional work, limited physical risk.
- Professional liability (E&O) matters more than premises liability.
- **Entity:** operating subsidiary **SNS Systems LLC** under SnS Network Solutions
Holdings LLC. **Liability tier: Medium** — form its own LLC when this becomes an
active business.

View File

@ -1,26 +0,0 @@
# SNS Web
**Parent:** SnS Network Solutions · **Tagline:** *Your Presence, Engineered*
## Scope
Websites, hosting, and digital presence — treated as engineered infrastructure,
not disposable design work.
## Services
- Website design and development (favor open-source stacks)
- Managed/self-hosted hosting and domains
- Email and DNS setup
- Performance, SEO fundamentals, and accessibility compliance
- Maintenance and content update workflows
## Positioning
The public-facing layer. The client's front door. Often the entry-point service
that leads clients toward Infrastructure, Systems, or Support later.
## Liability & Ops Notes
- **LowMedium** — mainly professional liability; uptime/SLA terms if hosting.
- Hosting introduces recurring-revenue and data-responsibility considerations —
coordinate managed hosting SLAs with SNS Support.
- **Entity:** operating subsidiary **SNS Web LLC** under SnS Network Solutions
Holdings LLC. **Liability tier: LowMedium** — form its own LLC when this becomes
an active business.

52
infra/README.md Normal file
View File

@ -0,0 +1,52 @@
# 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.

View File

@ -0,0 +1,70 @@
# AWS Baseline Account — SNS Digital
**Entity:** SNS Digital · **Status:** Buildable now
## What it is
Minimal secure AWS account setup for internal use and future client work.
Uses only the managed services where FOSS alternatives add unacceptable ops burden.
## Services Used (and why)
| Service | Purpose | FOSS Alternative | Why AWS wins here |
|---------|---------|------------------|-------------------|
| Route53 | DNS hosting | PowerDNS / self-hosted | 100% uptime SLA, $0.50/zone, not worth self-hosting |
| S3 | Offsite backups, static assets | MinIO | Durability guarantee, lifecycle policies, no disk management |
| SES | Transactional email | Postfix | Deliverability, IP reputation, SPF/DKIM handled |
| IAM | Access control | N/A | Native to the platform |
| CloudWatch (basic) | Billing alerts only | N/A | Free tier, protects against cost surprises |
## Account Structure
```
SNS AWS Organization (future, when multi-client)
└── sns-ops (current — single account)
├── IAM User: sam (console + MFA, no programmatic keys on this user)
├── IAM Role: infra-deploy (Ansible/Terraform assumes this role)
├── IAM Role: backup-writer (PBS pushes to S3, write-only)
└── IAM Role: ses-sender (app email, send-only)
```
For now: single account `sns-ops`. Move to AWS Organizations when the first
client needs their own isolated account.
## Build Steps
1. **Account:** Create with dedicated email (aws@snsnetlabs.com or similar). Enable MFA.
2. **IAM:** Create `sam` user with console access + MFA. No access keys on this user.
3. **Roles:**
- `infra-deploy` — AdministratorAccess scoped to Terraform/Ansible (assume via CLI with MFA).
- `backup-writer` — S3 PutObject + PutObjectTagging on backup bucket only.
- `ses-sender` — ses:SendEmail + ses:SendRawEmail only.
4. **S3 backup bucket:**
```
Name: sns-backups-<account-id>
Versioning: enabled
Encryption: SSE-S3 (AES-256)
Lifecycle: transition to Glacier after 30 days, delete after 365
Bucket policy: deny all except backup-writer role + sam
```
5. **Route53:** Create hosted zone for `snsnetlabs.com` (or production domain).
Point registrar NS records here.
6. **SES:** Verify domain, request production access, configure DKIM + SPF.
7. **Billing alert:** CloudWatch alarm at $10, $25, $50 thresholds → email.
## Security Posture
- **No root key usage.** Root account locked with MFA, used only for billing/org changes.
- **No long-lived access keys** on human users. Use `aws sso login` or assume-role with MFA.
- **S3:** Block public access (account-level setting). Bucket policies explicit deny by default.
- **CloudTrail:** Enable for API audit logging (free for management events).
- **GuardDuty:** Enable free tier for threat detection (30-day trial then ~$4/month).
## Upgrade Path
- **AWS Organizations + SCPs:** When you onboard the first client to their own account.
- **Terraform state in S3 + DynamoDB:** When IaC grows beyond a few resources.
- **Control Tower:** When you manage 5+ accounts and need guardrails at scale.
<!-- ponytail: Single account until first client needs isolation. Ceiling: IAM
complexity in a shared account. Upgrade: AWS Organizations + per-client accounts. -->

View File

@ -0,0 +1,110 @@
# Development Environments — SNS Digital
**Entity:** SNS Digital · **Status:** Buildable now
## What it is
Reproducible dev environments that can be spun up on Proxmox in minutes.
No "works on my machine" — every project gets a defined environment.
## Stack
| Component | Software | FOSS | Role |
|-----------|----------|------|------|
| Remote dev | SSH + VS Code Remote / Kiro CLI | Yes | Code on server, UI on laptop |
| Environment definition | Ansible roles | Yes | Reproducible provisioning |
| Ephemeral VMs | Proxmox cloud-init clone | Yes | Fresh VM per project/experiment |
| Containers (app deps) | Docker Compose | Yes | Databases, caches, queues for local dev |
| Language management | mise (formerly rtx) | Yes | Python, Node, Go version pinning per project |
## Patterns
### Pattern 1: Remote VM (primary workflow)
```
Laptop (Kiro CLI / SSH) ──────► Dev VM on Proxmox
├── Project repo (git clone)
├── mise (.tool-versions)
├── Docker Compose (deps)
└── Full Linux environment
```
**When:** Most development. Get a full Linux box with all tools, accessible
from any device over Tailscale/WireGuard.
**Build:**
1. Clone Debian 12 template on Proxmox.
2. Run `dev-workstation` Ansible role:
- Install: git, mise, docker, docker-compose, build-essential
- Configure: user `sam`, SSH key, dotfiles
- Set resource: 4 vCPU, 8GB RAM, 64GB disk (adjustable)
3. SSH in, `mise install`, `docker compose up -d`, start coding.
### Pattern 2: Ephemeral project VM
**When:** Trying something risky, testing infrastructure changes, client-isolated work.
**Build:**
1. `qm clone 9000 --name experiment-xyz --full`
2. Work. Break things. Learn.
3. `qm destroy <vmid>` — gone, no cleanup.
### Pattern 3: Local laptop (lightweight)
**When:** Quick edits, offline work, documentation.
Just Kiro CLI + SSH config. The heavy lifting happens on the remote VM.
## mise Configuration (per-project)
```toml
# .mise.toml
[tools]
python = "3.12"
node = "20"
ansible = "latest"
[env]
VIRTUAL_ENV = ".venv"
```
Ensures every contributor (or future hire) gets the same versions without
polluting the system.
## Ansible Role: dev-workstation
```yaml
# roles/dev-workstation/tasks/main.yml (key tasks)
- name: Install base packages
apt:
name: [git, curl, jq, tmux, htop, build-essential, unzip]
- name: Install Docker
# Official Docker repo, not distro package
- name: Install mise
shell: curl https://mise.run | sh
- name: Clone dotfiles
git:
repo: gitea:sam/dotfiles.git
dest: /home/sam/.dotfiles
- name: Symlink dotfiles
# .bashrc, .tmux.conf, .gitconfig
```
## Security Posture
- **Dev VMs are not production.** They sit on the service VLAN but have no inbound
ports open beyond SSH.
- **No secrets in dev environments.** Use `.env.example` + Vaultwarden lookups.
- **Ephemeral VMs destroyed after use.** No stale boxes accumulating.
- **Docker socket access** is the one elevated privilege — acceptable for dev, not prod.
## Upgrade Path
- **Devcontainers / Codespaces-like:** If you hire devs who need browser-based IDEs,
deploy code-server or Gitpod self-hosted on Proxmox.
- **Nix flakes:** For truly reproducible environments beyond what mise offers
(full system-level deps). Higher learning curve.

View File

@ -0,0 +1,70 @@
# DNS & Domain Management — SNS Digital
**Entity:** SNS Digital · **Status:** Buildable now
## What it is
Centralized DNS management strategy. Public DNS on Route53 (cheap, reliable, API-driven).
Internal DNS on AdGuard Home (split-horizon for private services).
## Architecture
```
Public (internet-facing) Internal (on-prem only)
┌─────────────────────┐ ┌─────────────────────────┐
│ AWS Route53 │ │ AdGuard Home (LXC) │
│ │ │ │
│ snsnetlabs.com │ │ *.internal.sns → 192.168.122.x │
│ client-domain.com │ │ *.wg.internal → 10.10.0.x │
│ (delegated zones) │ │ │
└─────────────────────┘ └─────────────────────────┘
```
## Public DNS (Route53)
| Record | Purpose |
|--------|---------|
| `snsnetlabs.com` | Primary business domain |
| `A` / `CNAME` → Caddy public IP or Cloudflare | Client sites |
| `MX` → Google Workspace | Email |
| `TXT` SPF/DKIM/DMARC | Email auth |
| `CAA` | Restrict cert issuance to Let's Encrypt |
**Why Route53 over self-hosted DNS:** $0.50/zone/month, 100% SLA, no maintenance.
DNS is the one thing you don't want to self-host — if it goes down, everything goes down.
## Internal DNS (AdGuard Home)
- Runs on Proxmox LXC.
- Resolves `*.internal.sns` to local service IPs.
- Blocks ads/telemetry for all on-prem devices.
- Upstream: Cloudflare DoH (`https://dns.cloudflare.com/dns-query`).
## Domain Registration
- **Registrar:** Cloudflare Registrar (at-cost, no markup) or Porkbun (cheap, good UI).
- **Rule:** All client domains registered under the client's own account. SNS never
holds a client's domain hostage.
- **SNS-owned domains:** registered under Sam's account, Route53 for DNS.
## Build Steps
1. Register domain at Cloudflare/Porkbun.
2. Create Route53 hosted zone → get NS records.
3. Point registrar NS to Route53.
4. Add records via Ansible (`amazon.aws.route53` module) or Terraform.
5. For internal: add entry to AdGuard Home's DNS rewrites.
## Security Posture
- **DNSSEC:** Enable on Route53 for SNS-owned zones.
- **CAA records:** Restrict to `letsencrypt.org` only — prevents rogue cert issuance.
- **DMARC:** `p=reject` on all owned domains once SPF/DKIM confirmed working.
- **Registrar lock:** Transfer lock enabled on all production domains.
- **No wildcard DNS on public zones** unless explicitly needed (reduces attack surface).
## Upgrade Path
- **Terraform-managed DNS:** When zone count exceeds 5, manage all Route53 records
in Terraform for version control and drift detection.
- **PowerDNS:** If Route53 cost becomes a factor at scale (unlikely at $0.50/zone).

View File

@ -0,0 +1,136 @@
# Gitea & CI/CD Pipeline — SNS Digital
**Entity:** SNS Digital · **Status:** Active (Gitea running on 192.168.122.103)
## What it is
Self-hosted code platform (Gitea) with built-in CI/CD (Gitea Actions) and
KESTRA for complex workflow orchestration. Replaces GitHub/GitLab SaaS entirely.
## Stack
| Component | Software | FOSS | Role |
|-----------|----------|------|------|
| Code hosting | Gitea | Yes | Git repos, issues, PRs, container registry |
| CI/CD (simple) | Gitea Actions | Yes | GitHub Actions-compatible runners |
| CI/CD (complex) | KESTRA | Yes | Orchestration, data pipelines, scheduled workflows |
| Runner | Gitea Act Runner | Yes | Executes workflows (on 192.168.122.22) |
| Artifacts | Gitea Packages | Yes | Built-in package/container registry |
| Secrets | Gitea Secrets + Vaultwarden | Yes | CI secrets in Gitea, master secrets in Vaultwarden |
## Current Topology
```
┌─────────────────────────────┐
│ Gitea (192.168.122.103) │ ← VM on Proxmox
│ - Git SSH (port 22) │
│ - Web UI (port 3000) │
│ - Container registry │
└──────────────┬──────────────┘
┌─────────────────────────────┐
│ Runner (192.168.122.22) │ ← Dedicated VM
│ - Gitea Act Runner │
│ - Docker executor │
│ - Builds, tests, deploys │
└─────────────────────────────┘
Deploy targets:
- Proxmox VMs (rsync/SSH)
- Docker hosts (docker compose pull)
- S3 (static assets)
```
## Workflow Patterns
### Simple: Build & Deploy (Gitea Actions)
```yaml
# .gitea/workflows/deploy.yml
name: Deploy
on:
push:
branches: [main]
jobs:
deploy:
runs-on: ubuntu-latest
steps:
- uses: actions/checkout@v4
- name: Build
run: make build
- name: Deploy
run: rsync -avz ./dist/ sam@target:/srv/app/
env:
SSH_KEY: ${{ secrets.DEPLOY_KEY }}
```
### Complex: Multi-step orchestration (KESTRA)
Use KESTRA when:
- Workflow spans multiple systems (build → deploy → verify → notify)
- Needs scheduling (cron-triggered)
- Has conditional branching or retry logic
- Involves data pipelines
## Git Workflow
- **Branching:** trunk-based for solo work. Feature branches + PR when collaborating.
- **Protection:** `main` branch protected — no force push, require CI pass.
- **Naming:** `feature/`, `fix/`, `infra/` prefixes.
- **Commits:** Conventional commits (`feat:`, `fix:`, `docs:`, `infra:`).
## Build Steps (if setting up fresh)
1. **Gitea VM:**
```bash
# Docker Compose (already running)
services:
gitea:
image: gitea/gitea:latest
ports: ["3000:3000", "2222:22"]
volumes: [./gitea-data:/data]
environment:
GITEA__database__DB_TYPE: sqlite3
```
2. **Runner VM:**
```bash
# Install act_runner
wget https://gitea.com/gitea/act_runner/releases/latest/act_runner-linux-amd64
chmod +x act_runner-linux-amd64
./act_runner-linux-amd64 register --instance https://gitea.internal.sns --token <TOKEN>
./act_runner-linux-amd64 daemon
```
3. **KESTRA (when needed):**
```yaml
services:
kestra:
image: kestra/kestra:latest
ports: ["8080:8080"]
volumes: [./kestra-data:/app/storage]
```
4. **SSH access:** Add runner's SSH key to deploy targets' `authorized_keys`.
## Security Posture
- **Gitea access:** Behind Caddy + Authelia for web. SSH via ProxyJump only.
- **Runner isolation:** Dedicated VM, Docker executor (each job gets a fresh container).
- **Secrets:** Never in repos. Use Gitea Secrets for CI, Vaultwarden for everything else.
- **Container registry:** Private by default. No public pulls without explicit config.
- **Audit:** Gitea logs all repo events. Runner logs in Loki.
## Upgrade Path
- **Gitea cluster:** When you need HA or multiple runners for parallel builds.
- **Woodpecker CI:** If Gitea Actions limitations appear (it's younger than the
alternatives). Drop-in integration with Gitea.
- **Harbor:** Enterprise container registry if Gitea's built-in registry isn't sufficient
(vulnerability scanning, replication).
<!-- ponytail: SQLite for Gitea until performance degrades (~50 repos, ~5 users).
Ceiling: SQLite write contention under concurrent CI. Upgrade: PostgreSQL. -->

View File

@ -0,0 +1,108 @@
# Web Hosting Stack — SNS Digital
**Entity:** SNS Digital · **Status:** Buildable now
## What it is
A self-hosted web hosting platform for client sites and internal properties.
Caddy as reverse proxy/TLS terminator, static sites via Hugo or plain HTML,
dynamic sites via WordPress (when clients insist) or Ghost.
## Stack
| Component | Software | FOSS | Role |
|-----------|----------|------|------|
| Reverse proxy + TLS | Caddy 2 | Yes | Auto HTTPS, reverse proxy, static file server |
| Static site generator | Hugo | Yes | Fast builds, no runtime dependencies |
| CMS (when needed) | WordPress or Ghost | Yes | Client-managed content |
| Database | MariaDB | Yes | WordPress backend |
| Object storage | MinIO or S3 | Yes / Partial | Media uploads, large assets |
| DNS | Route53 (AWS) | No | Reliable, cheap, API-driven |
| Deployment | Git push → Gitea Actions → rsync/docker | Yes | Zero-touch deploys |
## Topology
```
Internet
┌─────────────────────────────────┐
│ Caddy (LXC on Proxmox) │ ← public IP via port-forward or Linode proxy
│ - TLS termination │
│ - Rate limiting │
│ - Static file serving │
│ - Reverse proxy to backends │
└──────────┬──────────────────────┘
┌─────┼──────────┐
▼ ▼ ▼
Hugo WordPress Ghost
(static) (VM/Docker) (Docker)
```
### Where it runs
| Site type | Runs on | Why |
|-----------|---------|-----|
| Static (Hugo) | Caddy serves files directly | No runtime, fastest possible |
| WordPress | Docker Compose VM on Proxmox | Isolation, easy backup/restore |
| Ghost | Docker Compose VM on Proxmox | Cleaner than WP for blogs |
| High-traffic / client SLA | Linode or AWS (CloudFront + S3) | Uptime guarantee > home connection |
## Build Steps
### Static site (Hugo — default choice)
1. Scaffold site: `hugo new site client-name`
2. Add theme as git submodule.
3. Push to Gitea repo.
4. Gitea Actions workflow: build → rsync to Caddy's serve directory.
5. Caddyfile entry:
```
client-name.com {
root * /srv/sites/client-name/public
file_server
encode gzip
}
```
### WordPress (when client requires it)
1. Clone Docker Compose template:
```yaml
services:
wordpress:
image: wordpress:6-apache
volumes: [./wp-content:/var/www/html/wp-content]
environment:
WORDPRESS_DB_HOST: db
WORDPRESS_DB_NAME: wp
db:
image: mariadb:11
volumes: [./data:/var/lib/mysql]
environment:
MARIADB_ROOT_PASSWORD_FILE: /run/secrets/db_root_pw
```
2. Caddy reverse proxies to `wordpress:80`.
3. Backup: PBS snapshots VM nightly + wp-content rsync to S3.
## Security Posture
- **Caddy handles TLS** — automatic cert renewal, no manual certs to manage.
- **No PHP on the proxy LXC.** WordPress runs isolated in its own VM/container.
- **WordPress hardening:** disable XML-RPC, limit login attempts (Fail2ban or WP plugin),
auto-update minor versions, restrict `wp-admin` to Tailscale IP if internal.
- **Rate limiting** in Caddy for login pages and API endpoints.
- **CSP headers** set per-site in Caddyfile.
## Upgrade Path
- **Cloudflare Tunnel:** If home IP isn't reliable enough for client SLAs, put Caddy
behind a Cloudflare tunnel (free tier, no public port needed).
- **Multi-node:** If hosting 20+ WordPress sites, move to a dedicated VM cluster with
shared MariaDB (Galera) and NFS/Ceph for wp-content.
- **Coolify or CapRover:** Self-hosted PaaS if you want a client-facing deploy dashboard.
YAGNI until you have 5+ active web clients.
<!-- ponytail: No PaaS dashboard until 5+ web clients. Ceiling: manual Caddyfile +
docker-compose management doesn't scale past ~20 sites. Upgrade: Coolify. -->

View File

@ -0,0 +1,104 @@
# Hybrid Networking — SNS Digital
**Entity:** SNS Digital · **Status:** Partially built (WireGuard/Tailscale active)
## What it is
The overlay network that connects on-prem Proxmox VMs to cloud providers securely.
Makes location transparent — a VM on Proxmox and a VPS on Linode appear on the same
private network.
## Stack
| Component | Software | FOSS | Role |
|-----------|----------|------|------|
| Mesh VPN | Tailscale | Partial (client FOSS, control plane proprietary) | Zero-config mesh for management access |
| Site-to-site | WireGuard | Yes | Persistent tunnels between sites (Proxmox ↔ Linode) |
| DNS | AdGuard Home (on-prem) + split horizon | Yes | Internal names resolve to private IPs |
| Bastion | Linode Nanode | N/A | Public SSH/WireGuard endpoint, ProxyJump target |
## Current Topology
```
┌──────────────┐ WireGuard ┌──────────────────┐
│ Proxmox │◄──────────────────────────►│ Linode Bastion │
│ 192.168.122.x│ (always-on) │ 172.238.163.85 │
└──────┬───────┘ └────────┬─────────┘
│ │
│ Tailscale mesh (management) │ Public IP
│ │
┌──────┴───────┐ ┌────────┴─────────┐
│ Workstation │ │ Internet/SSH │
│ (Sam's PC) │ │ clients │
└──────────────┘ └──────────────────┘
Racknerd boxes: WireGuard peer to Linode (hub-and-spoke)
AWS VPC: future — VPN Gateway or WireGuard on EC2 when needed
```
## Design Decisions
1. **WireGuard for infrastructure, Tailscale for people.** WireGuard tunnels are
persistent, config-file driven, Ansible-managed. Tailscale is for ad-hoc
management access from laptops/phones.
2. **Linode is the hub.** All WireGuard peers connect to Linode. On-prem and Racknerd
boxes don't need public IPs — they reach each other through the hub.
3. **No split tunneling for services.** Only management traffic goes over the mesh.
Service traffic (web, API) goes through the public reverse proxy path.
4. **ProxyJump, not port forwarding.** SSH to internal VMs uses `ProxyJump linode`
(already in your SSH config). No ports exposed on the bastion beyond SSH + WireGuard.
## Build Steps (WireGuard hub-and-spoke)
1. **Linode (hub):**
```ini
# /etc/wireguard/wg0.conf
[Interface]
Address = 10.10.0.1/24
ListenPort = 51820
PrivateKey = <hub-private-key>
[Peer] # Proxmox
PublicKey = <proxmox-public-key>
AllowedIPs = 10.10.0.2/32, 192.168.122.0/24
[Peer] # Racknerd1
PublicKey = <rn1-public-key>
AllowedIPs = 10.10.0.3/32
```
2. **Proxmox (spoke):**
```ini
[Interface]
Address = 10.10.0.2/24
PrivateKey = <proxmox-private-key>
[Peer] # Linode hub
PublicKey = <hub-public-key>
Endpoint = 172.238.163.85:51820
AllowedIPs = 10.10.0.0/24
PersistentKeepalive = 25
```
3. **Enable IP forwarding** on Linode: `net.ipv4.ip_forward = 1`
4. **Firewall:** UFW on Linode allows UDP 51820 inbound. Forward rules for inter-spoke.
5. **DNS:** AdGuard on-prem resolves `*.wg.internal` to 10.10.0.x addresses.
## Security Posture
- **WireGuard:** Authenticated encryption (ChaCha20 + Poly1305). No pre-shared keys
needed for this threat model, but can add for post-quantum hedge.
- **Bastion exposure:** Only SSH (22/tcp) + WireGuard (51820/udp) on public IP.
Everything else is default-deny.
- **Key rotation:** WireGuard keys rotated annually (low urgency — Noise protocol
provides forward secrecy per session).
- **No cloud provider VPN dependencies.** Pure WireGuard means portable across providers.
## Upgrade Path
- **Headscale:** Self-hosted Tailscale control plane if the proprietary coordination
server becomes a concern.
- **AWS Site-to-Site VPN:** When a client VPC needs persistent connectivity and
WireGuard-on-EC2 isn't enterprise-palatable.
- **Multi-hub:** Add a second WireGuard hub (Racknerd or second Linode) for redundancy
if the single Linode becomes a SPOF.

View File

@ -0,0 +1,70 @@
# Provider Roles & Allocation — SNS Digital
**Entity:** SNS Digital · **Status:** Active (current layout)
## What it is
Defines what each cloud/VPS provider is used for, why, and when to pick one over another.
Keeps spend intentional and prevents provider sprawl.
## Provider Matrix
| Provider | Role | Monthly Budget | Use When |
|----------|------|---------------|----------|
| **Linode (Akamai)** | Bastion / jump host, WireGuard relay, light public-facing services | ~$520 | Need a stable public IP, low-latency relay to on-prem, or a small always-on service |
| **Racknerd** | Cheap VPS for non-critical / experimental workloads | ~$1030 total | Disposable boxes, testing, overflow capacity, geo-diversity |
| **AWS** | Enterprise workloads, managed services (S3, Route53, SES, Lambda) | Pay-as-you-go | Client requires AWS, need a managed service with no good self-hosted equivalent, or enterprise compliance |
## Current Allocation
```
Linode ($5 Nanode)
├── sam@172.238.163.85
├── Role: SSH bastion, WireGuard endpoint, Tailscale relay
├── ProxyJump target for all on-prem VMs (192.168.122.x)
└── Minimal attack surface: SSH + WireGuard only
Racknerd1 ($?)
├── root@172.245.72.108
└── Role: TBD / available capacity
Racknerd2 ($?)
├── root@192.3.165.113
└── Role: TBD / available capacity
AWS (free tier + selective services)
├── Route53: DNS hosting (cheap, reliable, no self-host headache)
├── S3: offsite backup target (encrypted, lifecycle policies)
├── SES: transactional email (when Google Workspace SMTP isn't appropriate)
└── Future: client-facing infra when contracts require it
```
## Decision: When to go cloud vs. on-prem
```
Is it client-facing with an SLA you can't meet from home?
YES → Cloud (Linode or AWS depending on complexity)
NO →
Does it need a public IP 24/7 with guaranteed uptime?
YES → Linode (simple) or AWS (complex)
NO →
Is it throwaway / experimental?
YES → Racknerd
NO → On-prem Proxmox
```
## Cost Rules
1. **No idle AWS resources.** If it's not serving traffic or storing data, shut it down.
2. **Linode stays small.** It's a relay, not a compute platform. If workloads grow,
they belong on-prem or on a dedicated Racknerd box.
3. **Racknerd is disposable.** Don't put anything there that can't be rebuilt from
Ansible in 15 minutes.
4. **AWS reserved instances / savings plans:** Only after 3+ months of steady usage
proves the workload is permanent.
## Security Notes
- Linode bastion: SSH key-only, UFW deny-all except 22 + WireGuard port.
- Racknerd boxes: same hardening playbook as on-prem. No secrets stored locally.
- AWS: IAM least-privilege, no root keys, MFA on console, service roles over user keys.

View File

@ -0,0 +1,57 @@
# Container Strategy — SNS Networking
**Entity:** SNS Networking · **Status:** Buildable now
## What it is
Guidelines for when to use LXC containers vs VMs vs Docker on Proxmox, keeping
things simple and predictable.
## Decision Tree
```
Need full kernel isolation or non-Linux OS?
YES → VM (KVM)
NO →
Is it a single long-running daemon (DNS, proxy, small app)?
YES → LXC container (Proxmox-native, lowest overhead)
NO →
Is it a multi-container app with a compose file?
YES → VM running Docker + Compose
NO → LXC container
```
## Rules
1. **LXC is default** for single-service workloads. Lower RAM, faster boot, native
Proxmox backup/snapshot support.
2. **Docker inside a VM** (not inside LXC) when the app ships as a compose stack.
Avoids the nested-container headaches of Docker-in-LXC.
3. **No Kubernetes.** Not until there are 20+ services that need orchestration and
auto-scaling. The ceiling is named; the upgrade path is k3s on dedicated VMs.
4. **One service per container/VM.** No multi-app VMs except dev/test throwaway boxes.
5. **Naming:** `{service}-{env}` — e.g., `gitea-prod`, `caddy-prod`, `monitoring-dev`.
## LXC Template Defaults
- **OS:** Debian 12 (official Proxmox template)
- **Resources:** 1 vCPU, 512MB RAM, 8GB disk (grow as needed)
- **Network:** static IP on service VLAN, gateway to Caddy
- **Security:** unprivileged container, nesting disabled unless Docker required
## VM Template Defaults
- **OS:** Debian 12 cloud-init (template ID 9000)
- **Resources:** 2 vCPU, 2GB RAM, 32GB disk
- **Network:** same as LXC
- **Agent:** qemu-guest-agent installed for Proxmox integration
## Upgrade Path
- **k3s:** When service count exceeds ~20 or you need rolling deploys, stand up
3 k3s nodes (VMs on Proxmox) and migrate Docker Compose apps to Helm charts.
- **Podman:** Drop-in Docker replacement if Docker licensing ever becomes a concern
(it won't for self-hosted, but Podman is rootless by default — security win).
<!-- ponytail: No k8s until 20+ services. Ceiling: manual docker-compose deploys
don't scale past ~20 without toil. Upgrade: k3s on 3 dedicated VMs. -->

View File

@ -0,0 +1,98 @@
# Host Hardening Baseline — SNS Networking
**Entity:** SNS Networking · **Status:** Buildable now (Ansible playbook)
## What it is
The minimum security posture applied to every Linux host — on-prem VM, LXC, or
cloud VPS — before it does anything else. This is the Ansible "base" role that
runs first on every new machine.
## Stack
| Component | Software | FOSS | Role |
|-----------|----------|------|------|
| Firewall | UFW (iptables frontend) | Yes | Default-deny inbound, explicit allow |
| Brute-force protection | Fail2ban | Yes | SSH + web login jail |
| SSH hardening | OpenSSH (config only) | Yes | Key-only, no root, no password |
| Auto-updates | unattended-upgrades (Debian) | Yes | Security patches only |
| Audit logging | auditd | Yes | File access, privilege escalation events |
| Rootkit detection | rkhunter | Yes | Weekly scan, email on findings |
## The Playbook (what it does)
```yaml
# roles/base-hardening/tasks/main.yml (conceptual)
- name: SSH hardening
# PermitRootLogin no
# PasswordAuthentication no
# PubkeyAuthentication yes
# MaxAuthTries 3
# AllowUsers sam
- name: UFW default deny
# Default incoming: deny
# Default outgoing: allow
# Allow: SSH (22/tcp) from Tailscale/WireGuard subnet only
- name: Fail2ban SSH jail
# maxretry: 3
# bantime: 3600
# findtime: 600
- name: Unattended upgrades (security only)
# Automatic-Reboot: false (manual kernel reboots)
- name: Auditd rules
# Watch /etc/passwd, /etc/shadow, /etc/sudoers
# Log all sudo usage
# Log failed file access attempts
- name: Disable unused services
# Stop & mask: cups, avahi-daemon, bluetooth (if present)
- name: Sysctl hardening
# net.ipv4.conf.all.rp_filter = 1
# net.ipv4.icmp_echo_ignore_broadcasts = 1
# net.ipv4.conf.all.accept_redirects = 0
# net.ipv4.conf.all.send_redirects = 0
# kernel.randomize_va_space = 2
```
## Per-Host Firewall Rules
| Host type | Inbound allowed | Notes |
|-----------|----------------|-------|
| All hosts | SSH from 10.10.0.0/24 (WireGuard) | Management only over VPN |
| Web-facing (Caddy) | 80, 443 from 0.0.0.0/0 | Public web traffic |
| Bastion (Linode) | 22, 51820/udp from 0.0.0.0/0 | SSH + WireGuard |
| Internal services | App port from service VLAN only | No direct internet access |
| Proxmox host | 8006 from Tailscale only | Web UI never on public IP |
## Build Steps
1. Write Ansible role `roles/base-hardening/` with the above tasks.
2. Add to `site.yml` as the first role for all host groups.
3. Run against all existing hosts: `ansible-playbook site.yml --tags hardening`
4. Verify: `ssh root@host` should fail. `ssh sam@host` with key should work.
5. Verify: `nmap -sS host` from outside WireGuard should show only allowed ports.
## Security Posture
- **Default deny.** Nothing gets in unless explicitly allowed.
- **No passwords anywhere.** SSH key-only. Service accounts use tokens or certs.
- **Audit trail.** Every sudo, every sensitive file access logged.
- **Automatic patching.** Security updates apply daily without manual intervention.
Kernel updates require manual reboot (scheduled maintenance window).
## Upgrade Path
- **CIS Benchmark compliance:** Run `cis-cat` scanner and close gaps for client
environments that require formal compliance.
- **OSSEC/Wazuh:** When you need centralized security event management across 10+ hosts.
- **SELinux/AppArmor:** Enforce MAC policies on high-value services (currently not
enabled — adds complexity without proportional gain at this scale).
<!-- ponytail: No SELinux/AppArmor yet. Ceiling: DAC-only can't contain a compromised
service from lateral movement on the same host. Upgrade: AppArmor profiles for
Caddy, WordPress, Gitea when client compliance requires it. -->

View File

@ -0,0 +1,128 @@
# IDS & Centralized Logging — SNS Networking
**Entity:** SNS Networking · **Status:** Buildable now
## What it is
Intrusion detection and centralized log aggregation so you know when something
goes wrong before a client tells you. Lightweight — no SIEM until the scale demands it.
## Stack
| Component | Software | FOSS | Role |
|-----------|----------|------|------|
| Network IDS | Suricata | Yes | Packet inspection on Proxmox bridge |
| Host IDS | AIDE | Yes | File integrity monitoring (detect unauthorized changes) |
| Log aggregation | Loki (Grafana) | Yes | Centralized logs, queryable |
| Log shipper | Promtail / Alloy | Yes | Ships logs from all hosts to Loki |
| Alerting | Grafana Alerting | Yes | Fires on log patterns + IDS events |
| Rootkit scan | rkhunter | Yes | Weekly cron, email on detection |
## Architecture
```
┌────────────┐ ┌────────────┐ ┌────────────┐
│ Host A │ │ Host B │ │ Host C │
│ promtail │ │ promtail │ │ promtail │
└─────┬──────┘ └─────┬──────┘ └─────┬──────┘
│ │ │
└────────────────┼────────────────┘
┌─────────────────┐
│ Loki (VM) │
│ + Grafana │
└─────────────────┘
Grafana Alerting → Email / Ntfy / Slack
```
Suricata runs on the Proxmox host, tapping `vmbr1` (service bridge) in AF_PACKET mode.
Alerts feed into Loki via promtail watching Suricata's `eve.json`.
## What Gets Logged
| Source | What | Retention |
|--------|------|-----------|
| SSH | All auth attempts (success + fail) | 90 days |
| UFW | All denied packets | 30 days |
| Fail2ban | All bans/unbans | 90 days |
| Caddy | Access logs (all requests) | 30 days |
| Suricata | Alerts (eve.json) | 90 days |
| auditd | Sudo, sensitive file access | 90 days |
| Systemd journal | Service starts/stops/crashes | 14 days |
## Build Steps
1. **Loki + Grafana:** Deploy as Docker Compose on a monitoring VM.
```yaml
services:
loki:
image: grafana/loki:latest
volumes: [./loki-data:/loki]
command: -config.file=/etc/loki/local-config.yaml
grafana:
image: grafana/grafana:latest
volumes: [./grafana-data:/var/lib/grafana]
```
2. **Promtail on each host:** Install via apt or binary. Config:
```yaml
clients:
- url: http://loki.internal.sns:3100/loki/api/v1/push
scrape_configs:
- job_name: syslog
static_configs:
- targets: [localhost]
labels:
job: syslog
host: ${HOSTNAME}
journal:
labels:
job: journal
```
3. **Suricata on Proxmox host:**
```bash
apt install suricata
suricata-update # download rulesets
# /etc/suricata/suricata.yaml: af-packet interface = vmbr1
systemctl enable --now suricata
```
4. **AIDE on critical hosts:**
```bash
apt install aide
aide --init
mv /var/lib/aide/aide.db.new /var/lib/aide/aide.db
# Cron: daily `aide --check` → email diff
```
5. **Grafana alerts:** Create alert rules for:
- Fail2ban ban count > 10/hour
- Suricata alert severity >= 2
- SSH root login attempt (should never happen)
- AIDE file change on critical paths
## Security Posture
- **Detection, not prevention** (at this layer). Prevention is UFW + Fail2ban.
Suricata alerts tell you something got past the first layer.
- **File integrity (AIDE)** catches rootkits, unauthorized config changes, backdoors.
- **Log immutability:** Loki is write-once from the host perspective. Compromising a
host doesn't let you erase your tracks from Loki (different VM, different creds).
- **Retention is cost-bounded.** 90 days is enough for incident response without
filling disks.
## Upgrade Path
- **Wazuh:** Full HIDS + SIEM + compliance dashboards when client contracts require
formal security monitoring (SOC2, etc.).
- **CrowdSec:** Collaborative IDS — share blocklists with the community. Drop-in
alongside Suricata.
- **Elasticsearch/OpenSearch:** If Loki's label-based querying isn't sufficient for
complex correlation. YAGNI until you have a dedicated security analyst.
<!-- ponytail: No SIEM until client contracts require compliance reporting.
Ceiling: Loki + Suricata can't do cross-host correlation or automated response.
Upgrade: Wazuh for HIDS+SIEM or CrowdSec for collaborative blocking. -->

View File

@ -0,0 +1,78 @@
# Proxmox Base Cluster — SNS Networking
**Entity:** SNS Networking · **Status:** Buildable now
## What it is
A single-node (expandable to cluster) Proxmox VE hypervisor that hosts all on-prem
VMs and LXC containers. This is the foundation — everything else in `infra/` runs
on top of this or connects to it.
## Stack
| Component | Software | FOSS | Notes |
|-----------|----------|------|-------|
| Hypervisor | Proxmox VE 8.x | Yes | Debian-based, KVM + LXC |
| Storage | ZFS (local) | Yes | Mirror or RAIDZ1 depending on disk count |
| Networking | Linux bridge + VLANs | Yes | `vmbr0` = management, `vmbr1` = services |
| Backup | Proxmox Backup Server (PBS) | Yes | Separate VM or separate box |
| Templates | Cloud-init images (Debian 12, Rocky 9, Ubuntu 24.04) | Yes | Pulled and prepped with `virt-customize` |
| Automation | Ansible + Proxmox API | Yes | `community.general.proxmox*` modules |
## Topology
```
┌─────────────────────────────────────────────┐
│ Proxmox VE Host (bare metal) │
│ │
│ vmbr0 (mgmt, VLAN 1) vmbr1 (services, VLAN 10+) │
│ ├── LXC: dns (Pi-hole/AdGuard) │
│ ├── LXC: nginx-proxy (reverse proxy) │
│ ├── VM: gitea (code hosting) │
│ ├── VM: monitoring (Prometheus+Grafana) │
│ ├── VM: app-01 (general workloads) │
│ └── VM: pbs (Proxmox Backup Server) │
│ │
│ ZFS pool: rpool (OS) + datapool (VMs) │
└─────────────────────────────────────────────┘
├── WireGuard tunnel → Linode (bastion)
└── Tailscale mesh (management access)
```
## Build Steps
1. **Install Proxmox VE** on bare metal (Debian netinstall + Proxmox repo, or ISO).
2. **Configure ZFS** — mirror for 2 disks, RAIDZ1 for 3+. Separate `rpool` (OS) from
`datapool` (VM storage).
3. **Networking** — create `vmbr0` (management) and `vmbr1` (service VLAN). Tag VLANs
at the switch if physical segregation exists.
4. **Disable enterprise repo, enable no-subscription repo** — remove nag popup.
5. **Cloud-init templates** — download base images, convert to templates:
```bash
wget https://cloud.debian.org/images/cloud/bookworm/latest/debian-12-generic-amd64.qcow2
qm create 9000 --memory 2048 --net0 virtio,bridge=vmbr1 --name debian12-template
qm importdisk 9000 debian-12-generic-amd64.qcow2 datapool
qm set 9000 --scsihw virtio-scsi-pci --scsi0 datapool:vm-9000-disk-0
qm set 9000 --ide2 datapool:cloudinit --boot c --bootdisk scsi0
qm template 9000
```
6. **PBS** — install Proxmox Backup Server (separate VM or LXC). Point PVE's storage
config at it. Schedule nightly backups.
7. **Ansible bootstrap** — run base hardening playbook against all new VMs (SSH keys,
UFW, fail2ban, unattended-upgrades).
## Security Posture
- **Management access:** Tailscale or WireGuard only. Proxmox web UI not exposed to WAN.
- **SSH:** key-only, no password auth, port 22 behind Tailscale/WireGuard.
- **Firewall:** Proxmox host firewall enabled. Default deny inbound. Allow only
Tailscale/WireGuard + VLAN inter-traffic as needed.
- **Updates:** `apt` auto-security-updates on host. Manual kernel updates (reboot required).
- **Backups:** PBS with encryption at rest. Retention: 7 daily, 4 weekly, 3 monthly.
## Upgrade Path
- **Multi-node cluster:** Add a second Proxmox host, enable HA with Ceph or shared ZFS-over-iSCSI.
- **Ceph storage:** When local ZFS capacity or redundancy isn't enough.
- **SDN:** Proxmox SDN module for VXLAN overlays if VLAN count gets unmanageable.

View File

@ -0,0 +1,59 @@
# Self-Hosted Application Stack — SNS Networking
**Entity:** SNS Networking · **Status:** Buildable now
## What it is
A standard set of self-hosted services that replace SaaS for internal ops and
client deployments. Each runs in its own LXC container or VM on Proxmox.
## Service Catalog
| Service | Software | Runs in | FOSS | Replaces |
|---------|----------|---------|------|----------|
| DNS + Ad blocking | AdGuard Home | LXC | Yes | Cloudflare DNS / Pi-hole |
| Reverse proxy | Caddy | LXC | Yes | Nginx Proxy Manager (simpler TLS) |
| File sync | Nextcloud | VM | Yes | Google Drive / Dropbox |
| Passwords | Vaultwarden | LXC | Yes | Bitwarden cloud |
| Wiki / Notes | Outline or BookStack | LXC | Yes | Notion / Confluence |
| Identity (SSO) | Authelia | LXC | Yes | Okta / Auth0 |
| Container registry | Gitea (built-in) | VM | Yes | Docker Hub / ECR |
## Topology
All services sit on `vmbr1` (service VLAN). Caddy is the single ingress point
with automatic Let's Encrypt certs. Internal services use `*.internal.snsnetlabs.com`
via split DNS (AdGuard returns local IPs).
```
Internet → Linode (bastion/WireGuard) → Proxmox vmbr1
Caddy (reverse proxy)
┌──────────┬───────────┼───────────┬──────────┐
Nextcloud Vaultwarden Outline Authelia Gitea
```
## Build Pattern (per service)
1. Clone Debian 12 cloud-init template.
2. Set hostname, static IP on service VLAN, SSH key.
3. Run Ansible role for the specific app (Docker Compose or native install).
4. Add Caddyfile entry for reverse proxy + TLS.
5. Add DNS record in AdGuard (local) or public DNS if external.
6. Add to PBS backup schedule.
## Security Posture
- **Authelia** gates all web UIs behind 2FA (TOTP). No service exposed without auth.
- **Caddy** handles TLS termination — no self-signed certs internally.
- **Vaultwarden** is the only password store; all service credentials live here.
- **Network:** services can't reach the management VLAN. Inter-service traffic is
explicit (e.g., Nextcloud → Authelia for SSO, nothing else).
## Upgrade Path
- **LDAP/Keycloak:** If client count grows beyond what Authelia file-based users handles,
swap to Keycloak + LDAP backend.
- **High availability:** Run critical services (Caddy, Vaultwarden, Authelia) as HA pairs
behind a keepalived VIP.

View File

@ -0,0 +1,83 @@
# VPN & Access Control — SNS Networking
**Entity:** SNS Networking · **Status:** Partially built (WireGuard + Tailscale active)
## What it is
Zero-trust-lite access model. No service is reachable from the public internet unless
it explicitly needs to be. All management access goes through VPN. All web UIs gated
by Authelia 2FA.
## Layers
```
Layer 1: Network (WireGuard / Tailscale)
└── Can you even reach the port?
Layer 2: Authentication (Authelia + SSH keys)
└── Who are you?
Layer 3: Authorization (per-service ACLs)
└── Are you allowed to do this?
```
## Access Matrix
| What | Who | How they get in |
|------|-----|-----------------|
| Proxmox Web UI | Sam | Tailscale IP → port 8006 |
| SSH to any host | Sam | WireGuard/Tailscale → ProxyJump |
| Gitea web | Sam + future devs | Caddy → Authelia 2FA → Gitea |
| Monitoring (Grafana) | Sam | Caddy → Authelia 2FA → Grafana |
| Client websites | Public | Caddy → site (no auth) |
| Client WordPress admin | Client | Caddy → Authelia or IP-restrict |
| Vaultwarden | Sam | Caddy → Authelia 2FA → Vaultwarden |
## Authelia Configuration (key decisions)
- **Backend:** file-based users (YAML). Swap to LDAP when user count > 10.
- **2FA:** TOTP (Authelia built-in). No hardware key requirement yet.
- **Session:** 12h idle timeout, 7d absolute timeout.
- **Policy:** two_factor for all protected domains. No single_factor exceptions.
- **Integration:** Caddy `forward_auth` directive per-site.
```
# Caddyfile pattern for Authelia-protected service
grafana.internal.sns {
forward_auth authelia:9091 {
uri /api/authz/forward-auth
copy_headers Remote-User Remote-Groups Remote-Email
}
reverse_proxy grafana:3000
}
```
## Certificate Management
| Scope | Tool | Method |
|-------|------|--------|
| Public sites | Caddy (built-in ACME) | Let's Encrypt, auto-renewal |
| Internal services | Caddy (internal CA) or Step-CA | Caddy can issue self-signed internal certs automatically |
| WireGuard | Native (Noise protocol) | No PKI needed — public key exchange |
| SSH | OpenSSH keys | Ed25519 keys, no CA (until 20+ hosts) |
**Future:** SSH Certificate Authority (step-ca) when managing keys for 20+ hosts
becomes unwieldy.
## Security Posture
- **No service exposed without auth** (except public websites by design).
- **2FA mandatory** on every web UI — no exceptions.
- **Session tokens short-lived** — 12h idle forces re-auth.
- **No VPN split tunneling for management** — if you're on the mesh, you can reach
management ports. If you're not, you can't. Binary.
- **Key rotation:** SSH keys rotated annually. WireGuard keys annually.
Authelia TOTP secrets only on device change.
## Upgrade Path
- **Keycloak + LDAP:** When you have employees or multiple clients needing SSO.
- **Hardware keys (WebAuthn):** When the threat model justifies it (high-value targets).
- **SSH CA (step-ca):** When managing individual authorized_keys files across 20+ hosts
becomes toil.
- **Mutual TLS (mTLS):** For service-to-service auth if zero-trust goes full-depth.

View File

@ -0,0 +1,114 @@
# Backup Strategy — SNS Support
**Entity:** SNS Support · **Status:** Buildable now
## What it is
3-2-1 backup strategy using FOSS tools. Three copies, two media types, one offsite.
Every VM and critical data set has a defined backup path and tested restore procedure.
## Stack
| Component | Software | FOSS | Role |
|-----------|----------|------|------|
| VM/container backup | Proxmox Backup Server (PBS) | Yes | Incremental, deduplicated VM backups |
| File-level backup | restic | Yes | Encrypted, deduplicated file backups |
| Offsite target | AWS S3 (Glacier) | No | Encrypted offsite copies |
| Local target | PBS datastore (ZFS) | Yes | Fast restores, primary backup |
| Scheduling | PBS built-in + cron | Yes | Nightly automated runs |
| Verification | PBS verify + restic check | Yes | Catch corruption early |
## 3-2-1 Implementation
```
Copy 1: Live data (Proxmox VM disks, app databases)
Copy 2: PBS on-prem (separate ZFS pool or separate physical host)
Copy 3: S3 Glacier (encrypted, offsite)
```
| Data type | Copy 1 | Copy 2 (local) | Copy 3 (offsite) |
|-----------|--------|----------------|-------------------|
| VMs + LXC | Proxmox host | PBS (nightly snapshot) | PBS → S3 sync (weekly) |
| Databases (MariaDB, SQLite) | Running instance | mysqldump → restic → local | restic → S3 |
| Git repos (Gitea) | Gitea VM | PBS snapshot + Gitea dump | restic → S3 |
| Config/secrets | Vaultwarden | PBS snapshot | restic → S3 (encrypted at rest) |
| Static sites | Caddy VM | PBS snapshot | Git repo is the backup |
## Retention Policy
| Location | Daily | Weekly | Monthly | Max age |
|----------|-------|--------|---------|---------|
| PBS (local) | 7 | 4 | 3 | ~4 months |
| S3 Glacier | — | 4 | 6 | ~7 months |
| restic (local) | 7 | 4 | 6 | ~7 months |
## Build Steps
### PBS (primary — already referenced in sns-systems)
1. Dedicated VM or physical host with its own ZFS pool.
2. Add as storage in Proxmox: Datacenter → Storage → Proxmox Backup Server.
3. Create backup jobs: nightly at 02:00, all VMs/CTs in the pool.
4. Enable verification: weekly verify job to catch bit rot.
5. Encryption: PBS supports client-side encryption — enable for offsite copies.
### restic (file-level + offsite)
```bash
# Initialize S3 repo (one-time)
export AWS_ACCESS_KEY_ID=<backup-writer-key>
export AWS_SECRET_ACCESS_KEY=<secret>
restic -r s3:s3.amazonaws.com/sns-backups-<account>/restic init
# Nightly backup (cron)
restic -r s3:... backup /srv/critical-data \
--exclude-caches \
--tag nightly
# Prune old snapshots
restic -r s3:... forget \
--keep-daily 7 --keep-weekly 4 --keep-monthly 6 \
--prune
```
### Database dumps (pre-backup hook)
```bash
#!/bin/bash
# /etc/cron.d/db-backup (runs before restic)
mysqldump --all-databases | gzip > /srv/backups/mysql/all-$(date +%F).sql.gz
# Restic picks up /srv/backups/ in its nightly run
```
## Restore Testing
**Monthly:** Restore one random VM from PBS to a temporary ID. Boot it, verify
services start. Destroy the test restore.
**Quarterly:** Restore from S3/restic to a clean VM. Verify data integrity end-to-end.
Document restore test results in `projects/` or a simple log file.
## Security Posture
- **Encryption at rest:** PBS supports encryption. restic encrypts by default (AES-256).
S3 bucket has SSE-S3 enabled as a second layer.
- **Backup credentials isolated:** `backup-writer` IAM role can only PutObject to the
backup bucket. Cannot list, read, or delete — prevents ransomware from wiping backups.
- **S3 Object Lock (future):** Enable when client data is stored — makes backups
immutable for the retention period.
- **PBS access:** Only Proxmox host can reach PBS. No other host has write access.
- **restic repo password:** Stored in Vaultwarden, not in cron scripts (use a
password file with 600 permissions owned by root).
## Upgrade Path
- **S3 Object Lock + Compliance mode:** When you need immutable backups for client
contracts or compliance.
- **PBS replication:** Second PBS at a different site for faster disaster recovery
(instead of restoring from S3).
- **Velero:** If/when Kubernetes enters the picture, for persistent volume backups.
<!-- ponytail: No immutable backups yet. Ceiling: a compromised root on the Proxmox
host could delete PBS datastore. Upgrade: S3 Object Lock + separate PBS with
different credentials. -->

View File

@ -0,0 +1,145 @@
# Monitoring & Alerting — SNS Support
**Entity:** SNS Support · **Status:** Buildable now
## What it is
Centralized monitoring for all infrastructure — on-prem and cloud. Know when
something is down before anyone reports it. This is what makes managed services
possible.
## Stack
| Component | Software | FOSS | Role |
|-----------|----------|------|------|
| Metrics collection | Prometheus | Yes | Scrapes targets, stores time-series |
| Visualization | Grafana | Yes | Dashboards, alerting UI |
| Node metrics | node_exporter | Yes | CPU, RAM, disk, network per host |
| Container metrics | cAdvisor | Yes | Docker/LXC resource usage |
| Uptime / HTTP checks | Uptime Kuma | Yes | External endpoint monitoring, status pages |
| Alerting | Grafana Alerting | Yes | Routes alerts to email/Ntfy/Slack |
| Notifications | Ntfy | Yes | Self-hosted push notifications (phone/desktop) |
## Architecture
```
┌────────────┐ ┌────────────┐ ┌────────────┐ ┌────────────┐
│ Host A │ │ Host B │ │ Host C │ │ Linode │
│ node_exp │ │ node_exp │ │ node_exp │ │ node_exp │
└─────┬──────┘ └─────┬──────┘ └─────┬──────┘ └─────┬──────┘
│ │ │ │
└────────────────┼────────────────┼────────────────┘
┌─────────────────┐
│ Prometheus │ ← VM on Proxmox
│ (scrapes all) │
└────────┬────────┘
┌────────┴────────┐
│ Grafana │
│ - Dashboards │
│ - Alert rules │
└────────┬────────┘
┌────────┴────────┐
│ Ntfy │ ← Push notifications to phone
└─────────────────┘
┌─────────────────┐
│ Uptime Kuma │ ← Separate LXC, checks from outside
│ (HTTP checks) │
└─────────────────┘
```
## What Gets Monitored
| Category | Metrics | Alert threshold |
|----------|---------|-----------------|
| **Host health** | CPU, RAM, disk, load | Disk > 85%, RAM > 90%, load > 4x cores |
| **Service up/down** | systemd unit status | Any critical service down > 2 min |
| **Network** | Interface errors, bandwidth | Sustained > 80% capacity |
| **HTTP endpoints** | Response time, status code | > 5s response or non-2xx |
| **SSL certs** | Days until expiry | < 14 days (Caddy should auto-renew, this catches failures) |
| **Backups** | Last successful PBS backup age | > 26 hours (missed nightly window) |
| **Docker** | Container restarts, OOM kills | Any restart loop or OOM |
| **WireGuard** | Peer last handshake age | > 5 minutes (tunnel down) |
## Build Steps
1. **Monitoring VM:** Clone Debian 12 template. 2 vCPU, 4GB RAM, 50GB disk.
2. **Prometheus + Grafana (Docker Compose):**
```yaml
services:
prometheus:
image: prom/prometheus:latest
volumes:
- ./prometheus.yml:/etc/prometheus/prometheus.yml
- prom-data:/prometheus
command: --storage.tsdb.retention.time=90d
grafana:
image: grafana/grafana:latest
volumes: [grafana-data:/var/lib/grafana]
environment:
GF_SECURITY_ADMIN_PASSWORD__FILE: /run/secrets/grafana_pw
```
3. **node_exporter on every host:**
```bash
apt install prometheus-node-exporter
# Or binary install + systemd unit
# Listens on :9100, scraped by Prometheus
```
4. **Prometheus scrape config:**
```yaml
# prometheus.yml
scrape_configs:
- job_name: nodes
static_configs:
- targets:
- gitea.internal.sns:9100
- caddy.internal.sns:9100
- linode.wg.internal:9100
# ... all hosts
```
5. **Uptime Kuma (separate LXC):**
```bash
docker run -d --name uptime-kuma -p 3001:3001 \
-v uptime-kuma:/app/data louislam/uptime-kuma
```
Add monitors for all public endpoints + internal services.
6. **Ntfy (self-hosted push):**
```bash
docker run -d --name ntfy -p 8080:80 \
-v ntfy-cache:/var/cache/ntfy binwiederhier/ntfy serve
```
Grafana alert contact point → Ntfy webhook → phone notification.
7. **Grafana dashboards:** Import community dashboards:
- Node Exporter Full (ID: 1860)
- Docker/cAdvisor (ID: 14282)
- Custom: SNS Overview (service status grid)
## Security Posture
- **Prometheus/Grafana:** Behind Authelia 2FA via Caddy. Not exposed publicly.
- **node_exporter:** Binds to service VLAN IP only. No internet-facing metrics endpoints.
- **Uptime Kuma:** Can optionally expose a public status page per-client (read-only).
- **Ntfy:** Private topic names. No unauthenticated publish.
- **Data retention:** 90 days for metrics. Enough for trend analysis without filling disks.
## Upgrade Path
- **Thanos / Mimir:** When Prometheus needs long-term storage or multi-cluster federation.
YAGNI until metrics volume overwhelms a single Prometheus instance.
- **VictoriaMetrics:** Drop-in Prometheus replacement with better compression and
performance if retention or scrape targets grow significantly.
- **PagerDuty / Opsgenie:** When you have SLA contracts that need formal on-call rotation.
Until then, Ntfy to your phone is sufficient.
<!-- ponytail: Single Prometheus, no HA. Ceiling: single-node Prometheus handles ~1M
active series easily. Upgrade: VictoriaMetrics or Thanos when that's exceeded. -->

View File

@ -0,0 +1,140 @@
# RMM & Patch Management — SNS Support
**Entity:** SNS Support · **Status:** Buildable now
## What it is
Remote monitoring and management (RMM) for maintaining hosts without SSH-ing into
each one manually. Patch management ensures security updates land promptly.
This is the recurring-revenue engine — what you sell as "managed services."
## Stack
| Component | Software | FOSS | Role |
|-----------|----------|------|------|
| RMM / remote management | MeshCentral | Yes | Remote access, terminal, file transfer, inventory |
| Patch management | unattended-upgrades + Ansible | Yes | Auto security patches + scheduled full updates |
| Configuration drift | Ansible (periodic runs) | Yes | Detect and correct drift from desired state |
| Inventory | MeshCentral + Ansible facts | Yes | Hardware/software inventory per host |
| Ticketing (future) | Zammad or FreeScout | Yes | Client-facing ticket system when needed |
## Architecture
```
┌─────────────────────────────────┐
│ MeshCentral (VM on Proxmox) │
│ - Web UI (Authelia-gated) │
│ - Agent management │
│ - Remote terminal/desktop │
└──────────────┬──────────────────┘
┌──────────┼──────────┬──────────────┐
▼ ▼ ▼ ▼
Host A Host B Host C Client PC
(agent) (agent) (agent) (agent)
```
## MeshCentral
**Why MeshCentral over commercial RMM (ConnectWise, Datto, NinjaRMM):**
- Fully FOSS (Apache 2.0 license)
- Self-hosted — no per-device SaaS fees
- Supports Linux, Windows, macOS agents
- Web-based remote desktop/terminal
- Device groups, user permissions, audit logging
- Good enough for 150 managed endpoints
**Limitations (the ceiling):**
- No built-in patch management (that's Ansible's job)
- No PSA/ticketing integration (add Zammad when needed)
- Single-node only (no built-in HA)
## Patch Strategy
| Patch type | Method | Timing | Approval |
|------------|--------|--------|----------|
| Security (critical) | unattended-upgrades | Daily, automatic | None needed |
| Security (kernel) | Ansible playbook | Weekly maintenance window | Auto (reboot scheduled) |
| Feature / major version | Ansible playbook | Monthly, manual trigger | Sam approves |
| Application updates | Docker image pull + restart | Per-app schedule | CI/CD pipeline |
### unattended-upgrades config (every host):
```
Unattended-Upgrade::Allowed-Origins {
"${distro_id}:${distro_codename}-security";
};
Unattended-Upgrade::Automatic-Reboot "false";
Unattended-Upgrade::Mail "sam@snsnetlabs.com";
```
### Ansible patch playbook (weekly):
```yaml
# playbooks/patch.yml
- hosts: all
become: true
tasks:
- name: Update all packages
apt:
upgrade: safe
update_cache: yes
- name: Check if reboot required
stat:
path: /var/run/reboot-required
register: reboot_file
- name: Schedule reboot (Sunday 03:00)
command: shutdown -r 03:00
when: reboot_file.stat.exists
```
## Build Steps
1. **MeshCentral VM:** Clone Debian 12 template. 2 vCPU, 2GB RAM.
```bash
# Install
apt install nodejs npm
mkdir /opt/meshcentral && cd /opt/meshcentral
npm install meshcentral
node node_modules/meshcentral --install
```
2. **Caddy reverse proxy:** `mesh.internal.sns` → MeshCentral port 443.
Gate behind Authelia for web UI access.
3. **Deploy agents:** MeshCentral generates install scripts per OS.
Add to Ansible `base-hardening` role so every new host gets an agent.
4. **Ansible scheduled runs:**
```bash
# Cron on Ansible control node (or Gitea Actions scheduled workflow)
0 2 * * 0 ansible-playbook /srv/ansible/playbooks/patch.yml
```
5. **Drift detection:**
```bash
# Weekly: run playbook in check mode, alert on changes
ansible-playbook site.yml --check --diff | mail -s "Drift report" sam@snsnetlabs.com
```
## Security Posture
- **MeshCentral:** Authelia 2FA required. Agent-to-server communication is TLS.
No agents phone home to the internet (server is on-prem only via VPN).
- **Ansible:** SSH key-only, no passwords. Runs from a dedicated control node.
Playbooks in Gitea (version controlled, auditable).
- **Patch lag:** Critical security patches land within 24h (unattended-upgrades).
Kernel patches within 7 days (next maintenance window).
- **Client separation:** MeshCentral device groups + Ansible inventory groups.
Each client's hosts are isolated from others.
## Upgrade Path
- **Zammad / FreeScout:** Client-facing ticketing when you have 3+ managed clients.
- **Rundeck:** If Ansible ad-hoc commands need a web UI for on-call staff.
- **Commercial RMM (Tactical RMM):** FOSS alternative with built-in patching if
MeshCentral + Ansible combo gets too manual at 50+ endpoints.
<!-- ponytail: MeshCentral + Ansible instead of commercial RMM. Ceiling: no
integrated patching UI, no ticketing. Upgrade: Tactical RMM (FOSS) or
add Zammad for tickets when client count justifies it. -->