# SHiNE Deployment Servers Inventory

## Scope
This folder contains all deployment-related notes and server records for SHiNE.

## Legacy Production Server
- Name: `VPS-02` (legacy)
- Access: `root@194.87.0.247`
- Current role: old production server
- Confirmed services:
  - `coturn` is installed and active (`systemd: active/running`)
  - `caddy` is installed (reported by project context; verify version on host if needed)
- TURN configuration observed on host:
  - `listening-port=3478`
  - `external-ip=194.87.0.247`
  - `relay-ip=194.87.0.247`
  - auth mode: `use-auth-secret` + `static-auth-secret`
- SHiNE deployment note:
  - This host is used as current/legacy runtime for SHiNE.
  - Gradle-based deployment is used in this project (see repository deploy tasks and scripts).

## Target Production Server (Migration)
- Name: `VPS-05` (new)
- Access: `root@45.136.124.227`
- Planned role: new primary production server for gradual migration
- Baseline setup done:
  - `ripgrep` installed
  - user `player` created
  - user `player` added to `sudo` group
  - deployment directory created: `/home/player/SHiNE`
- Rule:
  - All SHiNE-related runtime files and deployments on VPS-05 should be placed under `/home/player/SHiNE`.

## Additional TURN Node
- Name: `promo-node-93`
- Access: `ubuntu@93.170.12.154` (and `player` user for SHiNE operations)
- Role: additional TURN node for SHiNE calls
- TURN setup:
  - `coturn` installed and active
  - `listening-port=3478`
  - `tls-listening-port=5349`
  - `use-auth-secret` + shared `static-auth-secret`
  - relay UDP port range: `49152-50152`
- Runtime files:
  - `/etc/turnserver.conf`
  - `/home/player/SHiNE/coturn/turnserver.conf`
- Cleanup done:
  - Disabled old reverse SSH tunnel (`reverse-ssh.service`) that exposed `0.0.0.0:1200 -> localhost:22` to `194.87.0.247`.

## Next Migration Steps (recommended)
1. Install and configure runtime dependencies (JDK, Caddy, DB, TURN if required).
2. Mirror SHiNE deployment process from VPS-02 using existing Gradle deployment flow.
3. Move traffic gradually and validate logs/metrics before final cutover.