sns-network-solutions/infra/sns-digital/hosting-stack.md
Samuel James b1a35783bb 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
2026-07-18 13:08:23 -05:00

109 lines
3.9 KiB
Markdown

# 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. -->