1.6 KiB
1.6 KiB
Research: VPS Migration
Decision 1: Reverse proxy role
- Decision: New VPS runs nginx as the primary reverse proxy; services remain on the host server.
- Rationale: Matches the clarified scope and minimizes service migration risk while restoring proxy functionality.
- Alternatives considered: Migrating services to VPS; keeping old proxy (caddy) on Fedora VPS.
Decision 2: Firewall parity
- Decision: Apply the existing iptables ruleset as-is on the new VPS.
- Rationale: Ensures exact behavioral parity for complex routing and hot-swap behavior.
- Alternatives considered: Translating to another firewall system; partial translation with mixed rules.
Decision 3: VPN key handling
- Decision: Store VPN keys only in the existing secrets system; no plaintext keys in config.
- Rationale: Preserves confidentiality and aligns with encrypted secrets workflow.
- Alternatives considered: Plaintext inline keys; separate unmanaged secrets store.
Decision 4: Admin SSH principals
- Decision: Limit admin SSH authorized_keys entries to workstation, server, deacero, and galaxy.
- Rationale: Keeps access scope bounded to explicitly requested principals.
- Alternatives considered: Auto-adding other hosts found in config; adding only after confirmation.
Decision 5: Analytics (Plausible) migration
- Decision: Migrate existing analytics data to the new server.
- Rationale: Preserves historical reporting and continuity of metrics.
- Alternatives considered: Fresh start with no history; read-only legacy instance for history.