Считаем бюджет на инфраструктуру стартапа на первый год

MAATRIX

Основатель раннего стартапа обычно решает бюджет на инфраструктуру одним из двух неверных способов: либо берёт сервер "с запасом на вырост" и полгода платит за простаивающие ресурсы, либо экономит на всём подряд и теряет данные или репутацию в первый месяц, когда что-то пошло не так. Правильный подход не про точные суммы — их всё равно нельзя предсказать до product-market fit — а про методику: где закладывать минимум, где нельзя экономить в принципе, и как заранее знать, куда расти, когда нагрузка вырастет непредсказуемо.

Логика бюджета: сначала минимум, потом рост по факту

До product-market fit у стартапа нет истории нагрузки — есть только гипотеза о продукте и неизвестность в том, сколько людей придёт и когда. В этой ситуации любая точная оценка бюджета на год вперёд — фикция: либо вы закладываете большой запас "на всякий случай" и переплачиваете каждый месяц за неиспользуемые ресурсы, либо экономите и в момент роста упираетесь в лимиты именно тогда, когда нельзя тормозить.

Рабочая методика делит статьи расходов на инфраструктуру на три категории:

• Плавающие по нагрузке — сервер под приложение, база данных, объём диска. Здесь стартуем с минимума и растим по факту метрик (CPU, RAM, диск, трафик), а не по календарю.
• Постоянные и почти бесплатные — домен, SSL, базовый мониторинг. Их можно один раз настроить и забыть, стоимость не зависит от роста продукта.
• Некопируемые на старте — резервное копирование. Это единственная статья, где принцип "минимум сейчас" не работает: цена ошибки (потеря базы данных пользователей за неделю до презентации инвесторам) для стартапа часто фатальна, а стоимость нормального бэкапа — копейки на фоне остальных расходов.

Дальше по каждой категории — что конкретно закладывать в бюджет и по каким сигналам расти.

Базовый сервер под MVP: не переплачивать за мощность, которая не нужна

MVP на старте обслуживает горстку пользователей — фаундеров, первых бета-тестеров, инвесторов, которые смотрят демо. Для такой нагрузки минимальный VPS (1-2 vCPU, 2-4 ГБ RAM, 20-40 ГБ NVMe) справляется с большинством стеков: Node.js/Python/Ruby-бэкенд, PostgreSQL или MySQL, Redis для кеша, Nginx как reverse proxy. Если фронтенд статический (React/Vue-сборка), его вообще можно раздавать с того же сервера или через CDN — отдельный хостинг под статику на этом этапе не нужен.

Главный критерий выбора конфигурации не "сколько нужно", а "насколько быстро можно апгрейднуться, когда понадобится". Смотрите заранее у провайдера:

• Можно ли увеличить vCPU/RAM без переустановки ОС (вертикальный апгрейд "на лету" или с одной перезагрузкой).
• Можно ли расширить диск без даунтайма или с минимальным.
• Есть ли следующий тариф в той же линейке, чтобы не переезжать на новую платформу при росте.

# Быстрая проверка нагрузки на текущем VPS перед решением об апгрейде
htop                  # CPU и RAM в реальном времени
df -h                 # свободное место на диске
iostat -x 1 5         # утилизация диска, если есть sysstat
free -m                # память с учётом кеша

Если метрики стабильно выше 70-80% CPU/RAM в рабочее время или диск заполнен больше 80% — это сигнал апгрейдить тариф, а не признак того, что нужно было брать более мощный сервер с самого начала. Переплата за неиспользуемую мощность в первые 2-3 месяца жизни стартапа обычно больше, чем стоимость самого апгрейда, когда он реально понадобится. Подробнее о том, сколько ресурсов закладывать на старте и как их считать по метрикам, — в статье сколько ресурсов нужно VPS для стартапа на старте, а пошаговую настройку сервера под MVP разбирали в материале VPS для стартапа на старте: что выбрать и как настроить.

