Database Setup

Установка PostgreSQL и Redis на VPS.

1. PostgreSQL

Dokploy UI → Projects → проект goLoot
New Service → Database → PostgreSQL
Настройки:

Параметр	Значение
Name	`postgresql`
Docker image	`postgres:18` (default) или `postgres:16`
Database Name	`goloot`
Database User	`goloot`
Password	(см. ниже)

Какую версию выбрать?

Версия	EOL	Рекомендация
16	Nov 2028	Проверена с Dokploy, стабильная
18	Nov 2030	Default в Dokploy, рекомендуется для новых установок

Dokploy по умолчанию предлагает postgres:18. Для нашего проекта разница между версиями минимальна.

Сгенерируй надёжный пароль:

openssl rand -hex 24

Эта команда выдаст 48-символьный пароль из безопасных символов (0-9, a-f). Никаких спецсимволов, которые могут сломать connection string или shell.

Сохрани пароль!

Скопируй сгенерированный пароль и сохрани — он понадобится для connection string во всех сервисах.

Поле Command должно быть ПУСТЫМ при создании!

Dokploy позволяет указать Command в настройках PostgreSQL. Не заполняй его при создании — это заменит entrypoint контейнера и PostgreSQL откажется запускаться с ошибкой "root" execution of the PostgreSQL server is not permitted.

Оптимизацию можно добавить после успешного запуска — см. секцию ниже.

Deploy

Dokploy создаст контейнер PostgreSQL в сети dokploy-network.

Connection string (для других сервисов в Dokploy):

postgresql://goloot:YOUR_PASSWORD@DOKPLOY_SERVICE_NAME:5432/goloot

Внутренний DNS

Внутри Docker-сети dokploy-network сервисы обращаются друг к другу по имени сервиса. Dokploy генерирует уникальное имя при создании (например, goloot-postgres-de09zz). Узнать имя можно через:

docker service ls | grep postgres

Это имя используется как hostname в connection strings всех сервисов.

Оптимизация PostgreSQL (опционально, не нужно на старте)

По умолчанию PostgreSQL использует консервативные настройки (128 MB кэша вместо возможных 2 GB). На старте проекта это не проблема — разница заметна только при высокой нагрузке (тысячи пользователей, тяжёлые запросы).

Оптимизация состоит из двух частей: Resources (лимиты контейнера) и Command (настройки PostgreSQL).

Шаг 1: Увеличить Resources (лимиты контейнера)

Dokploy по умолчанию ставит Memory Limit = 1 GB для PostgreSQL. При таком лимите оптимизации через Command почти бессмысленны.

PostgreSQL → вкладка Advanced → прокрутить вниз до секции Resources
Изменить значения:

Параметр	По умолчанию	Рекомендация	Значение в bytes
Memory Limit	1 GB	4 GB	`4294967296`
Memory Reservation	256 MB	512 MB	`536870912`
CPU Limit	2 CPUs	Оставить	—
CPU Reservation	1 CPU	Оставить	—

Почему только Memory?

Memory Limit — потолок RAM для контейнера. Нужно увеличить, чтобы PostgreSQL мог использовать больше кэша.
Memory Reservation — минимум гарантированной памяти. 512 MB достаточно, чтобы PostgreSQL не "отжимали" другие контейнеры при нехватке RAM.
CPU — PostgreSQL в основном упирается в диск (I/O), а не в CPU. Дефолтные значения достаточны.

Нажать Save, затем Redeploy

Шаг 2: Настроить Command (параметры PostgreSQL)

Параметры PostgreSQL задаются через вкладку Advanced → Command.

Обязательно с docker-entrypoint.sh!

Command должен начинаться с docker-entrypoint.sh — это сохраняет штатный entrypoint, который переключает процесс с root на пользователя postgres. Без него PostgreSQL откажется запускаться.

docker-entrypoint.sh postgres -c shared_buffers=1GB -c effective_cache_size=3GB -c work_mem=16MB -c maintenance_work_mem=256MB

Значения рассчитаны для Memory Limit контейнера = 4 GB. Для точного расчёта используй PgTune.

Параметр	Значение	Описание
`shared_buffers`	1 GB	Кэш данных в RAM (~25% от Memory Limit)
`effective_cache_size`	3 GB	Оценка доступного кэша (~75% от Memory Limit)
`work_mem`	16 MB	Память для сложных запросов
`maintenance_work_mem`	256 MB	Память для VACUUM, CREATE INDEX

Command привязан к Memory Limit!

shared_buffers не может превышать Memory Limit контейнера — иначе PostgreSQL не запустится. Если меняешь Memory Limit — пересчитай Command.

Если оставляешь Memory Limit = 1 GB (без шага 1) — используй уменьшенные значения:

docker-entrypoint.sh postgres -c shared_buffers=256MB -c effective_cache_size=768MB -c work_mem=8MB -c maintenance_work_mem=128MB

Выигрыш при 1 GB лимите минимален. Реальный эффект — при лимите 4+ GB.

Нажать Save, затем Redeploy.

2. Redis (опционально)

Redis используется для трекинга invite-ссылок к документации. Если Redis недоступен — backend продолжает работать.

Dokploy UI → проект goLoot
New Service → Database → Redis
Настройки:

Параметр	Значение
Name	`redis`
Version	7
Password	(сгенерируй через `openssl rand -hex 24`)

Deploy

Connection string:

redis://:YOUR_PASSWORD@redis:6379

3. Проверка подключений

PostgreSQL

# Из контейнера PostgreSQL:
docker exec -it $(docker ps -q -f name=postgresql) psql -U goloot -d goloot -c "SELECT 1"

Если видишь 1 — подключение работает.

Redis

