Когда облако стало дороже железа
Счёт за облако уверенно перевалил за $200/месяц. Проект растёт, база пухнет, а вместе с ней — цифры в выписке. И тут меня посетила та самая мысль «а не собрать ли это дома?».
Калькуляция на салфетке:
- Облако: ~$200/мес за базу, storage, трафик и бэкапы
- VPS (8 GB RAM, 4 vCPU, 200 GB SSD): ~$40/мес + ~$2/мес за холодное хранилище бэкапов
- Экономия: ≈$158/мес или ~$1896/год
Для команд из РФ добавляется фактор доступности. Когда прод падает не из‑за багов, а из‑за геополитики и санкций — самое время взять управление в руки.
Контекст эпохи
2024–2025 — дорогие облака, волатильные тарифы и геополитические риски. Для небольших продуктов TCO облака часто хуже, чем «домашний» или выделенный сервер: платите за удобство и SLA, но теряете предсказуемость расходов. Self‑host — не романтика, а инструмент контроля unit‑economics.
Что такое «свой Supabase» простыми словами
Supabase — это не один сервис, а набор: PostgreSQL + PostgREST (REST‑API к БД) + GoTrue (аутентификация) + Realtime (стримы) + Storage (файлы) + Kong (шлюз) + Studio (админка). Всё крутится в Docker‑контейнерах и общается внутри одной сети.
Снаружи торчит только API‑шлюз и админка. Postgres наружу не выставляем никогда. Вот на этом, собственно, и держится безопасность.
Почему не Nhost (и наоборот)
Если вы GraphQL‑фанаты и живёте с Hasura — Nhost будет милее. Я же выбрал Supabase за простоту и зрелую экосистему. REST легко дебажить, документации много, интеграции с Next.js приятные.
Мой вердикт коротко: большинству — Supabase; GraphQL‑пуристам — Nhost. Менять потом можно, но это почти переписывание фронтенда.
Как я переносил (за выходные)
Никаких романтических мемуаров — рабочий чек‑лист.
- Подготовил VPS и диск под бэкапы. Настроил доступы, мониторинг, алерты.
- Развернул официальный Docker‑стек Supabase. Проверил, что наружу торчит только API‑шлюз и Studio.
- Создал новую БД, включил нужные расширения (pgvector, pg_net — по задачам проекта).
- Перенёс схему и данные. Сначала — dry‑run, потом — боевой прогон ночью.
- Настроил RLS‑политики, ключи и секреты. Дважды проверил.
- Перевёл Storage и CDN. Проставил правильные заголовки и права.
- Обновил фронтенд‑SDK ключи, прогнал регрессию, включил логирование.
- Сменил DNS и подстраховал rollback.
Бэкапы — не место для героизма. Автоматизируйте: ежедневные снапшоты БД, недельные — в холодное хранилище. Тестируйте восстановление, а не просто «верьте».
Бизнес‑инсайты
- Unit economics: $158/мес экономии → ~$1896/год. Окупился за 1–2 выходных внедрения.
- Контроль против аутсорса ответственности: платите временем за предсказуемость и независимость.
- Риски: электричество/аптайм/резервирование — закладывать в план (UPS, off‑site бэкапы, тесты восстановления).
- Масштаб: при росте нагрузки не стесняйтесь возвращаться в облако частично (гибрид).
Подводные камни, о которые я споткнулся
- Ограничения трафика у VPS‑провайдера. Проверьте заранее, сколько стоит перерасход.
- Права в Storage и RLS. Лишний «allow» может стоить дорого.
- Лимиты на соединения в Postgres. Тюним под реальную нагрузку, иначе подключений «на глаз» не хватит.
- Логи. Когда всё своё — внезапно нужны нормальные дашборды, а не «потом посмотрим».
Что в итоге
Экономия ощутимая, контроль полный, скорость — предсказуемая. Да, появляется зона ответственности, где раньше был SLA облака. Но лично мне спокойнее, когда ключи от продакшена лежат в моём кармане, а не «у доброго дяди».
Self‑host Supabase — это не геройство, а прагматичный выбор для проектов, которым важны: стоимость, предсказуемость и контроль. Если у вас похожие вводные — смело планируйте перенос. Это реально сделать за один уик‑энд.
См. также
- Proxmox: домашний дата‑центр
- PassWave — генератор паролей (использует Supabase)
- Статья о PassWave
