glm-5.1
7efc142406
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)
90 lines
3.2 KiB
Markdown
90 lines
3.2 KiB
Markdown
# 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:
|
|
|
|
1. Multi-site reverse proxy with TLS termination
|
|
2. ACME certificate management (multi-domain)
|
|
3. HTTP → HTTPS redirect
|
|
4. Rate limiting, logging, health check, graceful shutdown
|
|
5. Systemd integration
|
|
|
|
Phase 2 scope shifts to operational hardening:
|
|
|
|
1. Per-site rate limits and body limits
|
|
2. Per-site upstream timeouts
|
|
3. Metrics endpoint (Prometheus-compatible)
|
|
4. Connection limits and timeouts
|
|
5. 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](../overview.md)
|
|
- [config.md](../config.md)
|
|
- [tls.md](../tls.md)
|
|
- [proxy.md](../proxy.md)
|
|
- ADR-002 (custom proxy handler — rationale updated for multi-site) |