# Тестовый деплой на Proxmox (локально у вас в ЦОД)

Цель — один недорогой стенд: витрина + API + SQLite, без отказоустойчивого кластера.

## Серверов и ресурсов

Рекомендация для **минимального тестового** инстанса на Proxmox:

| Вариант | Ресурс | Комментарий |
|---------|--------|---------------|
| **1× LXC Debian 12 или Ubuntu 22.04** | CPU: **2 vCPU**, RAM: **1–2 GB**, Диск: **15–25 GB** (SSD/pool SSD) | Один контейнер: Node (API), при желании статика фронта с того же узла через nginx |

Для сборки (`npm ci` + `vite build`) и запасов по памяти лучше **2 GB RAM**; на **1 GB** возможны OOM при параллельной сборке — собирать фронт можно на машине разработчика и копировать `client/dist`.

Отделять приложение на **два LXC** (фронт / бэкенд) для теста обычно не нужно; имеет смысл только если хотите явно ограничить поверхность API.

### Сеть и доступ

- Одна виртуальная сеть VM/LAN вашего хостинга до Proxmox.
- Открыть снаружи (если нужен доступ из браузера): **80/tcp** и **443/tcp** на reverse proxy; прямой порт Fastify (**3333**) наружу не публиковать.
- Сервер приложения слушает **опционально** `127.0.0.1:3333`, наружу отдаёт **nginx** или **caddy**:

  - статика из `client/dist` (SPA `try_files`);

  - `location /api/` → proxy на `http://127.0.0.1:3333`;

  - `location /uploads/` → те же файлы с диска, что использует сервер (`server/uploads/` рядом с процессом) или через тот же origin с proxy на Fastify `@fastify/static`.

## Очистка БД локально перед тестом

В каталоге `server/` (нужны Node **20.6+** или **22+** для флага `--env-file`; иначе скопируйте переменные из `.dev_env` в `.env` и используйте обычные команды Prisma):

```bash
npm run db:reset:test
```

Удалит данные SQLite, заново применит миграции и выполнит `prisma`-seed из `server/package.json`.

## Программный стек на ВМ/LXC

- **Node.js** LTS (20.6+, лучше 22; скрипты `dev`, `start:dev_env`, `db:*:test` читают `server/.dev_env` через `node --env-file=.dev_env`).
- Приложение ставится так: склонировать репозиторий, на сервере в `server/` — `npm ci`, `npm run db:migrate:test` (или `migrate deploy`), при необходимости `npm run db:seed:test`.
- Переменные окружения: скопировать `server/.dev_env` или `server/.env.example`, задать **сильный** `JWT_SECRET`, свой `ADMIN_EMAIL`, `DATABASE_URL=file:./dev.db` или путь под персистентный раздел (`/var/lib/craftshop/data.db`).
- Для прод-подобного теста: **`IS_DEFAULT_CODE_ENABLED=false`** (не оставлять общий код на поставку наружу).

## Сервис (systemd, пример)

Один юнит `craftshop-api.service`:

- `WorkingDirectory=/opt/craftshop/server`
- `ExecStart=/usr/bin/node src/index.js` (перед этим экспортировать env через `EnvironmentFile=` к вашему `.env`)
- После деплоя: `systemctl daemon-reload && systemctl enable --now craftshop-api`

Персистентность: файл SQLite и каталог **`uploads/`** должны жить на диске, который не теряется при пересборке образа контейнера.

## Контрольный чеклист перед «тестом в бою»

1. Прогон миграций на чистую БД: `npm run db:reset:test` (только в **закрытом** окружении — стирает данные).
2. Сборка фронта и выставление `VITE_API_URL` (если API не на том же origin, что SPA).
3. `CORS_ORIGIN` — URL публичного фронта.
4. Выключить `DEFAULT_CODE` на внешнем стенде.

## Краткая схема

```mermaid
flowchart LR
  User[Браузер]
  Px[nginx на LXC]
  Api[Fastify Node :3333]
  Db[(SQLite файл)]
  Up[диск uploads]

  User --> Px
  Px -->|"/api"| Api
  Px -->|"статика /"| Ui[client dist]
  Api --> Db
  Api --> Up
```