Сервис Cloudflare Containers научился запускать изолированные Linux-песочницы для программных агентов всего за сотни миллисекунд вместо прежних четырех секунд. Теперь разработчикам не нужно гадать с серверами заранее: код на лету выбирает образ системы, выделяет память и поднимает файлы из готового снимка диска.
Каждый, кто поручал умному ассистенту написать скрипт или проверить чужой код, знает чувство паузы. Вы отправляете задачу, модель соглашается взяться за дело, а дальше на экране висит тишина. Программа не думает над решением — она ждет, пока сервер выделит виртуальную среду и откроет терминал.
Зачем агентам потребовался быстрый запуск
Четыре секунды ожидания кажутся мелочью для разовой задачи. Но современные сценарии устроены иначе. Один ассистент собирает проект, второй прогоняет тесты в соседней среде, а третий проверяет безопасность библиотек. Когда на каждый вызов уходит по нескольку секунд холодного старта, работа рассыпается.
Человек отвлекается и теряет контекст. Чтобы ассистент воспринимался напарником, отклик должен укладываться в доли секунды. Раньше приходилось держать серверы постоянно теплыми и платить за простой либо мириться с постоянными паузами.
Когда программный помощник решает рабочую задачу, человек не готов смотреть в пустой экран несколько секунд. Быстрый запуск возвращает привычный темп живого диалога.
Как контейнеры разогнались в шесть раз
Тридцатого сентября 2026 года Cloudflare открыла новую политику планирования под названием durable_object в публичную бету. Раньше параметры контейнера жестко задавались при публикации проекта. Теперь запуск стал динамическим: решение о мощности и образе принимает код прямо в момент вызова.
Замеры платформы ComputeSDK показали резкий скачок. В стресс-тесте Burst TTI при запуске сотни песочниц одновременно медианное время готовности среды упало с 4,049 секунды до 648 миллисекунд — в 6,2 раза быстрее. Девяносто пятый перцентиль задержки снизился с 5,839 секунды до 910 миллисекунд, а девяносто девятый — с 6,717 секунды до 1129 миллисекунд. На внутренних тестах Cloudflare развернула 100 000 контейнеров за 5,387 секунды в шести регионах.
Если вы хотите глубже разобраться в работе автономных систем и автоматизации рабочих процессов, заглядывайте в наш Telegram-канал Ковчег, читайте материалы в MAX и приходите на практическое обучение по Make и нейросетям.
Снимки диска спасают от долгой сборки проекта
Быстрый запуск голой системы решает только половину задачи. Основное время уходит позже, когда агент клонирует репозиторий, скачивает зависимости и компилирует код. Если сессия прерывается, следующему ассистенту приходится повторять цепочку с нуля.
Вместе с новой политикой планирования вышли снимки файловой системы. Агент готовит окружение один раз, сохраняет диск и получает идентификатор. Следующая песочница стартует сразу из готового слепка, пропуская сборку. Снимок вмещает до 20 гигабайт и хранится тридцать дней. Каждый успешный запуск автоматически продлевает срок еще на месяц. Если идентификатор не найден, система выдаст ошибку и не станет подменять данные пустым образом.
Снимок сохраняет только файлы на диске, но не запущенные процессы и не оперативную память. Если сохраненный идентификатор потерялся, запуск прервется с ошибкой.
Выбор мощности прямо в коде вызова
Разработчики получили возможность точно дозировать ресурсы под задачу. Нужный профиль передается аргументом прямо в вызов запуска. В линейке доступно пять готовых типов: от минимального lite с одной шестнадцатой ядра, 256 мегабайтами памяти и диском на 2 гигабайта до standard-4 с четырьмя ядрами и 12 гигабайтами памяти.
Для типовых задач появился официальный образ cloudflare/debian-trixie с облегченной системой Debian и платформой Node.js 24.20.0 LTS. Это избавляет от написания собственного файла сборки. При этом старый тип basic для новой политики планирования отключен.
Подводные камни новой архитектуры
Новая схема требует внимания к деталям. Метод запуска возвращает управление моментально, не дожидаясь готовности сетевого порта и приема команд. Если сценарий сразу пошлет запрос, он получит ошибку. В коде обязательно нужна проверка готовности окружения.
Базовые классы Container и Sandbox уходят в прошлое: их поддержка завершится 31 декабря 2026 года. После этой даты сервисы продолжат работать, но новых возможностей не получат. Кроме того, переключение политики планирования необратимо: откат публикации завершится сбоем. Наконец, снимок диска содержит абсолютно все файлы сессии, включая возможные секреты, поэтому делиться им между разными пользователями нельзя.
Архитектурное обновление нельзя откатить назад одной командой публикации. Новая логика требует отдельного тестирования, поэтому проекты стоит переводить постепенно.
