9. Rationale
9. Rationale
← Service Access Model | Index | Next →
Alternatives Considered
| Alternative | Why Considered | Why Rejected |
|---|---|---|
| Public IP + firewall per-service | Simple and direct | High exposure risk, operational overhead |
| SSH tunnels | Minimal change to services | Not scalable, brittle, manual |
| Docker Swarm overlay | Automated multi-host networking | Requires orchestrator adoption |
| Kubernetes CNI | Standardized overlay networking | Requires Kubernetes migration |
Invariant Violations
| Alternative | Violated Invariant |
|---|---|
| Public IP + firewall per-service | Invariant 1 (WG-only access) |
| SSH tunnels | Invariant 2 (stable host identity) |
| Swarm overlay | Invariant 2 (deterministic addressing) |
Conclusion
A host-level WireGuard mesh provides the minimum viable architecture that satisfies privacy, encryption, and operational simplicity without requiring a full orchestrator.
End of Rationale — RFC-WG-0002