Supabase

Supabase - open-source платформа-бэкенд (BaaS, backend-as-a-service), self-host замена Firebase. Из коробки дает то, ради чего обычно берут облако Google: базу данных, аутентификацию, автоматический API поверх таблиц, подписки на изменения в реальном времени, хранилище файлов и админку. Разница в одном - все это работает НА ВАШЕМ сервере, данные лежат у вас, а не в чужом облаке.

Боль, от которой уходят: Firebase - это SaaS Google с вендор-локом и оплатой за чтения, где счет растет вместе с трафиком, а данные вы не контролируете. Облачный Supabase - тоже SaaS. Self-host Supabase снимает и то и другое: весь бэкенд у вас, лимитов и счетчика чтений нет, лицензия Apache-2.0 разрешает коммерческое использование и хостинг.

В основе - обычный Postgres. Это ключевая идея: вы создаете таблицу в базе, и она мгновенно становится REST API. Не нужно писать роуты, контроллеры и ORM - PostgREST генерирует API прямо из схемы, а GoTrue закрывает его аутентификацией и построчными политиками доступа (RLS) самого Postgres.

Supabase self-host - это не один продукт с единой версией, а композиция сервисов вокруг Postgres. Единого номера версии у него нет, поэтому в бейдже стоит только лицензия Apache-2.0, а версии компонентов - в таблице ниже. Все внешние запросы идут через один вход - API-gateway Kong, который маршрутизирует их по сервисам и закрывает Studio basic-авторизацией.

Ядро - Postgres 17. Поверх него PostgREST отдает автоматический REST API прямо из схемы таблиц, GoTrue выдает и проверяет JWT для аутентификации, Realtime транслирует изменения БД по WebSocket, Storage хранит файлы (с imgproxy для превью), postgres-meta и Studio дают веб-админку, supavisor пулит соединения к базе, а Edge Functions выполняют серверный код на Deno.

1. Создать VM

   Ubuntu 24.04 с Docker, тариф CPU4-RAM8-DISK100. Стек тяжелый: ~11 контейнеров и ~9 ГБ образов, меньше 8 ГБ RAM не берите.

2. Взять официальный docker-стек

   git clone --depth 1 github.com/supabase/supabase
   cp docker/.env.example docker/.env

   В .env прописать домен, секреты и вход в Studio.

3. Сгенерировать секреты и ключи

   POSTGRES_PASSWORD=...
   JWT_SECRET=... (>=32 символов)
   ANON_KEY=... (JWT, подписан на JWT_SECRET)
   SERVICE_ROLE_KEY=... (JWT, подписан на JWT_SECRET)
   DASHBOARD_USERNAME=admin
   DASHBOARD_PASSWORD=пароль-сервера

   ANON_KEY и SERVICE_ROLE_KEY - это HS256-JWT, подписанные на вашем JWT_SECRET. Демо-ключи из примера не годятся - Kong отдаст 401. В карте маркетплейса они генерятся автоматически.

4. Поднять стек

   docker compose pull
   docker compose up -d

   Старт тяжелый: Postgres 17, миграции всех сервисов, тянутся ~9 ГБ образов. Health поднимается по частям - подождите.

5. Закрыть TLS

   Caddy обратным прокси на Kong localhost:8000 - автоматический сертификат Let's Encrypt на magic-DNS домен.

Проверено на стеке от 2026.08.03, август 2026 (Postgres 17.6, Kong 3.9.3, GoTrue v2.189, PostgREST v14.12). На новых версиях компонентов результаты могут отличаться.

Studio закрыт basic-авторизацией на Kong: логин admin, пароль - пароль сервера. Наружу торчит только Kong через Caddy с TLS; сам Kong слушает localhost:8000 и напрямую не публикуется. API-ключи разделены по ролям: anon - публичный (для клиента, ограничен построчными политиками RLS), service_role - секретный, обходит RLS, его нельзя отдавать в браузер. Оба лежат в файле кредов на сервере.

Обновление - смена тегов образов в compose:

docker compose pull && docker compose up -d

Бэкап - дамп Postgres (в нем и данные, и вся конфигурация auth/storage):

docker exec supabase-db pg_dumpall -U postgres > supabase-db.sql

• PocketBase - легкий self-host бэкенд на SQLite (1 бинарь, ~30 МБ) для MVP, когда весь стек Supabase избыточен.
• Обратный прокси - Caddy или Nginx Proxy Manager для TLS и единого домена перед Kong.
• Почта - внешний SMTP для писем аутентификации (подтверждение, сброс пароля через GoTrue).
• Мониторинг - Prometheus и Grafana или Beszel по метрикам контейнеров и Postgres.