Files

glm-5.1 7efc142406 Expand architecture: multi-site Phase 1, multi-domain TLS, fix review issues

Promote multi-site support from Phase 2 to Phase 1 (ADR-010): the proxy
must support git.alk.dev and alk.dev from initial release. Add multi-domain
TLS configuration (ADR-011): acme_domains array replaces acme_domain string,
single SAN certificate via rustls-acme.

Key changes:
- ADR-010: Multi-site in Phase 1 — avoids config format migration later
- ADR-011: Multi-domain TLS — single SAN cert, acme_domains Vec<String>
- ADR-002: Updated rationale for multi-site (one upstream per domain)
- overview.md: Phase 1 now includes multi-site, alk.dev pass-through,
  dual licensing (MIT OR Apache-2.0), real IP removed
- config.md: acme_domain → acme_domains, TOML example shows both sites,
  validation adds unique host check, real IP replaced with 203.0.113.10
- tls.md: Multi-domain SNI section moved from Future to current, manual
  mode uses ResolvesServerCert for SNI mapping, TOML header fixed
- proxy.md: Updated for multi-site, removed single-domain language
- operations.md: RFC 5737 documentation IPs, clarified rate limit eviction
  semantics (distinct scan interval vs eviction age)
- open-questions.md: OQ-05 resolved (single bind_addr sufficient), new
  OQ-07 (per-site TLS overrides)

Review fixes:
- acme_domains (plural) consistently used across all docs and diagram
- ADR-011 clearly scopes acme_domain as previous design
- Inline decision rationale extracted: tls.md hot-reload → ADR-004 ref,
  config.md static/dynamic → ADR-008 ref
- TOML section headers consistent (server.tls)

2026-06-11 08:50:03 +00:00

3.2 KiB

Raw Blame History

ADR-010: Multi-Site Support in Phase 1

Status

Accepted

Context

The original architecture phased multi-site support into Phase 2, treating Phase 1 as a single-domain replacement for nginx serving only git.alk.dev. This was based on the assumption that only one domain needed proxying initially.

However, alk.dev (the bare domain) will need proxying in the near future. While alk.dev is a simple case — proxying to a Deno/Fresh container with no special requirements — the proxy must support multiple sites from day one. The config format, routing logic, and TLS certificate provisioning all need multi-site awareness.

Additionally, api.alk.dev is explicitly out of scope (it runs its own HTTP/2+ server natively), but the proxy must not prevent future sites from being added.

The cost of deferring multi-site is high: we'd need a config format migration, routing logic rewrite, and TLS cert management changes later. Supporting multi-site from the start costs very little — the config format just uses an array of sites (which it already does), host-based routing is trivial in axum, and rustls-acme supports multi-domain certificates natively.

Decision

Move multi-site support from Phase 2 into Phase 1. The proxy supports multiple sites from the initial release:

[[sites]] array in config (already the planned format)
Host-based routing via axum's Host extractor (already the planned approach)
Multi-domain ACME certificate provisioning via rustls-acme
Each site maps a hostname to an upstream address

Phase 1 scope becomes:

Multi-site reverse proxy with TLS termination
ACME certificate management (multi-domain)
HTTP → HTTPS redirect
Rate limiting, logging, health check, graceful shutdown
Systemd integration

Phase 2 scope shifts to operational hardening:

Per-site rate limits and body limits
Per-site upstream timeouts
Metrics endpoint (Prometheus-compatible)
Connection limits and timeouts
Log rotation

Phase 3 remains future enhancements.

Rationale

The config format already uses [[sites]] — no format change needed
Host-based routing is the natural axum pattern and was already planned
rustls-acme accepts Vec<domain> — multi-domain is its default usage
The cost of adding multi-site later (config migration, routing rewrite, cert management changes) far exceeds the cost of supporting it now (zero additional complexity)
alk.dev is confirmed as a near-term need, not a hypothetical
The proxy's value proposition is being a memory-safe reverse proxy for our infrastructure, which has multiple domains

Consequences

Positive:

No config format migration needed later
alk.dev can be added to the config without code changes
TLS cert management handles multiple domains from the start
Eliminates an entire phase of work

Negative:

Slightly more testing surface (must verify correct routing with multiple sites)
Must test multi-domain ACME provisioning (not just single-domain)
Wildcard or fallback site behavior needs to be defined (addressed in OQ-07)

References

overview.md
config.md
tls.md
proxy.md
ADR-002 (custom proxy handler — rationale updated for multi-site)

3.2 KiB Raw Blame History