Сервер для SaaS — это решение, которое принимают дважды: быстро на старте и вдумчиво при росте. Хорошая новость в том, что правильно выбранный VPS покрывает оба этапа: инфраструктура SaaS начинается с одного сервера за 750 ₽ в месяц и по мере роста аудитории разносится на несколько машин — без переезда в дорогое облако и без переписывания архитектуры. В этой статье разберём весь путь: MVP на одном VPS, вертикальный апгрейд без потери данных, разнесение по серверам, мониторинг и бэкапы, без которых SaaS-бизнес — это лотерея.
Почему SaaS стоит начинать на VPS, а не в облаке
Облачные платформы продают эластичность, но для SaaS на стадии MVP она не нужна: у вас десятки, максимум сотни пользователей, и нагрузка предсказуема. Зато облачный биллинг непредсказуем — платите отдельно за виртуальную машину, трафик, IOPS диска, снапшоты и балансировщик. Счёт за месяц узнаёте постфактум.
VPS переворачивает эту модель: фиксированная цена, выделенные ресурсы, полный root. Что это даёт SaaS-проекту:
- Предсказуемый бюджет. 750–1500 ₽ в месяц — и никаких сюрпризов в конце месяца. Трафик безлимитный, а это главный источник «внезапных» облачных счетов.
- Выделенные ресурсы KVM. Ваши vCPU и RAM не делятся с соседями — время ответа API стабильно, что критично для SaaS с SLA перед клиентами.
- NVMe-диски. База данных SaaS — это тысячи мелких операций чтения и записи. NVMe даёт кратный запас по IOPS по сравнению с обычными SSD.
- Полный контроль. Любой стек: Docker, PostgreSQL нужной версии, свои очереди. Никаких ограничений managed-платформ.
Подробное сравнение расходов есть в статье VPS или облако: считаем реальные расходы. Спойлер: до нескольких тысяч активных пользователей VPS дешевле в 3–5 раз.
Этап 1. MVP на одном VPS
Классический стек SaaS-стартапа умещается на одном сервере: приложение (Node.js, Python, Go, PHP — неважно), PostgreSQL, Redis для кеша и сессий, Nginx как реверс-прокси с SSL. Для этого этапа подходит тариф Pro у Cheap-Host: 12 vCPU, 16 ГБ RAM, 128 ГБ NVMe за 750 ₽/мес. Сервер выдаётся за 45–60 секунд — от оплаты до SSH-доступа проходит меньше минуты.
Базовая раскладка ресурсов на 16 ГБ RAM:
- PostgreSQL — 4 ГБ (
shared_buffers = 4GB); - приложение (2–4 воркера) — 2–4 ГБ;
- Redis — 1–2 ГБ (
maxmemory 2gb); - остальное — файловый кеш ОС, который ускоряет базу.
Удобнее всего собрать это в Docker Compose — тогда переезд и разнесение по серверам в будущем сведутся к правке одного файла. Как это сделать, мы разбирали в статье Docker Compose: приложение + база + Redis одной командой.
Минимальная гигиена безопасности с первого дня:
sudo apt update && sudo apt -y upgrade
sudo ufw allow OpenSSH
sudo ufw allow 80/tcp
sudo ufw allow 443/tcp
sudo ufw enable
sudo apt -y install fail2banПорт базы данных и Redis наружу не открываем вообще: пока всё на одном сервере, они слушают только 127.0.0.1.
Этап 2. Рост: апгрейд без потери данных
Первый сигнал роста — не падение сервера, а деградация метрик: p95 времени ответа API ползёт вверх, фоновые задачи выполняются дольше, при пиках появляются таймауты. Стандартная реакция в облаке — включить автоскейлинг и получить счёт побольше. На VPS путь проще и дешевле: вертикальный апгрейд.
Здесь проявляется ключевое преимущество Cheap-Host для SaaS: апгрейд CPU, RAM и диска выполняется без потери данных. Диск с базой, конфигами и приложением остаётся на месте — меняются только выделенные ресурсы. Не нужно поднимать новый сервер, переносить дампы, перенастраивать DNS и ловить простой посреди рабочего дня. Для SaaS, где каждый час недоступности — это письма недовольных клиентов, это не мелочь, а страховка бизнеса.
Практический маршрут апгрейда:
- Pro → Ultra (20 vCPU, 32 ГБ RAM, 192 ГБ NVMe, 1500 ₽/мес) — когда упёрлись в RAM или CPU. PostgreSQL получает 8 ГБ shared_buffers, Redis — 4 ГБ, приложению остаётся вдвое больше воркеров.
- Тюнинг на месте — прежде чем платить больше, убедитесь, что проблема в железе, а не в коде: индексы в базе, кеширование тяжёлых запросов в Redis, connection pooling (PgBouncer).
Правило: пока сервер загружен меньше чем на 70% в пике — тюнингуйте. Стабильно выше 70% — апгрейдитесь.
Этап 3. Разнесение по серверам
Когда и Ultra перестаёт хватать, наступает этап горизонтального разнесения. Не спешите с Kubernetes — для SaaS среднего размера достаточно 2–3 VPS с понятными ролями:
| Сервер | Роль | Тариф | Цена |
|---|---|---|---|
| app-1 | Приложение + Nginx | Pro | 750 ₽/мес |
| db-1 | PostgreSQL + Redis | Ultra | 1500 ₽/мес |
| worker-1 | Фоновые задачи, отчёты, рассылки | Start | 450 ₽/мес |
Итого 2700 ₽/мес за инфраструктуру, которая в облаке стоила бы в разы дороже. Порядок выноса компонентов:
- Сначала база данных. Она конкурирует с приложением за CPU и диск сильнее всего. Выносим PostgreSQL на отдельный Ultra, в
pg_hba.confразрешаем подключения только с IP приложения, соединение — по внутреннему туннелю WireGuard или с TLS. - Затем фоновые воркеры. Генерация PDF, экспорт данных, email-рассылки — всё, что грузит CPU рывками, переезжает на отдельный недорогой сервер и перестаёт влиять на время ответа API.
- Потом второй app-сервер — когда нужна отказоустойчивость. Nginx на входе балансирует между двумя приложениями через
upstream.
Благодаря Docker Compose с первого этапа разнесение — это перенос сервисов между compose-файлами, а не переустановка с нуля.
Мониторинг: видеть проблему раньше клиентов
SaaS отличается от лендинга тем, что о падении вам сообщают клиенты — если вы не узнали раньше. Минимальный набор:
- Метрики сервера: CPU, RAM, диск, IOPS. Netdata ставится одной командой и даёт живые графики; для мультисерверной схемы — связка Prometheus + Grafana (разбор в статье Grafana + Prometheus: профессиональный мониторинг VPS).
- Аптайм снаружи: внешний пинг главной страницы и endpoint'а
/healthкаждые 30–60 секунд с алертом в Telegram. - Метрики приложения: p95 времени ответа, частота ошибок 5xx, длина очереди фоновых задач. Именно они предсказывают, когда пора на следующий этап.
Простейший health-check для приложения за Nginx:
curl -fsS https://app.example.com/health || \
curl -s "https://api.telegram.org/bot$TOKEN/sendMessage" \
-d chat_id=$CHAT_ID -d text="SaaS down: health-check failed"Добавьте это в cron с интервалом в минуту на любом внешнем сервере — даже NAT VPS за 59 ₽/мес подойдёт в роли «наблюдателя».
Бэкапы: единственная настоящая страховка SaaS
Данные клиентов — это и есть ваш SaaS. Диски надёжны, но от DROP TABLE по ошибке, кривой миграции или взлома RAID не спасает. Рабочая схема для одного сервера:
# Ежедневный дамп PostgreSQL с ротацией 14 дней
pg_dump -Fc -U app appdb > /backup/appdb_$(date +%F).dump
find /backup -name "*.dump" -mtime +14 -deleteДальше — правило 3-2-1: копия локально, копия на другом сервере или в S3-совместимом хранилище, и хотя бы одна копия вне инфраструктуры хостера. Полную стратегию с restic и проверкой восстановления мы описали в статье Резервное копирование VPS: стратегия 3-2-1 на практике.
И главное: бэкап, который ни разу не разворачивали, — это не бэкап. Раз в месяц восстанавливайте дамп на тестовом сервере и убеждайтесь, что приложение с ним запускается.
Чек-лист инфраструктуры SaaS по этапам
| Этап | Пользователи | Конфигурация | Бюджет |
|---|---|---|---|
| MVP | до ~500 | 1 × Pro: всё на одном сервере | 750 ₽/мес |
| Рост | ~500–3000 | 1 × Ultra: апгрейд без потери данных | 1500 ₽/мес |
| Разнесение | 3000+ | Pro (app) + Ultra (БД) + Start (воркеры) | 2700 ₽/мес |
Цифры пользователей условны — всё зависит от тяжести вашего приложения, но логика этапов универсальна. Похожий путь для проектов на самой ранней стадии мы разбирали в статье Инфраструктура стартапа на VPS: MVP без облачных счетов.
FAQ
Можно ли запускать SaaS на одном VPS?
Да, для MVP и первых сотен пользователей одного сервера достаточно: приложение, база и Redis спокойно живут на 12 vCPU и 16 ГБ RAM. Главное — с первого дня настроить бэкапы и мониторинг.
Когда пора разносить SaaS по нескольким серверам?
Когда вертикальный апгрейд перестаёт помогать: база конкурирует с приложением за ресурсы, фоновые задачи тормозят API, а сервер в пике стабильно загружен выше 70%. Первым выносят базу данных.
Потеряю ли я данные при апгрейде тарифа?
На Cheap-Host апгрейд CPU, RAM и диска выполняется без потери данных: диск и настройки сохраняются, меняются только ресурсы. Можно вырасти со Start до Ultra без единой миграции.
VPS или облако — что выгоднее для SaaS-стартапа?
На старте VPS дешевле в разы: фиксированные 750–1500 ₽/мес против облачного биллинга за трафик, IOPS и запросы. Безлимитный трафик снимает главный источник непредсказуемых расходов.
Какой тариф взять для SaaS в продакшене?
Для MVP — Pro (12 vCPU, 16 ГБ RAM, 128 ГБ NVMe, 750 ₽/мес). Для продакшена с растущей аудиторией — Ultra: 20 vCPU, 32 ГБ RAM, 192 ГБ NVMe за 1500 ₽/мес.
Вывод
Инфраструктура SaaS на VPS — это управляемый рост без скачков в расходах: MVP на одном сервере, апгрейд без потери данных на пике роста, разнесение по 2–3 серверам, когда бизнес это оправдывает. На каждом этапе вы точно знаете, сколько платите и какие ресурсы получаете.
Если вы готовы разворачивать свой SaaS — у Cheap-Host есть тариф под каждый этап: Pro за 750 ₽/мес для MVP и Ultra за 1500 ₽/мес для продакшена. KVM с выделенными ресурсами, NVMe, безлимитный трафик, uptime 99,9% и выдача сервера за минуту. А когда проект вырастет — апгрейд без потери данных в пару кликов.