Домен, SSL и почта для команды: недорогая инфраструктура

Домен — разовая покупка на год с продлением, цена зависит от зоны (.com, .io, .ru и так далее) и меняется у регистраторов, поэтому конкретную сумму называть не будем — смотрите актуальный прайс у регистратора при покупке. Держите домен отдельно от хостинга приложения (регистратор ≠ провайдер сервера), чтобы не зависеть от одной компании и не терять контроль над доменом при смене хостинга.

SSL-сертификат для сайта и API в 2026 году в подавляющем большинстве случаев бесплатен — Let's Encrypt выпускает и автоматически продлевает сертификаты через ACME-протокол, платный SSL для стартапа на этом этапе не нужен почти никогда (платный сертификат имеет смысл только для специфичных корпоративных требований типа EV-сертификатов, которые раннему стартапу не актуальны).

# Установка Let's Encrypt через certbot на Ubuntu/Debian
sudo apt update && sudo apt install certbot python3-certbot-nginx -y
sudo certbot --nginx -d example.com -d www.example.com
# Автопродление проверяется так:
sudo certbot renew --dry-run

Подробный разбор установки и автопродления — в статье как установить и настроить Let's Encrypt SSL на VPS.

Почта для команды — статья, где легко переплатить, если сразу брать корпоративный почтовый сервис на всю команду "про запас". На старте достаточно:

• Алиасов вида hello@, support@, founders@ с переадресацией на личные ящики через настройки DNS (MX-записи) — бесплатно или почти бесплатно у большинства регистраторов доменов.
• Полноценного корпоративного почтового сервера (self-hosted Mailcow, iRedMail или платный сервис) — только когда команда выросла настолько, что алиасов с переадресацией уже не хватает организационно, а не потому что "так положено с первого дня".

Если решите поднимать почту на своём сервере сразу — учитывайте отдельный расход времени на репутацию IP и настройку SPF/DKIM/DMARC, иначе письма будут падать в спам. Это не техническая мелочь, а отдельная статья работы, которую стоит закладывать в бюджет времени, а не только денег.

Мониторинг и алерты: бесплатный минимум с первого дня

Мониторинг — ещё один пункт, где не нужно экономить на самой идее (мониторинг должен быть с первого дня), но можно и нужно экономить на инструментах. Для одного-двух серверов MVP хватает бесплатного или условно-бесплатного стека:

• Uptime Kuma — self-hosted мониторинг доступности сайта/API с алертами в Telegram, Slack, email; разворачивается на том же VPS в Docker за 10 минут и не требует отдельного сервера.
• Netdata или встроенные средства ОС — метрики CPU/RAM/диска/сети в реальном времени без сложной настройки.
• Бесплатные внешние чекеры доступности (пинг сайта раз в несколько минут с оповещением) — как дополнительный внешний контроль, если самому серверу вдруг "плохо" целиком.

# Фрагмент docker-compose.yml для Uptime Kuma
services:
  uptime-kuma:
    image: louislam/uptime-kuma:1
    volumes:
      - ./uptime-kuma-data:/app/data
    ports:
      - "3001:3001"
    restart: unless-stopped

Задача мониторинга на этом этапе — не собрать красивые дашборды, а узнать о падении сайта раньше, чем об этом напишет пользователь или инвестор. Полноценные Zabbix/Grafana+Prometheus имеет смысл разворачивать, когда серверов и сервисов становится больше одного-двух и вручную уследить за всем уже сложно — пошаговая установка описана в статье как установить и настроить Uptime Kuma на VPS.

Резервное копирование: то, на чём нельзя экономить

Это единственный пункт бюджета, где логика "минимум сейчас, растим по факту" не применяется. Причина простая: цена ошибки асимметрична. Если вы неправильно оценили мощность сервера — потеряете немного денег на апгрейде задним числом или немного скорости на пару дней. Если у вас нет бэкапа и упал диск, сломалась миграция базы или кто-то из команды случайно выполнил DROP TABLE на проде — стартап может не пережить эту потерю данных, особенно если это база пользователей на этапе привлечения первых клиентов или инвестиций.

