# Test/devnet серверы SHiNE

Отдельный test/devnet стенд состоит из четырёх независимых SHiNE-инстансов:

- `t1.shineup.me`
- `t2.shineup.me`
- `t3.shineup.me`
- `t4.shineup.me`

Это не production. Все deploy-цели задаются через домены.

Текущее фактическое состояние на `2026-07-28`:

- все четыре тестовых контура `t1` / `t2` / `t3` / `t4` уже работают без `SQLite`;
- все четыре контура используют `PostgreSQL 18.4`;
- PostgreSQL на test-хосте общий для всех четырёх контуров и запущен в Docker-контейнере `shine-test-postgres`;
- все четыре контура используют один и тот же Helius devnet RPC/WS endpoint;
- во всех четырёх UI включён web push client-код и встроен один и тот же test `VAPID` public key.

## Общие параметры

- SSH: `player@tX.shineup.me`
- Solana cluster: `devnet`
- Solana RPC: `https://devnet.helius-rpc.com/?api-key=0614c894-52d8-4ddc-bbbc-0947ce5ec3a4`
- Solana WS: `wss://devnet.helius-rpc.com/?api-key=0614c894-52d8-4ddc-bbbc-0947ce5ec3a4`
- Caddy config: `/etc/caddy/Caddyfile`
- Общий PostgreSQL container: `shine-test-postgres`
- PostgreSQL image: `postgres:18`
- PostgreSQL engine version на `2026-07-28`: `18.4`
- Web push в UI: общий test `VAPID` public key `BOdoWZndZRaNe9kyUFsJ5-xEfFABXNKennAKg15Z7ycAwUIQ7yDV_sIWWYJCwJriN4g9oU-CyJPrn1U6lfxuDbI`

## Инстансы

| Домен | Логин сервера | Сервер | UI | Порт | systemd | PostgreSQL DB | PostgreSQL user |
|---|---|---|---|---|---|---|---|
| `t1.shineup.me` | `server_t1` | `/home/player/t1/server` | `/home/player/t1/UI` | `7101` | `shine-t1.service` | `shine_t1_db` | `shine_t1` |
| `t2.shineup.me` | `server_t2` | `/home/player/t2/server` | `/home/player/t2/UI` | `7102` | `shine-t2.service` | `shine_t2_db` | `shine_t2` |
| `t3.shineup.me` | `server_t3` | `/home/player/t3/server` | `/home/player/t3/UI` | `7103` | `shine-t3.service` | `shine_t3_db` | `shine_t3` |
| `t4.shineup.me` | `server_t4` | `/home/player/t4/server` | `/home/player/t4/UI` | `7104` | `shine-t4.service` | `shine_t4_db` | `shine_t4` |

## Deploy

```bash
bash deploy/scripts/test_t1_server.sh
bash deploy/scripts/test_t1_ui.sh

bash deploy/scripts/test_t2_server.sh
bash deploy/scripts/test_t2_ui.sh

bash deploy/scripts/test_t3_server.sh
bash deploy/scripts/test_t3_ui.sh

bash deploy/scripts/test_t4_server.sh
bash deploy/scripts/test_t4_ui.sh
```

## Проверка

```bash
curl -I https://t1.shineup.me
curl -I https://t2.shineup.me
curl -I https://t3.shineup.me
curl -I https://t4.shineup.me
```

На сервере:

```bash
sudo systemctl --no-pager --full status caddy shine-t1 shine-t2 shine-t3 shine-t4
sudo docker ps --format 'table {{.Names}}\t{{.Image}}\t{{.Status}}'
```

## Operational-нюанс

Общий Helius devnet endpoint тоже может начать ограничивать запросы, если несколько инстансов одновременно делают тяжёлый bootstrap. Если после деплоя какой-то инстанс не подтянул `sync_servers` или завис на startup sync, рестартовать сервисы по одному с паузой.

Отдельный нюанс по web push:

- у `t1`, `t2`, `t3`, `t4` в UI уже есть одинаковый встроенный `VAPID` public key;
- то есть `t3` и `t4` используют тот же web push клиентский код, что и `t1` / `t2`;
- если позже понадобится разделить push-ключи по тестовым контурам, это нужно делать отдельным UI deploy с новым `DEPLOY_WEBPUSH_VAPID_PUBLIC`.