Хотите перенести Supabase на VPS и понять, что придётся обслуживать после установки? В официальной конфигурации self-hosted/v0.8.1 — 11 основных сервисов. С дополнительными Logflare и Vector для журналов — 13. К ним добавляются HTTPS-прокси, резервное копирование, мониторинг и отправка писем — на вашем сервере либо через внешние услуги.

В базовой установке каждому из этих сервисов соответствует отдельный контейнер. Все основные контейнеры можно разместить на одном VPS. Но у каждого компонента остаются свои настройки, версии и возможные причины отказа. Docker Compose помогает запускать их вместе; работоспособность приложения и восстановление данных проверяет администратор.

Какие 11 сервисов входят в установку

Состав ниже соответствует официальному Compose-файлу версии self-hosted/v0.8.1. Это версия конфигурации всего набора: номера версий PostgreSQL, Auth и остальных компонентов различаются.

В этой версии Logflare и Vector включаются отдельным файлом docker-compose.logs.yml: первый хранит и обрабатывает журналы, второй собирает их. В старых установках они могли входить в основной состав, а шлюзом служил Kong. Поэтому число контейнеров из старой инструкции может отличаться от вашего.

Чтобы увидеть свою конфигурацию, выполните из каталога установки с настроенным .env:

docker compose config --services
docker compose ps -a

Первая команда перечисляет описанные сервисы, вторая — созданные контейнеры, включая остановленные. Если запускали Compose с дополнительными параметрами -f или профилями, используйте те же параметры при проверке. При ошибках подстановки переменных сначала исправьте конфигурацию.

Для работающих постоянных сервисов ожидается Up или running, а при наличии проверки здоровья — healthy. Статусы restarting, exited или unhealthy требуют изучения журналов. Отсутствие отметки healthy у контейнера без такой проверки само по себе не означает неисправность.

Можно ли оставить только нужные компоненты

Можно сократить состав, если приложение действительно не использует соответствующие возможности. В руководстве Supabase прямо допускается исключение Realtime, Storage, imgproxy и Edge Runtime вместе с их зависимостями.

Начните со списка функций приложения: вход пользователей, REST-запросы, подписки, файлы, обработчики Edge Functions. Затем на тестовой копии отключайте ненужные компоненты и проверяйте оставшиеся сценарии. Учитывайте depends_on в Compose, настройки шлюза и обращения из приложения. Например, удаление imgproxy при включённом преобразовании изображений нарушит эту функцию Storage.

Сохраните исходные Compose-файлы перед изменением. Если тест перестал проходить, верните конфигурацию и нужный сервис. Данные в томах при такой проверке удалять не требуется.

Если нужен только PostgreSQL, отдельная установка базы обычно проще в обслуживании. Но приложение, использующее Supabase Auth, Storage или клиентскую библиотеку для API, нельзя перенести на обычный PostgreSQL одной заменой строки подключения: эти функции придётся сохранить или заменить.

Какой VPS нужен и сколько проектов на нём поместится

В официальном руководстве указаны минимальные ресурсы: 2 ядра CPU, 4 ГБ RAM и 40 ГБ SSD. Рекомендованный ориентир — 4 ядра, от 8 ГБ RAM и от 80 ГБ SSD. Это требования к запуску, а не обещание определённого числа пользователей. Дополнительные журналы, обработка изображений, тяжёлые SQL-запросы и функции увеличивают потребление.

Для оценки разверните выбранный состав и воспроизведите рабочую нагрузку: входы, запросы, загрузки файлов и подписки. На Linux снимите показатели до нагрузки и во время неё:

docker stats --no-stream
free -h
df -h

docker stats показывает потребление контейнеров, free — память всей системы, df — место на файловых системах. Смотрите на доступную память available, задержки запросов и рост диска. Если память заканчивается или контейнеры аварийно перезапускаются, выясните, какой компонент расходует ресурсы; затем оптимизируйте нагрузку, уменьшите состав или увеличьте RAM. Для диска оставляйте место под данные, образы, журналы и операции обновления.

Стандартная самостоятельная установка рассчитана на один проект. Несколько независимых проектов обычно означают несколько наборов сервисов с отдельными данными, ключами, именами контейнеров и сетевыми настройками. Их можно разместить на одном VPS, если хватает ресурсов, но отказ этого сервера затронет все проекты. Автоматического резервирования Docker Compose не добавляет.

