Переезд с Supabase Cloud на VPS: база, пользователи, файлы и функции

MAATRIX · 17 октября 2026 · 8 мин чтения

В Supabase слово «проект» объединяет несколько разных систем. Таблицы живут в PostgreSQL, вход обслуживает Auth, файлы — Storage, отдельная логика выполняется в функциях, а приложение обращается к API. Поэтому успешное восстановление базы ещё не означает, что проект переехал целиком.

Удобнее представить миграцию как последовательность приёмок: сначала данные читаются, затем пользователь входит, потом получает свой файл, наконец выполняются функции и события. Такой порядок помогает видеть конкретную проблему, а не разбирать большое сообщение «после переноса ничего не работает».

Что должно оказаться на новой площадке

Составьте перечень компонентов: схемы базы, расширения, роли, политики RLS, пользователи, buckets, объекты, функции, внешние провайдеры входа, почта и вебхуки. Укажите объём и способ переноса каждого пункта. Дополнительно проверьте внешние приложения, которые обращаются к проекту: сайт, мобильный клиент, бот, автоматизация.

В официальном маршруте восстановления из Platform описан перенос базы, но связанные сервисы требуют отдельного внимания. Объекты Storage, настройки провайдеров и развёрнутые функции нельзя считать содержимым обычного SQL-дампа.

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

Сначала поднимите чистый Supabase

Используйте поддерживаемую схему самостоятельного размещения и зафиксируйте версии образов. Руководство Docker описывает состав сервисов и конфигурацию. Не выбирайте случайный набор контейнеров из старой публикации: совместимость компонентов важнее короткого файла запуска.

Задайте собственные секреты, публичный адрес API и настройки административного доступа. Панель управления не должна быть доступна с паролем из примера. Базу оставьте во внутренней сети, а внешние обращения направляйте через предусмотренный шлюз и HTTPS.

Проверьте чистую установку до восстановления: вход в панель, создание тестовой таблицы, обращение к API и запись тестового объекта. Так проблемы установки не смешаются с ошибками миграции. Затем удалите временные данные штатным способом либо восстановите чистую исходную конфигурацию перед импортом.

Полезно заранее ознакомиться с материалом о составе self-hosted Supabase. Здесь нужно сопровождать набор сервисов, а не один процесс PostgreSQL с дополнительным логотипом.

База: структура, данные и правила доступа

Проверьте совместимость версий PostgreSQL и используемых расширений. Выполняйте экспорт и восстановление по официальному маршруту для вашей конфигурации, сохраняя журналы команд. Не запускайте произвольный полный импорт поверх рабочей целевой базы без понимания того, какие системные объекты он изменит.

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

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

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

Пользователи и вход: данные аккаунта не равны действующей сессии

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

Настройте SMTP, адрес отправителя и шаблоны ссылок. Проверьте регистрацию, подтверждение email, восстановление пароля и приглашение пользователя, если оно используется. Все ссылки должны вести на новый публичный адрес, а не в старую панель или тестовый домен.

Для внешнего входа перенастройте провайдеров и разрешённые callback-адреса. Проверьте именно существующий аккаунт: создание нового пользователя через тот же email не должно незаметно породить дубликат или потерять связи с данными.

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

Storage: перенести содержимое и сохранить смысл доступа

Составьте список buckets и их режимов доступа. Перенесите объекты, сохраняя ключи, на которые ссылается база. Если меняете структуру путей, подготовьте явное преобразование ссылок и возможность проверить его результат.

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

Публичные и закрытые объекты проверяйте раздельно. Подписанная ссылка со старой площадки не обязана работать на новой; приложение должно создавать новую ссылку с правильными параметрами. Закрытый файл должен быть доступен владельцу и недоступен постороннему пользователю.

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

Функции, события и внешние интеграции

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

Проверьте каждую функцию на тестовых данных. Убедитесь, что она обращается к новой базе и возвращает ожидаемый результат. Для внешних операций используйте тестовые аккаунты или безопасные действия. Повторное создание платежа не должно быть способом проверки сетевой связности.

Вебхуки и события проверяйте сквозным сценарием. Изменение записи должно привести к одному ожидаемому действию. На время переключения исключите параллельную отправку из двух окружений либо обеспечьте защиту от повторной обработки по идентификатору события.

Если приложение использует Realtime, проверьте подключение, получение изменения и восстановление связи после краткого разрыва. Успешный обычный REST-запрос не подтверждает работу долгоживущих соединений через новый прокси.

Репетиция переключения

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

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

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

Сохраните журнал миграции: версии, время выгрузки, контрольные показатели и результаты проверок. Через неделю он поможет понять, относится ли найденное расхождение к переезду или появилось позже.

Контрольный набор для приёмки проекта

Подготовьте несколько связанных объектов: двух пользователей, закрытый документ, публичное изображение и запись, которая вызывает функцию. Запишите ожидаемый результат каждого действия до переноса. После восстановления выполните проверки с обычными пользовательскими ключами, затем повторите их после перезапуска сервисов. Такой небольшой набор хорошо обнаруживает смешанное окружение, где интерфейс уже новый, а функция продолжает обращаться к старой базе. Не используйте для этой проверки только административную панель: её права отличаются от прав посетителя. Сохраните время запроса и идентификатор объекта, чтобы быстро найти событие в журналах, если один этап цепочки завершился иначе, чем ожидалось.

VPS и запас для всей системы

Для пилота полного Supabase разумно рассматривать MAATRIX Heka Standard с 4 vCPU и 8 ГБ памяти, сверяя требования текущей версии. Для базы, файлов и активных сервисов может понадобиться Maat Pro с 16 ГБ или разнесение компонентов. Это ориентир для испытания, а не гарантия вместимости.

Подойдут поддерживаемые Ubuntu или Debian. Рассчитайте диск по базе, объектам, журналам и временному месту для восстановления. Во время миграции расход часто выше постоянного: рядом лежат архив и восстановленные данные. Резервные копии храните вне рабочего сервера.

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