Self-hosted Supabase на своём VPS

Supabase — открытая альтернатива Firebase: Postgres, авторизация, storage и авто-API. Развернём его на VPS через Docker Compose и получим свой бэкенд без облачных лимитов.

Зачем self-host Supabase

Облачный Supabase удобен, но платные тарифы дорожают с ростом базы, а данные лежат не у вас. Self-host даёт полный контроль над Postgres, отсутствие лимитов на строки и хранение и предсказуемую стоимость — только цена VPS.

Supabase — это Postgres, который любит быстрый диск. NVMe у MAATRIX ускоряет запросы и бэкапы, а root-доступ нужен, чтобы крутить весь Docker-стек. Оплата картой РФ, СБП или криптой снимает проблему с зарубежным сервером.

Ещё один аргумент за self-host — резидентность данных и предсказуемость. В облачном Supabase вы платите за каждый гигабайт хранения и за трафик, а при росте проекта счёт растёт нелинейно. Развернув Supabase сами, вы получаете фиксированную стоимость (цена VPS от $8/мес) и полный доступ к Postgres: можно ставить расширения, тюнить конфиг, подключаться напрямую через psql и делать любые SQL-миграции без ограничений панели.

Ставим Docker и клонируем репозиторий

apt update && apt install -y docker.io docker-compose-plugin git
systemctl enable --now docker
docker --version

Клонируем официальный self-host и готовим .env:

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

Настраиваем секреты

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

openssl rand -base64 32   # POSTGRES_PASSWORD
openssl rand -hex 32      # JWT_SECRET

Впишите их в .env (POSTGRES_PASSWORD, JWT_SECRET, ANON_KEY, SERVICE_ROLE_KEY, DASHBOARD_PASSWORD). ANON_KEY и SERVICE_ROLE_KEY генерируются на основе JWT_SECRET через документацию Supabase.

Отдельно смените логин и пароль дашборда (DASHBOARD_USERNAME/DASHBOARD_PASSWORD) — по умолчанию это supabase/this_password_is_insecure_and_should_be_updated, и оставлять их нельзя. Проверьте, что .env не попадёт в git: он содержит все секреты вашего бэкенда.

Запуск стека

docker compose pull
docker compose up -d
docker compose ps

Поднимутся контейнеры: db (Postgres), auth (GoTrue), rest (PostgREST), storage, studio и kong (API-gateway). Kong — единая точка входа, он маршрутизирует запросы к нужному сервису по API-ключу. Studio по умолчанию слушает порт 8000; наружу его выпускать напрямую нельзя — это админ-панель со всеми данными. Закройте порт файрволом и пробросьте только через nginx с TLS и, желательно, basic-auth поверх:

server {
    listen 443 ssl http2;
    server_name supabase.example.com;
    ssl_certificate     /etc/letsencrypt/live/supabase.example.com/fullchain.pem;
    ssl_certificate_key /etc/letsencrypt/live/supabase.example.com/privkey.pem;
    location / {
        proxy_pass http://127.0.0.1:8000;
        proxy_set_header Host $host;
        proxy_set_header Upgrade $http_upgrade;
        proxy_set_header Connection upgrade;
    }
}

Бэкапы и частые ошибки

Postgres бэкапится штатным pg_dump прямо из контейнера — поставьте в cron:

docker compose exec -T db pg_dumpall -U postgres | gzip > /root/backup-$(date +%F).sql.gz

• Контейнеры падают циклом — не сменили дефолтные ключи или неверный JWT_SECRET; смотрите docker compose logs auth.
• Мало памяти — весь стек хочет минимум 2 ГБ RAM; берите план с запасом.
• Studio открыт всем — обязательно закройте порт 8000 файрволом и пускайте только через nginx с паролем.

Восстановление из дампа делается зеркальной командой: gunzip -c backup.sql.gz | docker compose exec -T db psql -U postgres. Проверьте процедуру заранее на тестовом сервере — бэкап, который ни разу не разворачивали, бэкапом не считается.

Ежедневные бэкапы MAATRIX дублируют ваш pg_dump на уровне всего диска — двойная страховка для базы, которую не хочется терять. Если проект вырастет, тариф апгрейдится без смены IP, а Postgres на NVMe продолжит отвечать быстро даже на аналитических запросах.

Частые вопросы