Lovable в России: как строить сайты на ИИ и не нарваться на Роскомнадзор
Честный разговор о том, как пользоваться крутыми зарубежными инструментами и при этом не нарушать закон
──────────────────────────────────────────────────
Сначала — о самом Lovable, если вдруг вы ещё не слышали
Lovable — это один из самых впечатляющих AI-инструментов последних лет. Вы описываете приложение словами, а он генерирует полноценный фронтенд на React + TypeScript, сам настраивает базу данных, аутентификацию, storage, edge-функции. Причём не «набросок» — а рабочий код, который можно сразу деплоить. Стартап запустился в начале 2024 года и за первые два месяца набрал $10 млн ARR с командой в 15 человек. Для сравнения: это быстрее, чем росли Notion, Figma и большинство SaaS-единорогов.
Для тех, кто делает сайты и небольшие веб-приложения — это что-то вроде суперсилы. Прototип за час, MVP за вечер. Никаких backend-разработчиков, никаких бесконечных итераций с DevOps.
Но у этого инструмента есть один нюанс, который в России становится юридической миной.
──────────────────────────────────────────────────
Проблема: Supabase живёт не там, где нужно
Под капотом Lovable работает Supabase — open-source альтернатива Firebase, построенная на PostgreSQL. Это мощная штука: вы получаете реляционную базу данных, аутентификацию, файловое хранилище и realtime-подписки прямо из коробки.
Когда вы создаёте проект в Lovable и подключаете облачную базу (Lovable Cloud), вам предлагают выбрать регион размещения: Америка, Европа или Азиатско-Тихоокеанский регион. Российских серверов в этом списке нет и не предвидится. И да — выбор региона фиксируется намертво, изменить его потом нельзя.
Казалось бы, ну и ладно. Но в России с 1 июля 2025 года это стало реальной правовой проблемой.
──────────────────────────────────────────────────
ФЗ-152: что изменилось и почему это важно
Федеральный закон №152 «О персональных данных» существует давно, но в 2025 году в него внесли поправки, которые резко ужесточили требования. Суть новой редакции такова:
Запись, систематизация, накопление, хранение и извлечение персональных данных граждан РФ с использованием баз данных, находящихся за пределами России, — запрещены.
Раньше закон говорил: «храните хотя бы копию в России». Теперь формулировка жёстче: первичная запись данных должна происходить на российских серверах. Данные не могут сначала уйти в Европу, а потом оттуда скопироваться к нам.
Что считается персональными данными? Практически всё, что позволяет идентифицировать человека: имя, телефон, email, IP-адрес. То есть если у вас на сайте есть форма регистрации или даже просто форма обратной связи с полем «имя» — вы уже оператор персональных данных и обязаны соблюдать закон.
Санкции за нарушение для юрлиц — до 300 тысяч рублей за несвоевременное уведомление РКН, плюс Роскомнадзор имеет право приостановить работу информационной системы. А с 2027 года планируется ещё ужесточение ответственности.
Вывод прямолинейный: если вы используете Lovable Cloud или внешний Supabase с европейским/азиатским сервером — вы нарушаете закон, как только начинаете собирать данные российских пользователей.
──────────────────────────────────────────────────
Хорошая новость: выход есть, и он элегантный
Lovable — открытый инструмент с точки зрения экспорта кода. Вы не заперты внутри платформы. Весь сгенерированный код (React, TypeScript, SQL-миграции) синхронизируется с GitHub. Это и есть ключ к решению.
Схема работает в три шага:
Шаг 1: Строим в Lovable, синхронизируем с GitHub
Делаете проект как обычно. Ловабл генерирует красивый фронтенд, настраивает Supabase, всё работает. Подключаете GitHub-интеграцию (кнопка в правом верхнем углу) — и весь код автоматически уходит в репозиторий. Двусторонняя синхронизация: изменения в Lovable → GitHub, изменения в GitHub → Lovable.
На этом этапе Supabase вам нужен только как инструмент разработки, не для хранения реальных данных пользователей. Работаете с тестовыми данными, всё нормально.
Шаг 2: Разворачиваем на российском хостинге с локальной БД
Клонируете репозиторий с GitHub, разворачиваете на хостинге в РФ — Timeweb Cloud, Selectel, FirstVDS или любом другом с сертификацией по 152-ФЗ. Там поднимаете свой PostgreSQL.
Supabase, к слову, полностью open-source и официально поддерживает self-hosting через Docker/Docker Compose. Это значит, что вы можете развернуть не просто голый PostgreSQL, а полноценный стек Supabase (с аутентификацией, storage API и realtime) — но уже на своём российском сервере. Схема поддерживается и документирована самим Supabase.
Шаг 3: Переключаем проект с облачного Supabase на локальную БД
Вот тут начинается самое интересное — и самая творческая часть этой истории.
──────────────────────────────────────────────────
Cursor + SSH: агент делает всё сам
Если вы не хотите вручную копаться в коде и менять все строчки подключения к базе данных, есть способ автоматизировать это полностью. И это, пожалуй, главная «фишка» всей схемы.
Cursor — это AI-редактор кода с режимом агента, который умеет не просто писать код, но и выполнять команды в терминале, работать с файлами и подключаться к удалённым серверам. Агентный режим Cursor может читать файлы, редактировать их, запускать тесты и итерировать до тех пор, пока задача не решена — без вашего участия.
Вот как это работает на практике:
1. Открываете проект в Cursor (просто клонируете репозиторий с GitHub).
2. Даёте агенту задачу: «Найди все упоминания Supabase в коде — строки подключения, URL, ключи API, импорты клиента. Замени их на подключение к PostgreSQL на моём сервере с такими-то параметрами».
3. Даёте агенту SSH-доступ к серверу. Cursor поддерживает работу через Remote SSH — вы открываете воркспейс прямо на сервере. Агент может не только редактировать код локально, но и выполнять команды на удалённой машине: накатить миграции, перезапустить сервис, проверить, что база поднялась.
4. Агент проходит по всему коду, находит каждый supabase.from(...), каждый createClient(url, key), каждую переменную окружения VITE_SUPABASE_URL — и переписывает их под новую конфигурацию. Затем выполняет SQL-миграции на вашем сервере, проверяет результат.
По сути, вы описываете задачу словами, даёте доступ — и через некоторое время получаете работающий проект, уже не зависящий от зарубежных облаков.
──────────────────────────────────────────────────
Что важно знать про миграцию
Несколько практических моментов, которые стоит учитывать:
Схема базы данных переносится чисто. Lovable хранит все изменения схемы в виде SQL-миграций в папке supabase/migrations/. Это стандартный формат, который применяется к любому PostgreSQL. Агент легко выполнит их на вашем сервере.
С данными сложнее. Если вы уже накопили данные в Lovable Cloud, их придётся экспортировать вручную (CSV из Table Editor) и импортировать на новый сервер. Lovable не предоставляет автоматического пути миграции данных — это честно задокументировано. Но если вы переносите проект до запуска в продакшн, этой проблемы нет вообще.
После переноса — продолжаете в Cursor или локально. Lovable останется подключённым к старому Supabase-инстансу, поэтому после миграции дальнейшую разработку ведёте уже в Cursor или любом другом редакторе, синхронизируя через GitHub.
Edge Functions потребуют отдельного внимания. Если в проекте есть серверные функции (Supabase Edge Functions), их нужно будет либо развернуть как часть self-hosted Supabase, либо переписать в формат, который поддерживает ваш хостинг (например, serverless-функции или обычный Node.js-сервер).
──────────────────────────────────────────────────
Итого: рабочий процесс
Lovable (разработка + быстрый прототип)
↓ GitHub sync
GitHub (код в репозитории)
↓ клонирование + задача агенту
Cursor Agent (находит все Supabase, переписывает на локальный PostgreSQL)
↓ SSH-доступ
Российский хостинг (PostgreSQL, соответствие 152-ФЗ)
──────────────────────────────────────────────────
Почему это работает лучше альтернатив
Можно возразить: а зачем вообще Lovable, если потом всё равно переделывать? Ответ в том, что переделывать приходится немного, а скорость создания прototипа несопоставима.
За несколько часов в Lovable вы получаете полноценный фронтенд с аутентификацией, формами, дашбордами, правильной структурой базы данных — то, на что у команды разработчиков ушли бы недели. Потом Cursor за один сеанс переключает подключение к БД. Это не «потеря времени на переделку» — это смена одной строчки конфига, только делает её агент, а не вы.
При этом вы сохраняете полный контроль над кодом (он ваш с первого промпта), данными и инфраструктурой — что важно не только с точки зрения закона, но и с точки зрения здравого смысла.
──────────────────────────────────────────────────
Юридическая сторона: что ещё нужно сделать
Переезд на российский сервер — необходимое, но не достаточное условие. Для полного соответствия 152-ФЗ также нужно:
• Зарегистрироваться в РКН как оператор персональных данных (уведомление подаётся онлайн).
• Добавить на сайт политику обработки персональных данных и форму согласия пользователя.
• Выбрать хостинг с сертификацией по требованиям ФСТЭК (Timeweb Cloud, Selectel, FirstVDS — все имеют соответствующие документы).
• Защитить сервер антивирусом, настроить бэкапы, ограничить доступ.
Это не сложно, но это обязательная часть пакета. Сервер в России без документов — это как машина без страховки: ездить можно, но нарваться неприятно.
──────────────────────────────────────────────────
Вместо заключения
Lovable — реально мощный инструмент, и было бы обидно от него отказываться из-за юридических нюансов. Хорошая новость в том, что не нужно. Схема «Lovable → GitHub → Cursor → российский хостинг» даёт вам лучшее из обоих миров: скорость и удобство AI-разработки плюс соответствие российскому законодательству.
Вся магия в том, что Lovable — это не закрытая платформа. Это инструмент, который генерирует ваш код. А где этот код работает — решаете вы.
──────────────────────────────────────────────────
Статья написана в марте 2026 года. Законодательство в сфере персональных данных продолжает меняться — уточняйте актуальные требования на сайте Роскомнадзора и в тексте ФЗ-152.
Подписывайтесь на мой Telegram канал: https://t.me/codeandchay
Строю свой стартап прямо в эфире.
Инструменты, ошибки, размышления без лишнего тех слэнга.