Как развернуть Supabase на своём сервере

Supabase разворачивается на ваш сервер одним шаблоном из каталога: девять контейнеров, домен с сертификатом, сгенерированные ключи. Доступ к машине остаётся только у вас — платформа к серверу не подключается.

Что именно поднимается

Девять сервисов, а не «образ Supabase»: такого образа не существует, Supabase — это набор служб вокруг Postgres.

Панель открывается на том же домене под basic auth — отдельного адреса для неё заводить не нужно.

Шаг 1. Проверьте, что сервер потянет

Стек просит около 4,7 ГБ памяти суммарными лимитами. Рабочая рекомендация — от 8 ГБ: остаётся запас под ваши данные и под сам агент.

Платформа сейчас не считает это за вас перед установкой, поэтому посчитайте сами. Если сервер уже под наблюдением, свободная память видна на его карточке — Мониторинг серверов.

Шаг 2. Заведите запись DNS — до всего остального

A-запись поддомена на адрес сервера:

Пропустить нельзя. Сертификат выпускает Let's Encrypt, и владение доменом он проверяет, обращаясь по этому имени к вашему серверу. Записи нет — проверка не пройдёт.

nslookup db.вашдомен.ru

В ответе должен быть адрес вашего сервера. Обновление записи занимает от нескольких минут до часа.

Шаг 3. Подключите сервер

Проект → Развёртывание → «Новый сервер» → «Команда установки».

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

Подробнее — Подключить сервер без входящих портов.

Шаг 4. Разверните Supabase из каталога

«Развернуть приложение» → «Из каталога» → Supabase.

Из обязательного — идентификатор (латиницей, задаёт имя папки на сервере, менять его потом нельзя) и домен с шага 2.

Пароли и ключи придумывать не нужно. ANON_KEY и SERVICE_ROLE_KEY — это JWT, подписанные секретом вашей установки; платформа генерирует и секрет, и производные от него ключи. Придуманные руками они были бы слабее и повторялись бы между установками.

Почта, внешние входы и прочее включаются переключателями в той же форме: включили «SMTP» — появились пять полей под него, не включили — их нет.

Шаг 5. Дождитесь проверки здоровья

Порядок: поднялись контейнеры → все девять прошли проверку здоровья → домен начал отвечать.

На прогретом хосте подъём занимает около 23 секунд при бюджете в 900. Первая установка дольше, и заметно: девять образов сначала скачиваются, и это самая долгая часть — она в эти 23 секунды не входит.

Не прошла проверка — трафик на домен не переключается.

Шаг 6. Заберите ключи подключения

Карточка приложения → «Ключи подключения» → «Показать ключи». Там же адрес API, который вы пропишете в клиенте.

Показываются только ANON_KEY и SERVICE_ROLE_KEY — то, без чего к базе не подключиться. Пароля базы в списке нет намеренно: он нужен контейнеру, а не человеку. Каждая выдача пишется в журнал: ключ, показанный однажды, дальше живёт вне платформы, и единственное, что можно гарантировать, — знание о том, кто и когда его забрал.

Чего в этом наборе нет

Три вещи из официального compose в набор не входят, и про две из них стоит знать заранее:

• Edge Functions и пул соединений (Supavisor) — их нет в этой версии набора. База доступна изнутри хоста и через PostgREST.
• Аналитика и логи в Studio — и вот это решение, а не пропуск. Сборщик логов в официальном compose монтирует внутрь контейнера сокет Docker. Пометка «только чтение» на unix-сокете не мешает слать через него команды Docker API, то есть это полный доступ к демону — фактически root на хосте. Запрет сокета Docker внутри контейнеров — центральное правило платформы, и лог-панель его не перевешивает.

Служебная база _supabase при этом создаётся сразу: когда аналитика появится, это будет обновление версии, а не пересборка стека с нуля.

Порт базы наружу не открыт

Снаружи доступен только HTTP через прокси. Postgres виден изнутри хоста и через PostgREST и SQL-редактор в Studio — открытый в интернет порт 5432 у self-hosted-установок это первое, что находят сканеры.

Что действительно стоит закрыть на самом сервере — Ключи и пароли не в переписке.

Почему данные в томах, а не в папках

Официальный compose кладёт данные в каталоги на хосте. Здесь — в именованные тома, и это не вкусовщина: резервное копирование платформы умеет тома, перед обновлением снимает архив каждого и возвращает их целиком при откате. Каталог на хосте в этот механизм не попадает вовсе.

Файлы инициализации базы приезжают вместе с шаблоном и монтируются только на чтение. Секретов в них нет — значения подставляются из окружения контейнера.

Что проверить после установки

curl -sI https://db.вашдомен.ru/rest/v1/ | head -3

Ответ 401 — это норма и признак, что всё работает: корень REST закрыт от анонимного запроса самим Supabase. Ключ в заголовке apikey — и ответ станет осмысленным.

Если видите редирект в неожиданное место, смотрите на Location: почему именно на него — Редирект вёл на 0.0.0.0:3000.

Если Supabase у вас уже работает

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

Чем это было оплачено у нас — Мы уходим с Coolify на своё.

Рядом с этим

• То же самое, но проще, на двух контейнерах — Как развернуть n8n.
• Выкат своего приложения из Git — Деплой.
• Полное описание раздела — Деплой из Git.