Приложение Bubble на своём сервере: что придётся переделать

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

Проверьте, какого результата вы добиваетесь

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

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

Выделенное размещение не решает вопрос независимости автоматически. В руководстве по инфраструктуре Bubble Enterprise dedicated instance описан как инфраструктура, управляемая Bubble. Это отдельный вариант работы на платформе, а не архив исходного кода для установки на произвольный сервер. Сравнивайте его с исходной целью, не только со словом «выделенный».

Зафиксируйте приложение через один рабочий процесс

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

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

Выгрузка данных — начало сверки

В инструкции Bubble по экспорту данных описаны CSV, JSON и NDJSON, выбор типа данных и представления. Готовая выгрузка относится к выбранному составу. До работы зафиксируйте окружение, фильтры и перечень полей: факт скачивания файла не подтверждает полноту переноса всех нужных объектов.

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

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

Не переносите старые процессы вслепую

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

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

Переход в несколько проверяемых этапов

1. Опишите цель независимого размещения, состав приложения и исключения. Назначьте владельцев данных, инфраструктуры и приёмки процесса.
2. Подготовьте пилот одного сквозного сценария на новой стороне. Проверьте его на учебных данных, включая роли, ошибки и повторные действия.
3. Согласуйте модель переноса сущностей, файлов и связей. Выполните пробную загрузку в изолированную среду и сверку контрольных объектов.
4. Перенесите оставшиеся необходимые функции по реестру. Для плагинов и внешних операций проверьте замену отдельно, не только открытие страниц.
5. Определите момент остановки изменений или иной проверенный способ учёта данных, появившихся после пробной выгрузки. Учтите удалённые записи и отложенные задачи, а не только новые.
6. Перед переключением примите данные, права, рабочие процессы и восстановление. Для возврата заранее опишите судьбу операций, созданных уже в новой системе.

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

Что передать новой команде и владельцу

В составе результата нужны исходники новой реализации, инструкция развёртывания, описание конфигурации без секретов, структура данных и набор принятых сценариев. Отдельно укажите, кто обслуживает сервер, резервные копии и интеграции. Независимый хостинг имеет смысл, когда владелец способен обновлять и восстанавливать продукт по согласованному порядку.

Объём перестройки можно обсудить через разработку веб-приложения. Сверку данных дополняет материал о переносе таблиц в CRM, а вопросы прежнего поставщика — разбор миграции из зарубежных SaaS. Не подменяйте итог работающего приложения красивой копией интерфейса: после перехода должны сохраняться согласованные действия, данные и границы доступа.