# 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.