OpenAI встроила хостинг внутренних приложений прямо в Codex
OpenAI добавила в Codex функцию Sites: теперь агент для кода может не только написать приложение, но и подготовить его к публикации, сохранить версию, задеплоить и вернуть ссылку на размещённый сайт. В документации OpenAI описывает Sites как плагин для сайтов, веб-приложений и игр, размещённых на хостинге OpenAI, без отдельной настройки процесса деплоя.
Это важный сдвиг в роли Codex. Он всё меньше похож на помощника рядом с IDE и всё больше — на рабочую среду, где команда просит: «собери внутренний инструмент», а агент проходит путь от кода до рабочей ссылки. Но пока это не «новый Lovable для всех»: Sites находится в preview и доступен для ChatGPT Business и Enterprise.
Что именно умеет Sites
Базовый сценарий выглядит просто. Пользователь в треде описывает сайт или приложение, при необходимости явно вызывает @Sites, просит Codex проверить сборку, затем выбирает: сохранить версию для ревью или деплоить уже одобренную версию. После успешного деплоя Codex возвращает рабочий URL.
OpenAI отдельно подчёркивает: каждая ссылка деплоя в Sites — это рабочая публикация. Если команда хочет сначала посмотреть результат, надо просить Codex сохранить версию без публикации. Это маленькая деталь, но для внутренних приложений она критична: агент может быстро довести задачу до ссылки, а значит процесс ревью должен быть не менее явным, чем скорость сборки.
В документации примеры крутятся вокруг практичных внутренних задач: дашборд для операционной команды, список заявок с владельцами и статусами, сохранение данных между визитами, игровые таблицы результатов, загрузка аватаров и файлов. То есть фокус не на лендинге ради лендинга, а на превращении командной рутины в небольшое живое приложение.
Данные, файлы и доступ
Sites поддерживает постоянные данные и загрузки. Для структурированных записей OpenAI указывает D1 — реляционную базу данных, для файлов — R2 object storage. В конфигурации проекта связь с hosting хранится в .openai/hosting.json, где могут быть project_id и имена storage bindings.
Здесь важно быть аккуратным с Cloudflare. Источник прямо говорит, что Sites размещает проекты, которые собираются в ES-модули, совместимые с Cloudflare Workers, а также называет D1 и R2. Но из этой страницы нельзя уверенно утверждать больше: например, что весь продукт полностью работает как обычный Cloudflare-проект или что пользователь управляет инфраструктурой так же, как в аккаунте Cloudflare. Для читателя практический вывод проще: приложение должно собираться в совместимый формат, а агент сам ведёт его через слой управляемого хостинга OpenAI.
Доступ по умолчанию стоит держать узким: владелец и администраторы. Потом Sites может открыть приложение для всего workspace или для выбранного набора пользователей и групп. Для внутренних инструментов это правильная логика: сначала проверить контент, данные и аудиторию, затем расширять доступ.
Почему это важно для команд
Sites закрывает неприятный разрыв между «агент написал полезный прототип» и «теперь кто-то должен поднять хостинг, базу, секреты и права». Для многих внутренних приложений именно этот разрыв убивает проект: код уже есть, но путь до usable-ссылки слишком скучный и разрозненный.
Теперь OpenAI пробует встроить этот путь в сам тред Codex. Команда может просить не только код, но и результат, которым можно пользоваться: онбординг-дашборд, базу знаний, простую форму, отчётный экран, лёгкое приложение для рабочего процесса. Это делает Codex конкурентом не только инструментов для программирования, но и no-code/low-code среды для внутренних задач.
Ограничения тоже очевидны. Перед деплоем OpenAI советует проверить изменения в коде, миграции базы, сборку, выбранную сохранённую версию, аудиторию и секреты окружения. Иными словами, Sites ускоряет доставку, но не отменяет ответственность за данные и доступ. Самая здоровая роль этой функции сейчас — быстрые внутренние приложения под контролем workspace, а не публичные продукты без нормального ревью.
