32 lines
1.6 KiB
Markdown
32 lines
1.6 KiB
Markdown
# 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**: Use the existing iptables ruleset as the source of truth and implement equivalent nftables/NixOS rules 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.
|