Что нужно настроить помимо контейнеров

HTTPS и адреса приложения. Перед рабочим использованием настройте домен и обратный прокси с TLS-сертификатом, например Caddy или Nginx. В .env проверьте SUPABASE_PUBLIC_URL, API_EXTERNAL_URL и SITE_URL: последний задаёт адрес вашего приложения, куда возвращается пользователь. Для Realtime прокси должен пропускать WebSocket-соединения. После настройки проверьте вход и переход по ссылке восстановления пароля с внешнего устройства.

Отправка писем. Для подтверждения регистрации и восстановления пароля нужен SMTP-сервис. В типовой конфигурации его параметры задаются через SMTP_HOST, SMTP_PORT, SMTP_USER, SMTP_PASS и адрес отправителя. Проверьте реальное получение письма и правильный адрес ссылки. Если письмо не приходит, смотрите журнал auth и результат доставки у почтового провайдера. Собственный почтовый сервер добавит отдельную задачу обслуживания; внешний SMTP уменьшает её объём.

Доступ администратора и ключи. До публикации замените значения из примера на собственные, задайте пароль Studio через DASHBOARD_PASSWORD и ограничьте доступ к панели. Секретный API-ключ SUPABASE_SECRET_KEY и прежний SERVICE_ROLE_KEY должны оставаться на доверенной серверной стороне. Для клиентского приложения используются публичные ключи, а доступ к строкам базы задаётся политиками RLS — Row Level Security.

Открытые порты. В docker compose ps посмотрите столбец PORTS. Публикация на 0.0.0.0 означает привязку ко всем IPv4-интерфейсам хоста. Доступ к портам базы и пула подключений оставьте только нужным клиентам; внутренние сервисы не требуется открывать всему интернету. Проверяйте ограничения извне: опубликованные Docker-порты могут обходить ожидаемые правила UFW.

Большая часть конфигурации самостоятельного Supabase хранится в переменных окружения и файлах. Наличие Studio не означает, что все настройки доступны через панель. Для VPS используйте официальный вариант Docker Compose: supabase start запускает среду локальной разработки, которую нельзя выставлять в интернет как рабочую установку.

Что резервировать, чтобы восстановить приложение целиком

Сначала определите допустимую потерю данных и время восстановления. Например, ежедневная копия без промежуточного сохранения изменений оставляет риск потери почти суток работы. Восстановление PostgreSQL на выбранный момент времени, или PITR, требует отдельной настройки резервирования и архивирования журналов транзакций.

В план резервного копирования включите:

• Базу данных: данные приложения, Auth, служебные схемы, роли, права, политики и необходимые расширения. Копия только схемы public не сохраняет весь Supabase.
• Файлы Storage: в базовом варианте они находятся в volumes/storage, при подключении внешнего S3-совместимого хранилища — в нём. Записи о файлах в PostgreSQL не заменяют сами объекты.
• Конфигурацию и секреты: .env, Compose-файлы, настройки прокси, версии образов и ключи шифрования. В частности, именованный Docker-том db-config содержит ключ pgsodium: при использовании хранилища секретов Vault его потеря может сделать секреты невосстановимыми.
• Код и настройки Edge Functions: каталог volumes/functions, необходимые переменные и дополнительные файлы вашей установки.

Храните защищённую копию вне рабочего VPS. Для PostgreSQL используйте подходящий механизм резервирования: логический дамп либо физическую копию по правилам СУБД. Простое копирование каталога работающей базы обычным архиватором не гарантирует пригодный результат. Снимок сервера тоже требует проверки согласованности и охвата всех дисков.

На отдельной тестовой установке восстановите копию и проверьте данные в ключевых таблицах, вход существующего пользователя и скачивание сохранённого файла. Убедитесь, что объекты Storage соответствуют записям в базе. Для согласованной копии БД и файлов предусмотрите остановку записей на время копирования либо другую проверенную процедуру согласования.

Ошибки восстановления нельзя считать безобидными только потому, что таблицы появились. Проверьте роли, политики и расширения, затем повторите восстановление с исправленной процедурой. Запишите фактическое время: оно покажет, укладывается ли ваш план в допустимый простой.

