AIREITERМногие приложения так и остаются на localhost — именно эту проблему Cursor пытается решить релизом Build Live Apps от 5 ноября. По changelog, документации и первым вопросам пользователей вывод простой: это сильный вариант для внутренних инструментов и прототипов за Cursor SSO, но пока не замена сложным production-бэкендам и системам с жёсткими требованиями к соответствию нормам.
Что умеет Build Live Apps
Build Live Apps — это сценарий для cloud agent: вы описываете задачу обычным языком, а Cursor собирает и разворачивает веб-приложение. Функцию Cursor анонсировал в changelog 5 ноября 2026 года. Процесс в документации выглядит так: дать агенту промпт, посмотреть результат в панели предпросмотра, выбрать URL, пройти проверки безопасности и опубликовать приложение по рабочей ссылке.
Запрос нужно формулировать явно: согласно документации Cursor, агенту следует прямо сказать build an app. Приложение можно создать с нуля через Cursor Origin — в этом случае появится новый репозиторий, — либо развернуть из существующего репозитория GitHub. Создавать приложения способны только облачные агенты.
Если приложению требуется хранилище, Cursor предоставляет базу PostgreSQL. Размещение происходит в отдельном изолированном hosting-аккаунте для каждого пользователя или команды. Для командных приложений используется Cursor SSO: получатель ссылки должен войти в Cursor, прежде чем открыть приложение. Пользователи индивидуальных тарифов также могут публиковать публичные приложения без обязательного входа.
Сразу стоит учитывать несколько ограничений. Поддержка GitLab заявлена в планах, но пока недоступна. С custom domains ясности нет: Cursor говорит, что автор публикации выбирает уникальный домен, а документация позволяет изменить URL позже, однако процесса подключения собственного домена ни на одной из страниц не описано.
Также Cursor не приводит список поддерживаемых фреймворков и рантаймов, регионов, версию Postgres, сведения о бэкапах, масштабировании, лимитах трафика или SLA. Юридически хостинг отделён от сервисов Cursor и предоставляется "as is" and "as available"; Cursor оставляет за собой право отозвать или приостановить работу поддомена либо приложения.
Публикация только после четырёх обязательных проверок и AI-ревью
Приложение не становится доступным само по себе: пользователь должен явно подтвердить публикацию. Одной подготовки недостаточно, чтобы открыть к нему доступ. При каждой публикации Cursor запускает четыре обязательные проверки. Они работают даже в том случае, если команда отключила отдельное AI-ревью:
- Не дают опубликовать приложение, если в его файлах найден API-ключ или access token.
- Блокируют файлы с учётными данными, включая приватные ключи и ключи service account.
- Исключают файлы
.envиз публикуемой сборки. - Удаляют source maps, чтобы посетители не могли восстановить исходный код через браузер.
При ошибке Cursor покажет проблему, после чего можно попросить агента исправить её и повторить попытку.
Дополнительное AI-ревью безопасности анализирует файлы приложения и способно заблокировать серьёзные проблемы до публикации. Администраторы команды могут добавлять в его промпт инструкции, специфичные для организации. Такие инструкции позволяют вводить дополнительные правила, но не отменять и не ослаблять встроенные проверки Cursor. Администраторы вправе обходить некоторые блокировки публикации, но не могут снять блокировку, связанную с вредоносным кодом, захардкоженными секретами или раскрытыми учётными данными. Изменения этих настроек фиксируются в audit log команды.
Однако важнее понимать не то, что этот барьер находит, а то, чего он не доказывает:
«Главная оговорка: успешное прохождение проверок безопасности не означает, что у нужных людей действительно есть нужный доступ к приложению». — @0node0, реальный пользователь
Cursor прямо приводит в качестве примеров секреты и раскрытые учётные данные. Но компания не заявляет, что каждое приложение получает тестирование авторизации, проверку построчных прав, защиту от SQL-инъекций, сканирование зависимостей или ревью бизнес-логики. В анализе TechRepublic от 6 ноября отмечено то же самое: проверяйте приложение несколькими аккаунтами с разными уровнями доступа, поскольку защита от ситуации, когда один авторизованный пользователь читает записи другого, не подтверждена.
Цена, замена Vercel и работа с секретами: главные вопросы
Нужно ли отдельно платить за хостинг? Cursor не публиковал отдельную цену на хостинг или базу данных. У Build Live Apps нет самостоятельной подписки: функция входит в платные планы с доступом к cloud agents. Конкретные цены доступны в таблице тарифов TechRepublic, а не на страницах Cursor о функции:
| Тариф | Указанная цена | Доступ к Build Live Apps |
|---|---|---|
| Plus | $8/месяц | Нет, cloud agents отсутствуют |
| Premium | $30/месяц | Да, минимальный подходящий индивидуальный тариф |
| Super | $100/месяц | Да, увеличенный лимит использования |
| Ultra | $200/месяц | Да, максимальный из указанных лимитов |
| Team | От $30/пользователь/месяц | Да, добавляет административные средства управления |
| Enterprise | Индивидуально | Да, зависит от политики |
Cursor использует общий недельный лимит AI-использования (разбор тарифов TechRepublic), но на этих страницах Cursor не указывает лимиты токенов, запросов или вычислительных ресурсов для отдельных тарифов. Сторонние модели могут тарифицироваться отдельно (TechRepublic). Лимиты базы данных, хранилища, трафика и параллельной нагрузки не раскрыты. Поэтому $30 — это порог входа, а не подтверждённая полная стоимость эксплуатации: перед запуском клиентской нагрузки на встроенном хостинге уточните квоты.
Заменяет ли Build Live Apps Vercel? Пока нет — если речь о сложном production-бэкенде или системе с требованиями к compliance. Встроенный путь хорошо подходит для связки Postgres, SSO и ссылки для доступа. Традиционный сценарий через GitHub и Vercel, Netlify, Railway, Render или VPS по-прежнему нужен для нестандартных архитектур и регулируемых данных; подробное разделение по сценариям приведено в таблице ниже. В обсуждениях хостинга на Reddit постоянно возвращаются к одному критерию: выбор хоста определяется тем, насколько нагрузка stateful и насколько долгие процессы ей нужны.
«Большинство демонстраций Cursor в моей ленте сосредоточены на UI… и в основном не развернуты для реальных платящих пользователей». — @mayowaoshin, реальный пользователь
Где хранятся секреты и видит ли их агент? Документация Cursor утверждает, что coding agent никогда не видит значения секретов. Если приложению нужен доступ к хранилищу данных или внешнему API, Cursor попросит пользователя указать секреты. Секреты команды обычно создаёт администратор в Apps dashboard либо добавляет их там же позднее.
Администраторы команды видят все командные приложения и все секреты команды. Это удобно для управления, но также задаёт границу доверия, которую стоит учитывать до вставки production-ключей. Автоматизированные клиенты — скрипты, CI-задачи и Grok Bot — получают доступ к защищённым приложениям через ключ в заголовке x-cursor-app-token, а не через cookies или query parameters.
Когда выбирать Live Apps, а когда привычный деплой
| Сценарий | Встроенный Live Apps | Традиционный деплой (Vercel / Railway / VPS) |
|---|---|---|
| Внутренний дашборд, трекер регистраций, портал онбординга за SSO | Оптимальный вариант: самый быстрый путь к ссылке для доступа | Избыточен, пока приложение не перерастёт квоты |
| Публичный маркетинговый микросайт с формой email | Работает на индивидуальных тарифах с публичным доступом | Выбирайте традиционный путь, если нужны собственный домен, аналитика или edge caching |
| Приложение с Postgres, Cursor SSO и возможностью снять публикацию администратором | Нативный вариант: изолированный hosting-аккаунт, явная публикация и audit log | Придётся вручную собирать аутентификацию, БД и проверки |
| Кастомная аутентификация, SAML/OIDC помимо Cursor, насыщенная RLS-схема Supabase | Рискованный выбор: модель прав не подтверждена, а администраторы видят секреты | Используйте традиционный путь и контролируйте слой аутентификации и данных |
| Долгие бэкенд-процессы, workers, cron, WebSockets, хранилище не на Postgres | Не документировано: нет спецификации рантайма и масштабирования | Используйте традиционный путь, если требуется хотя бы один из этих пунктов |
| Исходники в GitLab, workflow с локальным агентом, регулируемая резидентность данных/SLA | Заблокировано: только GitHub или Origin, cloud agents и хостинг as-is | Используйте традиционный путь |
| Production-платежи, webhooks, PII | Только пилот: пройдите проверки, затем отдельно подтвердите корректность авторизации | Используйте традиционный путь со staging, branch protection и ограниченными ключами |
У привычного пути остаётся собственная цена настройки: конфигурация MCP, данные для хостинга, переменные окружения и усиление RLS. Это хорошо видно по четырёхнедельному пути одного разработчика от лендинга через Vercel к аутентификации Supabase.
Чек-лист перед первой публикацией
Проверки Cursor ловят утёкшие секреты и файлы с учётными данными. Но права доступа, настройка окружения, асинхронные побочные эффекты и непрочитанный код остаются вашей зоной риска. Пройдитесь по этому списку перед первой отправкой ссылки — даже если инструмент предназначен только для команды.
- Соберите с чистого состояния и прочитайте diff. Попросите агента выполнить настоящую production-сборку, а не запустить dev server. Откройте все изменённые файлы, затрагивающие платежи, аутентификацию и запись данных. Если проект уже разросся настолько, что diff невозможно нормально проверить, восстановите checkpoint и разбейте задачу на части вместо новых промптов поверх накопившегося хаоса.
- Проверьте права двумя аккаунтами. Войдите как администратор и как пользователь с ограниченными правами. Создайте запись от имени пользователя A, затем попробуйте прочитать, изменить и удалить её от имени пользователя B. Пройденный security report не доказывает, что владение строками настроено правильно.
- Проведите сквозной аудит секретов. Убедитесь, что ключи не попали во frontend-код, файл
.envне ушёл в публикацию, а каждый внешний credential имеет минимально необходимые права. Уберите прямые URL production-базы данных из окружения, доступного агенту. В одном сообщении на r/cursor описан случай, когда Cursor развернул изменения сразу в production Supabase, минуя GitHub. - Протестируйте асинхронные сценарии. Отправьте реальный webhook, повторите его и оборвите выполнение в середине. Проверьте поведение connection pool при параллельной нагрузке. Именно тихие сбои webhook и исчерпанные пулы пользователи нередко обнаруживают уже после запуска.
- Определите порядок обновления и отката. Уточните, кто может публиковать приложение, обходить блокировку публикации и снимать его с публикации, а также куда поступает audit log. Зафиксируйте, как откатывается неудачная публикация и как выполняется миграция схемы: документация описывает публикацию, но не историю версий и не rollback.
«Как только приложение покидает localhost, секреты отправляются вместе с ним». — @1PasswordDev, реальный пользователь о изоляции секретов между приложениями
Если на любой из этих пунктов нет ответа — например, отсутствуют staging-проект, второй тестовый аккаунт или rollback, — оставьте приложение доступным только команде либо используйте традиционный стек, пока ответ не появится.
FAQ
Для Build Live Apps нужен платный тариф Cursor?
Да. Build Live Apps работает только на платных тарифах с включёнными cloud agents. Plus за $8/месяц не подходит. Premium за $30/месяц — минимальный подходящий индивидуальный тариф.
Cursor может собрать приложение из существующего репозитория?
Да, из существующего репозитория GitHub или с нуля через Cursor Origin. GitLab заявлен в планах, но пока недоступен, а локальные агенты создавать приложения не могут.
Может ли приложение команды быть публичным?
На тарифах Team и Enterprise публичный доступ по умолчанию отключён. Администратор может включить его в Apps dashboard. На индивидуальных тарифах публичные приложения можно публиковать напрямую.
Поддерживает ли Cursor custom domains?
Cursor сообщает, что автор публикации выбирает уникальный домен и может изменить его позднее, но ни changelog, ни документация не подтверждают возможность привязки собственного домена. Пока Cursor не опишет это отдельно, исходите из использования URL под управлением Cursor.
Как скриптам или ботам получить доступ к приватному приложению?
Создайте Cursor API key и передавайте его в каждом запросе через заголовок x-cursor-app-token. Персональные ключи открывают всё, к чему есть доступ у владельца. Командные ключи работают только с явно разрешёнными приложениями команды.
Что происходит после снятия приложения с публикации?
Администраторы могут снять с публикации любое командное приложение, а отключение публичных приложений возвращает уже опубликованные приложения к видимости только для команды. Cursor не описывает хранение данных, бэкапы или экспорт данных после снятия с публикации.
Build Live Apps убирает настройку хостинга между работающим прототипом и полезной ссылкой. Но он не отменяет ревью, тестирование прав доступа и работу с ответственностью за приложение — именно они определяют, смогут ли другие пользоваться результатом безопасно.
Читайте также: Best LLM for Coding Agents 2026 · Cursor Projects Beta Review · Cursor Router Explained