Self-hosted трекер на dedicated: стек, который не ломается от первой же нагрузки

Self-hosted трекер на dedicated: стек, который не ломается от первой же нагрузки

Dedicated под трекер нужен не ради «мощности», а ради контроля: диск, сеть, бэкапы, доступы и логика отказоустойчивости должны быть у тебя, а не у хостера.

Базовый стек обычно такой:
— Nginx как reverse proxy и TLS-терминация
— PostgreSQL для основных таблиц и событий
— Redis для очередей, кеша и rate limit
— отдельный worker для postback, API и фоновых задач
— object storage или второй диск под логи и бэкапы

Критичные ошибки на старте:
— ставить всё в один контейнер без лимитов по CPU/RAM
— держать БД и логи на одном медленном томе
— оставлять бекупы только на этом же сервере
— не закрывать админку и API по IP/Basic auth/VPN
— смешивать веб-слой и тяжёлые фоновые джобы в одном процессе

По сети важнее стабильный RTT, чем «гигабит на бумаге». Для трекера полезнее предсказуемый канал, отдельный IP под инстанс и DNS с нормальным TTL, чтобы при миграции не ловить лишние простои. Логи лучше сразу ротацировать, а метрики снимать отдельно: load, iowait, disk latency, saturation по Postgres.

Если стек собран без лишней магии, его проще переносить, масштабировать и дебажить. Начинай с простого разделения ролей: веб, БД, очередь, бэкап.