# Из контейнера Redis (используй goloot-redis, т.к. Dokploy имеет свой внутренний Redis):
docker exec -it $(docker ps -q -f name=goloot-redis) redis-cli -a YOUR_REDIS_PASSWORD ping
# Ответ: PONG

4. Инициализация базы данных

Это делается после деплоя Backend

Сначала создай и задеплой Backend (см. Services Deployment), затем вернись сюда.

Применить Prisma-схему

PostgreSQL в Dokploy доступен только внутри Docker-сети — порт не открыт наружу. Есть два способа применить миграции.

Когда что использовать

Команда	Когда	Что делает
`db push`	Dev/staging, активная разработка	Синхронизирует схему напрямую, может потерять данные
`migrate deploy`	Production	Применяет только созданные миграции, безопасно

Способ A: SSH-тоннель с локальной машины (рекомендуется)

Позволяет запускать Prisma команды с локальной машины через SSH-тоннель к VPS.

Терминал 1 — открыть тоннель:

ssh -L 5432:localhost:5432 root@YOUR_VPS_IP
# Оставить открытым на время работы

Терминал 2 — применить миграции:

cd backend

# DATABASE_URL указывает на localhost через тоннель:
DATABASE_URL="postgresql://goloot:YOUR_PASSWORD@localhost:5432/goloot" npx prisma migrate deploy

# Или для dev/staging:
DATABASE_URL="postgresql://goloot:YOUR_PASSWORD@localhost:5432/goloot" npx prisma db push

Не используй внешний IP!

DATABASE_URL должен указывать на localhost:5432 (через тоннель), а не на внешний IP сервера. Порт 5432 закрыт UFW — подключение по внешнему IP не пройдёт.

Способ B: Через Dokploy Docker Terminal

Миграции уже находятся внутри Backend контейнера (попадают туда при сборке Docker-образа). Можно выполнить их напрямую.

Dokploy UI → Backend → вкладка Deployments или Advanced → Docker Terminal
Выбрать running контейнер → /bin/sh
Внутри контейнера:

npx prisma migrate deploy   # production
npx prisma db push           # dev/staging

Когда использовать Docker Terminal

Когда нет возможности открыть SSH-тоннель
Для быстрой проверки статуса: npx prisma migrate status
prisma CLI скачается при первом запуске через npx (не установлен в production-образе)

Загрузить начальные данные (Seeds)

Seed-скрипты заполняют справочники (категории, типы кейсов, рулеток).

Запускать с локальной машины через SSH-тоннель (способ A):

# Терминал 1: SSH-тоннель уже открыт
# Терминал 2:
cd backend

DATABASE_URL="postgresql://goloot:YOUR_PASSWORD@localhost:5432/goloot" npx tsx prisma/seed/seed-categories.ts
DATABASE_URL="postgresql://goloot:YOUR_PASSWORD@localhost:5432/goloot" npx tsx prisma/seed/seed-case-types.ts
DATABASE_URL="postgresql://goloot:YOUR_PASSWORD@localhost:5432/goloot" npx tsx prisma/seed/seed-spin-types.ts

Полный список seeds

# Обязательные seeds (порядок важен!)
npx tsx prisma/seed/seed-categories.ts
npx tsx prisma/seed/seed-case-types.ts
npx tsx prisma/seed/seed-spin-types.ts

# Опциональные seeds
npx tsx prisma/seed/seed-streak-achievements.ts
npx tsx prisma/seed/seed-streak-content.ts
npx tsx prisma/seed/seed-achievement-templates.ts
npx tsx prisma/seed/seed-quest-templates.ts

Порядок seeds

seed-categories должен выполняться первым, так как другие seeds зависят от категорий.

5. Бэкап PostgreSQL

Dokploy имеет встроенную систему бэкапов PostgreSQL прямо в S3-совместимое хранилище — без необходимости настраивать cron или bash-скрипты вручную.

Настройка

Настрой S3 Destination: Dokploy UI → Settings → S3 Destinations → + Add Destination
Dokploy UI → проект goLoot → сервис PostgreSQL → вкладка Backups
Выбери S3 Destination и настрой расписание (например, 0 3 * * * — ежедневно в 03:00)

Dokploy автоматически выполняет pg_dump, сжимает и загружает в S3.

Восстановление

Dokploy UI → PostgreSQL → Backups → выбрать бэкап → Restore

Подробнее о бэкапах, восстановлении и миграции: Backup & Migration

6. Чеклист

PostgreSQL установлен и работает
База goloot и пользователь созданы
Redis установлен (опционально)
Connection strings записаны (понадобятся для env vars)
Автоматический бэкап настроен

Записать и сохранить:

DATABASE_URL=postgresql://goloot:PASSWORD@DOKPLOY_SERVICE_NAME:5432/goloot
REDIS_URL=redis://:PASSWORD@DOKPLOY_REDIS_SERVICE_NAME:6379

Имена сервисов узнаёшь через docker service ls | grep -E "postgres|redis" на VPS.

Dokploy Installation — предыдущий шаг
Services Deployment — следующий шаг
Environment Variables — полный список переменных
Backup & Migration — стратегии бэкапов

1. PostgreSQL​

Шаг 1: Увеличить Resources (лимиты контейнера)​

Шаг 2: Настроить Command (параметры PostgreSQL)​

2. Redis (опционально)​

3. Проверка подключений​

PostgreSQL​

Redis​

4. Инициализация базы данных​

Применить Prisma-схему​

Способ A: SSH-тоннель с локальной машины (рекомендуется)​

Способ B: Через Dokploy Docker Terminal​

Загрузить начальные данные (Seeds)​

5. Бэкап PostgreSQL​

Настройка​

Восстановление​

6. Чеклист​

Related​