Supabase — open-source альтернатива Firebase на базе PostgreSQL

Supabase — платформа для серверной части приложения на базе PostgreSQL: управляемая платформа или self-hosted-стек на собственной инфраструктуре с базой данных, авторизацией, хранилищем, Realtime, Edge Functions и автоматически создаваемыми API.

Материал поможет выбрать вариант запуска, поднять Supabase через Docker, безопасно подключить приложение и проверить результат. Команды и тарифы сверены с официальными источниками 9 сентября 2026 года; самостоятельный запуск автором не подтверждён.

Содержание

1. Что входит в Supabase
2. Облако или self-hosted
3. Установка через Docker
4. Подключение приложения
5. Защита данных через RLS
6. Полезные сценарии
7. Тарифы и лимиты
8. Ограничения
9. Официальные ссылки

Что входит в Supabase

Каждый проект в управляемой платформе получает:

• выделенную базу PostgreSQL;
• автоматически создаваемые API;
• авторизацию и управление пользователями;
• файловое хранилище;
• Realtime API для событий в реальном времени;
• Edge Functions для серверного кода.

PostgreSQL сохраняет реляционную модель: таблицы, связи, объединения таблиц (JOIN), транзакции и миграции. Доступ из клиентских приложений ограничивается правами PostgreSQL и политиками защиты строк Row Level Security, или RLS.

Облако или self-hosted

Управляемая платформа

В Supabase Dashboard можно создать проект без самостоятельного управления инфраструктурой. Этот вариант подходит для быстрого старта и команд, которым не хочется обслуживать базу, API-шлюз и остальные компоненты стека.

Self-hosted через Docker

Docker-конфигурация разворачивает Supabase на собственном сервере или компьютере. Вы отвечаете за обновления, резервное копирование, HTTPS, секреты и состояние хранилища.

Минимальные требования для полного стека:

Логи и аналитика не входят в базовую Docker-конфигурацию. Их можно добавить отдельно, но потребление ресурсов увеличится.

Установка через Docker

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

1. Скопируйте закреплённую конфигурацию

На 9 сентября 2026 года в официальном руководстве используется тег self-hosted/v0.8.1:

git clone --depth 1 --branch self-hosted/v0.8.1 https://github.com/supabase/supabase
mkdir supabase-project
cp -rf supabase/docker/. supabase-project
cd supabase-project
cp .env.example .env

Запишите исходную версию для последующего обновления и загрузите образы:

printf 'ref=self-hosted/v0.8.1\n' > .supabase-version
docker compose pull

2. Создайте пароли и API-ключи

sh utils/generate-keys.sh
sh utils/add-new-auth-keys.sh

Проверьте в .env основные параметры:

• POSTGRES_PASSWORD — пароль базы данных;
• SUPABASE_PUBLISHABLE_KEY — ключ для клиентского приложения;
• SUPABASE_SECRET_KEY — секретный серверный ключ;
• SUPABASE_PUBLIC_URL — базовый адрес Supabase;
• API_EXTERNAL_URL — адрес, который Auth использует для URL обратного вызова;
• SITE_URL — адрес перенаправления по умолчанию после авторизации;
• DASHBOARD_USERNAME и DASHBOARD_PASSWORD — данные доступа к Studio.

Секретный ключ обходит RLS и предоставляет повышенные права. Его нельзя помещать в браузерный код, публичный репозиторий, URL или логи.

3. Запустите стек

sh run.sh start

Команда запускает docker compose up -d --wait и ждёт перехода сервисов в здоровое состояние. Проверьте контейнеры:

docker compose ps

У работающих сервисов должен появиться статус healthy. Если контейнер не запускается, проверьте диагностический скрипт и журнал конкретного сервиса:

sh tests/test-container-logs.sh
sh run.sh logs storage

4. Откройте Studio и проверьте API

По умолчанию Studio доступна через API-шлюз:

• Studio: http://localhost:8000;
• REST API: http://localhost:8000/rest/v1/;
• Auth API: http://localhost:8000/auth/v1/;
• Storage API: http://localhost:8000/storage/v1/;
• Realtime API: http://localhost:8000/realtime/v1/.

При открытии Studio браузер запросит DASHBOARD_USERNAME и DASHBOARD_PASSWORD. Сгенерированные реквизиты можно вывести командой:

sh run.sh secrets

Наблюдаемый результат успешной установки: все обязательные контейнеры имеют статус healthy, Studio открывается и принимает созданные учётные данные.

По умолчанию стек доступен по HTTP. Для продакшен-развёртывания, особенно при использовании OAuth, настройте HTTPS с действующим TLS-сертификатом. Официальная документация рекомендует поставить перед API-шлюзом обратный прокси-сервер (reverse proxy), например Caddy или Nginx.

5. Включите логи при необходимости

sh run.sh config add logs
sh run.sh start

Будут добавлены Logflare, Vector и просмотр журналов в Studio.

6. Остановите или полностью сбросьте установку

sh run.sh stop

Быстрая установка на Linux

Для поддерживаемых Debian, Ubuntu, RHEL, CentOS и Fedora доступен официальный установщик:

curl -fsSL https://supabase.link/setup.sh | sh

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

Обновление PostgreSQL 15 до 17

