Instant Cloud закроется в 2027 году — миграцию нельзя делать одним бэкапом

Переносить приложение с Instant Cloud нужно в два этапа: сначала развернуть собственный экземпляр InstantDB и проверить восстановление пробной копии, затем остановить запись в облаке, создать свежий бэкап и переключить клиентов. Один заранее скачанный архив не сохраняет изменения, которые пользователи и фоновые процессы успеют записать после его создания.

Облачные приложения отключат 31 августа 2027 года. До этой даты нужно подготовить инфраструктуру, проверить данные, файлы и авторизацию, а финальное переключение провести в окно обслуживания: после появления новых записей в собственной базе возврат к облачной копии потребует отдельной синхронизации.

Сначала выберите целевую инфраструктуру

Объявление Instant устанавливает две разные даты: облачные приложения прекратят работу 31 августа 2027 года, а их резервные копии останутся доступны до 31 августа 2028 года. Доступность архивов в дополнительный год не продлевает работу приложений.

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

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

Проведите репетицию восстановления

Инструкция InstantDB по миграции делит процесс на репетицию и финальное переключение: сначала восстанавливается тестовая копия, затем запись в облаке приостанавливается и создаётся свежий архив. Репетиция проверяет не только сам бэкап, но и длительность восстановления — от неё зависит реалистичное окно недоступности записи.

1. Разверните собственный экземпляр и проверьте доступность API, панели и файлового хранилища по HTTPS.
2. Настройте почтового провайдера, доступ к панели и используемые приложением вебхуки.
3. Выберите для восстанавливаемого приложения новый идентификатор в формате UUID.
4. Восстановите пробный бэкап и сопоставьте схему, правила доступа, прикладные данные, файлы и шаблоны писем с облачной версией.
5. Измерьте полное время восстановления и функциональной проверки, предусмотрев запас на скачивание архива и устранение ошибок.

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

Подготовьте авторизацию и новые адреса

Для каждого используемого OAuth-провайдера на восстановленном приложении нужно заново создать конфигурацию, перенести идентификатор клиента, секрет и остальные параметры. У провайдера добавьте адрес обратного вызова собственного сервера вида https://api.example.com/runtime/oauth/callback, но облачный адрес не удаляйте до завершения миграции.

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

Заранее подготовьте, но пока не выпускайте клиентскую конфигурацию. В каждом вызове инициализации замените идентификатор приложения, адрес API и адрес WebSocket; для Admin SDK потребуются также новый административный токен и адрес API. В перечень клиентов включите веб-приложение, мобильные сборки, серверные задания и другие процессы, способные записывать данные без участия пользователя.

Инструменты командной строки по умолчанию работают с Instant Cloud. Для собственной установки задайте INSTANT_CLI_API_URI и INSTANT_CLI_DASH_URI, заново войдите в систему и убедитесь, что instant.config.ts содержит адреса собственного API и панели. Иначе следующая команда управления может обратиться к облачному приложению.

Остановите запись и восстановите свежую копию

В согласованное окно включите для облачного приложения режим только для чтения и подождите 30 секунд, чтобы завершились уже начатые изменения. Чтение, активные запросы и присутствие продолжат работать, но новые записи, включая накопленные на устройствах автономные изменения, будут отклоняться.

После паузы создайте резервную копию по требованию — архив с репетиции для финального переноса не подходит. Восстановите свежую копию с тем UUID, который уже указан в подготовленных клиентах, и до их выпуска проверьте:

• схему и правила разрешений;
• контрольные данные и доступность файлов;
• вход по коду и через каждый OAuth-провайдер;
• отключённый режим только для чтения на собственном экземпляре;
• ответ системной проверки с состоянием журнала транзакций wal: ok.

Если хотя бы одна проверка не пройдена, не переключайте клиентов. Облачная база остаётся согласованной точкой возврата, пока запись в ней остановлена, а собственный экземпляр ещё не принимает новые изменения.

Переключите клиентов и зафиксируйте границу отката

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

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

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

Читайте также:

• Сотрудники уводят клиентов: что делать?
• Текст речи нельзя писать как статью: как подготовить выступление для слуха
• Цена тюрьмы зависит от методики: почему страны нельзя сравнить одним рейтингом