Как обслуживать обновления

Обновляйте согласованный набор версий и заранее проверяйте изменения на тестовой копии. Новейший образ отдельного компонента может требовать другой конфигурации или изменений в базе.

В современных установках есть официальный скрипт update.sh. Если он присутствует, на хосте установлены git и jq, а в .supabase-version записана исходная версия, предварительный просмотр запускается из каталога установки:

sh update.sh --dry-run

Просмотр показывает изменения и конфликты без их применения. Если исходная версия неизвестна, сначала восстановите сведения о ней по официальной инструкции: неполный отчёт не подтверждает совместимость.

Перед применением сделайте отдельные копии БД и Storage, сохраните конфигурацию и проверьте восстановление. Сам update.sh резервирует конфигурационные файлы, но не данные PostgreSQL и Storage. После устранения конфликтов выполните docker compose config -q: успешная проверка завершается без сообщения об ошибке. Затем обновляйте тестовую установку, проверяйте приложение и только после этого планируйте обновление рабочего сервера.

Отдельный случай — смена основной версии PostgreSQL. В рассматриваемой конфигурации используется PostgreSQL 17. Каталог данных от PostgreSQL 15 нельзя просто подключить к новому образу: нужна процедура обновления с проверкой расширений и возможностью отката. Если обновление меняло данные, возвращение прежних контейнеров само по себе не вернёт прежнее состояние базы. Для отката может потребоваться восстановление копии, а новые записи после неё придётся учитывать отдельно.

Как понять, какой сервис не работает

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

Если один из сценариев не работает, начните с соответствующего компонента:

docker compose logs --tail=100 auth
docker compose logs --tail=100 storage
docker compose logs --tail=100 db

Команды читают последние сообщения выбранного сервиса. Для другой неисправности подставьте имя из docker compose config --services.

• Не работает вход или восстановление пароля: проверяйте auth, SMTP, внешние URL и адрес возврата у провайдера входа.
• Studio открывается, но запросы к данным завершаются ошибкой: проверяйте rest, db, ключи, права и RLS. Пустой результат запроса может быть следствием политики доступа.
• Не загружаются или не скачиваются файлы: проверяйте storage, свободное место, права на каталог или доступ к внешнему хранилищу.
• Несколько сервисов одновременно теряют соединение: начните с PostgreSQL, памяти, диска и сети хоста. Сбой общей зависимости может выглядеть как несколько отдельных ошибок.

Не используйте reset.sh и удаление томов как универсальный способ ремонта: сброс способен уничтожить данные и ключи. Сначала сохраните журналы и определите причину.

Для постоянной эксплуатации нужны уведомления о недоступности приложения, нехватке диска, сбоях резервного копирования и перезапусках. Настройте срок хранения журналов. Если Docker использует json-file, задайте ротацию через max-size и max-file — например, 10m и 3 для трёх файлов по 10 МБ на контейнер. Без ограничений журналы могут заполнить диск. Новые параметры журналирования нужно применить к пересозданным контейнерам в запланированное окно обслуживания. При включённом Logflare отдельно контролируйте объём его данных.

Когда самостоятельное размещение оправдано

Supabase на VPS подходит, когда нужны его функции, контроль над размещением и есть человек, который отвечает за обновления и восстановление. Если команда хочет заниматься преимущественно приложением и пользоваться управляемыми резервными копиями, стоит сравнить этот вариант с облачным Supabase. Если нужен только SQL-доступ к базе, оцените отдельный PostgreSQL.

В бюджет самостоятельного размещения включайте VPS, хранение резервных копий, почту, мониторинг, тестовую среду и время администратора. Фиксированное число часов обслуживания в месяц здесь нельзя обещать: оно зависит от нагрузки, изменений и требований к доступности.

Для размещения можно подобрать VPS/VDS HSTQ с SSD или NVMe и достаточным объёмом памяти. При выборе передайте число проектов, используемые компоненты и объём БД и файлов. На странице услуги отдельно обозначены границы поддержки: настройка приложений, оптимизация и постоянное администрирование согласуются как отдельные работы. До запуска определите, кто обновляет Supabase, проверяет копии и восстанавливает приложение при сбое.