Cloudflare перестроила Containers для агентов: старт в 6 раз быстрее

Cloudflare переработала инфраструктуру Containers под нагрузку, которую создают ИИ-агенты: песочницы появляются по требованию, под каждую задачу, и должны быть готовы мгновенно. В независимом бенчмарке ComputeSDK медианное время старта упало с 4,049 секунды до 648 миллисекунд (в 6,2 раза), а в собственном пробном тесте компании один аккаунт поднял 100 000 контейнеров за 5,387 секунды в шести локациях. Вместе с этим вышли выбор образа и ресурсов прямо из кода и снапшоты файловой системы в публичной бете.

Образ и железо выбирает код, а не деплой

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

Старая модель требовала на каждую комбинацию образа и типа инстанса отдельное приложение, своё пространство имён Durable Objects и маршрутизацию в Worker. Маленькая Node.js-песочница и большая Python-среда для сборок означали два деплоя. Новая политика планирования `durable_object` превращает это в условие `if`: в конфигурации wrangler объявляются доступные образы (например, node и python), а Durable Object при старте передаёт в `ctx.container.start()` образ, тип инстанса (скажем, standard-1 или standard-2) и флаг доступа в интернет. Новая среда теперь появляется правкой кода, а не новым развёртыванием.

То же касается раскатки обновлений. Grace-периоды, процентные сплиты и вызовы API конфигурации уходят: контейнер работает на образе, с которым стартовал, пока код его не остановит, а следующий запуск берёт тот образ, который выберет код. Из этого получаются канареечный выкат на 5% новых песочниц по хешу ID Durable Object, закрепление активных проектов за текущим образом, миграция на контрольной точке и откат простой сменой образа для будущих запусков.

Почему первая команда выполняется быстрее

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

После попадания на хост тоже убрали лишнее: вместо загрузки виртуальной машины с нуля среда выполнения восстанавливает заранее подготовленную неназначенную ВМ, переиспользует настройку сети и файловой системы, группирует повторяющиеся операции и не ждёт сервисов, которые первой команде не нужны. Результаты бенчмарка Burst TTI (100 одновременных песочниц, замер на стороне клиента):

• медиана: 4,049 с → 648 мс (в 6,2 раза быстрее); • 95-й перцентиль: 5,839 с → 910 мс (в 6,4 раза); • 99-й перцентиль: 6,717 с → 1129 мс (в 5,9 раза).

Отдельно Cloudflare выпустила образ `cloudflare/debian-trixie` с Debian Trixie Slim и Node.js 24.20.0 LTS. Агент может стартовать Linux-песочницу без Dockerfile, сборки и пуша образа, а затем через `exec()` склонировать репозиторий и поставить пакеты. Поскольку образ контролирует сама Cloudflare, его заранее распространяют по подходящим хостам, и при запуске ничего не скачивается и не распаковывается.

Снапшоты: сохранить рабочее пространство и вернуться

Даже быстрый старт не отменяет настройку: клонирование, установка зависимостей и конфигурация тулчейна часто занимают больше времени, чем запуск самого контейнера. Для этого в публичную бету вышли нативные снапшоты файловой системы. Метод `snapshotContainer()` сохраняет рабочее пространство, а `start()` с параметром `containerSnapshot` восстанавливает его.

Снапшоты неизменяемы и переиспользуемы, поэтому работают в двух сценариях. Первый: одно рабочее пространство продолжается между сессиями. Кодинговый агент сохраняет репозиторий, зависимости, кэши сборки и правки, когда пользователь уходит, и поднимает их на следующий день. Второй: общая контрольная точка для множества песочниц. Это удобно для оценки агентов, когда одну задачу прогоняют с разными системными промптами, навыками, моделями или версиями агента, а всё остальное должно оставаться неизменным. Один снапшот запускает много изолированных сред с одинаковой базой и убирает дрейф окружения из результатов. Цепочка тоже работает: агент стартует с debian-trixie, настраивает среду через `exec()` и сохраняет результат как снапшот.

Кому это пригодится

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

На Containers уже строят свои продукты Base44 (изолированная среда разработки для каждого приложения с живым превью) и Kilo Code (отдельное окружение под каждую облачную сессию агента). Есть интеграции с Cursor Cloud Agents, Devin Outposts, OpenAI Agents API и Claude Managed Agents. Модель переносится и в Sandbox SDK 1.0, а в нативный API `ctx.container` добавляется больше возможностей, чтобы Durable Object управлял контейнером без класса-обёртки.

Для команд, которые делают агентные продукты, практический вывод такой: если вы держите отдельные приложения под каждый стек, их можно свернуть в один класс Durable Object с выбором образа в рантайме. Для эвалов и RL стоит собирать эталонный снапшот и запускать от него параллельные прогоны. Для долгоживущих сессий подойдёт пара «снапшот при паузе, восстановление при возврате». Цифры по 100 000 контейнеров предварительные, поэтому реальную нагрузку лучше проверять на своём профиле.