Перед обновлением сохраните резервную копию volumes/db/data и ключ pgsodium. Для миграции используйте официальный сценарий обновления. Если база зависит от timescaledb, plv8, plcoffee или plls, перейти на образы Supabase PostgreSQL 17 нельзя: эти расширения в них отсутствуют. Временный вариант — закрепить совместимый образ PostgreSQL 15 и подготовить миграцию отдельно.

Подключение приложения

Установите JavaScript-клиент:

npm install @supabase/supabase-js

Передавайте URL и publishable key через переменные окружения:

import { createClient } from '@supabase/supabase-js'

export const supabase = createClient(
  process.env.NEXT_PUBLIC_SUPABASE_URL!,
  process.env.NEXT_PUBLIC_SUPABASE_PUBLISHABLE_KEY!
)

Publishable key предназначен для кода, который получает пользователь: браузерного, мобильного или настольного приложения. Его безопасность зависит от корректных прав и RLS-политик.

Secret key используйте только в контролируемом серверном окружении:

import { createClient } from '@supabase/supabase-js'

export const supabaseAdmin = createClient(
  process.env.SUPABASE_URL!,
  process.env.SUPABASE_SECRET_KEY!
)

Supabase выводит устаревшие ключи anon и service_role из использования к концу 2026 года. До отдельного отключения в Settings > API Keys они могут работать параллельно с новыми ключами.

Минимальная проверка подключения:

const { data, error } = await supabase
  .from('posts')
  .select('*')
  .limit(1)

if (error) throw error
console.log(data)

Успешный результат — массив данных либо пустой массив без ошибки. Ошибка прав указывает на гранты PostgreSQL, а пустой результат при существующих строках может означать, что ни одна RLS-политика не разрешила чтение.

Защита данных через RLS

RLS позволяет PostgreSQL проверять доступ к каждой строке. Для таблиц, доступных клиентскому приложению, включите RLS и создайте политики для ролей anon и authenticated.

alter table posts enable row level security;

create policy "Users see own posts"
  on posts for select
  using (auth.uid() = user_id);

create policy "Authenticated can insert"
  on posts for insert
  with check (auth.role() = 'authenticated');

Сначала PostgreSQL проверяет табличные привилегии, затем применяет RLS. Отсутствующий грант приводит к ошибке доступа; политика, не совпавшая ни с одной строкой, обычно даёт пустой результат.

Полезные сценарии

Минимально жизнеспособный продукт (MVP) с авторизацией и общей базой

Исходное условие: веб-приложению нужны пользователи и таблицы, а отдельный backend пока не оправдан. Создайте облачный проект, подключите publishable key, включите RLS и добавьте политики для пользовательских данных. Результат проверяется регистрацией тестового пользователя и чтением только принадлежащих ему строк.

Ограничение: publishable key сам по себе не защищает данные. Без корректных грантов и RLS клиент может получить лишний доступ.

Локальный backend для разработки

Исходное условие: команде нужен воспроизводимый PostgreSQL, Auth, Storage и Realtime на локальной машине или тестовом сервере. Разверните закреплённый Docker-релиз, создайте секреты и дождитесь статуса healthy. Наблюдаемый результат — доступная Studio и успешный запрос через локальный API.

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

Серверные административные операции

Исходное условие: фоновому заданию или внутренней панели нужен повышенный доступ. Храните secret key только в серверном менеджере секретов и создайте отдельный серверный клиент. Результат проверяется операцией, которая недоступна обычному клиенту, при сохранении запрета на выдачу ключа браузеру.

Ограничение: secret key обходит RLS, поэтому серверный код обязан выполнять собственную проверку полномочий.

Тарифы и лимиты

Проверено 9 сентября 2026 года по официальной странице тарифов.

Free-проекты приостанавливаются после недели бездействия; одновременно разрешено не больше двух активных проектов. Платные планы включают $10 ежемесячных вычислительных кредитов (compute), чего достаточно для одного Micro-инстанса. Дополнительные проекты и превышение квот оплачиваются отдельно.

Ограничения

Supabase потребует дополнительной оценки, если:

• проекту нужна преимущественно документная NoSQL-модель;
• команда не готова самостоятельно обслуживать self-hosted инфраструктуру;
• серверная логика построена на secret key без собственного слоя авторизации;
• миграция существующего self-hosted проекта затрагивает несовместимые расширения PostgreSQL;
• требования к сертификации, резервным копиям или SLA выходят за возможности выбранного тарифа.

Официальные ссылки

• Сайт Supabase
• Документация
• Управляемая платформа
• Self-hosting через Docker
• API-ключи и правила безопасности
• Тарифы
• Статус платформы
• Переход self-hosted с PostgreSQL 15 на 17
• GitHub

Следующий шаг

Directus — headless CMS и backend как контентный хаб для мультисайтовой архитектуры

Связанные материалы

• Статья: Codex и GPT-5.6 Sol удалили мой VPS. Я только диктовал команды
• Блог: Данные важнее модели
• База знаний: GitLab — репозитории, CI/CD и агентные функции в одной платформе

Если вы выбираете между облачным Supabase и self-hosted установкой, заранее сопоставьте требования к данным, резервному копированию и эксплуатации.

Если захотите обсудить, как это применить у себя или в команде — пишите в Telegram @pimenov