Минимальная схема резервного копирования, которую стоит настроить в первую неделю жизни продукта, а не откладывать до "когда будет время":

• Ежедневный дамп базы данных с ротацией (хранить хотя бы 7-14 последних копий).
• Копия бэкапов вне самого сервера — на S3-совместимое хранилище, отдельный VPS или облачное хранилище. Бэкап, который лежит на том же диске, что и рабочие данные, не бэкап — если умрёт диск, вы потеряете и оригинал, и копию одновременно.
• Периодическая проверка восстановления (хотя бы раз в месяц реально накатить дамп на тестовую базу) — бэкап, который никогда не проверяли на восстановление, может оказаться битым именно в момент, когда он нужен.

# Простой пример: ежедневный дамп PostgreSQL с выгрузкой в удалённое хранилище
0 3 * * * pg_dump -U appuser appdb | gzip > /backups/appdb_$(date +\%F).sql.gz \
  && rclone copy /backups/appdb_$(date +\%F).sql.gz remote:startup-backups/

Инструмент бэкапа (pg_dump/mysqldump напрямую, BorgBackup, restic, UrBackup) на этом этапе вторичен — первично то, что копия существует, лежит отдельно и её реально проверяли. Подробная методика настройки описана в статье как установить и настроить резервное копирование БД на VPS.

Буфер на рост: как не паниковать, когда продукт выстрелит

Буфер на непредвиденный рост — это не отдельная строка "заложить X% сверху на всякий случай", а заранее продуманный план действий на случай, если метрики резко пойдут вверх. Задача не "накопить денег про запас", а знать заранее, куда конкретно апгрейдиться, чтобы в момент роста не тратить время на выбор решения под давлением.

Что стоит продумать заранее, ещё когда нагрузка низкая:

• Следующий тариф VPS в той же линейке провайдера — конкретный, с которого можно быстро переехать вертикальным апгрейдом, а не искать новый хостинг в панике.
• Порог для перехода на выделенный сервер — примерная метрика (например, стабильная утилизация CPU/RAM выше 80% на топовом VPS-тарифе линейки), после которой имеет смысл переезд на выделенное железо, а не бесконечный апгрейд виртуалки.
• План на скачок трафика — что делать, если внезапно пришёл наплыв пользователей (Product Hunt, вирусный пост, упоминание у крупного блогера): включить кеширование на уровне Nginx/CDN, временно отключить тяжёлые фоновые задачи, поднять реплику базы для чтения.
• Контакты и процедура апгрейда у провайдера — сколько времени занимает апгрейд тарифа, нужен ли даунтайм, работает ли это в личном кабинете за минуты или требует обращения в поддержку.

Такой план стоит нулевой бюджет — это просто час планирования, — но экономит и деньги (не покупаете мощности заранее), и нервы (не выбираете решение в момент, когда сайт уже лежит от нагрузки). Единственное, что имеет смысл резервировать финансово — это не потратить весь бюджет первого месяца до копейки, оставив небольшой запас на непредвиденный внеплановый апгрейд, а не на постоянную избыточную мощность.

Ориентировочная структура распределения бюджета по месяцам

Ниже — не тарифы, а логика распределения расходов на инфраструктуру по мере роста продукта. Конкретные суммы зависят от вашего стека, региона и провайдера — считайте эту таблицу шаблоном для собственных расчётов, а не готовым бюджетом.

Ключевое правило: апгрейдить статью расходов тогда, когда метрика использования (CPU, RAM, объём базы, число писем, число серверов) реально показала рост, а не заранее "на всякий случай" — кроме бэкапа, который закладывается на максимально надёжном уровне с первого дня независимо от текущей нагрузки.

Частые вопросы