Self-hosted Supabase: развернуть у себя

Self-hosted вариант нужен там, где облако не подходит по требованиям, а не там, где хочется сэкономить: экономия появляется только на объёме, а обязанности - сразу.

Зачем

Данные не должны уходить наружу. Персональные данные, медицина, финансы, договор с клиентом, прямо запрещающий передачу третьим лицам. Самая честная причина: тут вопрос не в цене.

Объём. На больших данных и большом трафике счёт за облако растёт, и в какой-то момент сервер оказывается дешевле.

Независимость. Тарифы, доступность и решения сервиса вам неподконтрольны.

Полный контроль над базой. Расширения, настройки, прямой доступ - всё, что в облаке ограничено.

Чего в этом списке нет: «проще» и «быстрее». Обычно наоборот.

Что входит в стек

Это не одна программа, а набор сервисов, работающих вместе:

• PostgreSQL - собственно база.
• Слой доступа по HTTP, превращающий таблицы в API.
• Сервис авторизации - регистрация, вход, токены.
• Хранилище файлов.
• Среда выполнения функций.
• Панель управления.
• Обратный прокси, связывающий всё это.

Разворачивается обычно контейнерами. Принципы эксплуатации те же, что описаны для self-hosted стека n8n: тома для данных, переменные окружения, обратный прокси с сертификатом.

Практическая деталь: обслуживать придётся весь набор. Обновление одного сервиса может потребовать согласования с остальными, и это основная разница с облаком, где эту работу делают за вас.

Что бэкапить

Три вещи, и все обязательны:

База данных. Регулярно, автоматически, с проверкой восстановления. Бэкап, который никогда не восстанавливали, бэкапом не является.

Файлы хранилища. Они лежат отдельно от базы, и про них забывают. База без файлов восстановит ссылки на несуществующие объекты.

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

Плюс переменные окружения и конфигурация: восстанавливать их по памяти - отдельное удовольствие.

Обновления

Порядок, который снижает риск:

1. Читать примечания к версии. Изменения, ломающие совместимость, здесь встречаются.
2. Бэкап до обновления. Всегда.
3. Сначала на тестовом окружении. Обновление стека - не то же самое, что обновление одной программы.
4. Обновлять регулярно. Пропущенные версии превращают обновление в миграцию через несколько мажорных версий.
5. Проверять после. Авторизация, доступ к данным, загрузка файлов, функции - по списку.

Чего не будет по сравнению с облаком

Честный список:

• Автоматических бэкапов - настраиваете сами.
• Масштабирования по кнопке - планируете ресурсы сами.
• Мониторинга из коробки - ставите сами.
• Гарантий доступности - она равна доступности вашего сервера.
• Обновлений без вашего участия.
• Части возможностей, доступных только в облачной версии: набор различается и меняется, проверять надо перед решением, а не после.

Практический ориентир: разворачивать у себя стоит, когда есть требование или объём. Для прототипа и небольшого проекта облако проще, а сэкономленное время дороже разницы в счёте.

Общая картина - гид по Supabase. Про автоматизации вокруг базы - связка с n8n.