Лимит Cloudflare Workers вырос до 64 MiB: апгрейд ради бандла больше не нужен

Cloudflare убрала размер бандла из списка причин покупать Workers Paid. 4 сентября 2026 года прежние ограничения — 3 MB для Free и 10 MB для Paid после сжатия — сменил единый лимит Cloudflare Workers: 64 MiB без сжатия на обоих тарифах. Поэтому бюджет развёртывания теперь нужно сверять со строкой Total Upload в Wrangler, а не с gzip.

Как изменился лимит Cloudflare Workers

Бандл Worker — это код и вспомогательные модули, которые Cloudflare получает при развёртывании. Wrangler, инструмент командной строки Cloudflare, по умолчанию собирает этот пакет с помощью esbuild, добавляет импортируемые кодом npm-пакеты и показывает итоговый размер.

До 4 сентября Cloudflare сжимала бандл и отклоняла его, если результат превышал 3 MB на Workers Free или 10 MB на Workers Paid. Эта проверка сжатого размера больше не действует.

Теперь платформа проверяет только одно: размер бандла без сжатия не должен превышать 64 MiB. Ограничение одинаково для Free и Paid.

Последний столбец описывает всю механику. Total Upload — это размер без сжатия. Wrangler по-прежнему выводит gzip для справки, но Cloudflare больше не использует его как условие допуска к развёртыванию.

Не стоит сводить изменение к удобному множителю. Старые значения измеряли сжатые байты в MB, а новое — несжатые байты в MiB. Сколько дополнительного кода поместится, зависит от того, насколько хорошо сжимаются конкретные JavaScript-файлы, зависимости и бинарные модули проекта.

Что изменилось в решении о тарифе за $5

Прямое коммерческое следствие узкое, но важное. Минимальная плата за Workers Paid составляет $5 USD с аккаунта в месяц. Если команда собиралась перейти на платный тариф только потому, что бандл превысил прежний лимит Free в 3 MB, эта причина исчезла — при условии, что Total Upload укладывается в 64 MiB.

Это не делает два тарифа одинаковыми. Workers Free по-прежнему включает 100,000 запросов в день, 10 миллисекунд процессорного времени на вызов и 50 подзапросов на вызов. Workers Paid включает 10 миллионов запросов и 30 миллионов процессорных миллисекунд в месяц, допускает 10,000 подзапросов на вызов и позволяет использовать до 5 минут процессорного времени на запрос при значении по умолчанию 30 секунд.

Зато бюджетное решение стало проще. Платить следует за трафик, процессорное время, подзапросы и возможности, доступные только на Paid, — но не просто за то, что хорошо сжимаемый бандл оказался больше отменённого порога Free.

Команды, уже использующие Paid для реальной продакшен-нагрузки, не увидят прямого снижения счёта. Не изменится рабочий процесс и у тех, чьи бандлы уверенно помещались в прежний лимит. Основную выгоду получают проекты, которым из-за размера развёртывания приходилось урезать или разделять бандл либо переходить на другой тариф.

Остальные расчёты по аккаунтам и среде выполнения разобраны в подробном обзоре Cloudflare: там показано, какое место Workers занимает среди других тарифных и ресурсных платежей Cloudflare. Изменение этого сентября заменяет приведённые в обзоре прежние лимиты бандла.

Четыре сценария, в которых сборка стала проще

Основатель SaaS может выбирать тариф отдельно от фреймворка

Представим, что независимый разработчик выпускает full-stack-приложение на Workers Free. Адаптер фреймворка, код серверного рендеринга и продакшен-зависимости способны дать бандл, который после сжатия превышает старый порог Free, даже если трафик приложения всё ещё укладывается в этот тариф.

Теперь такую сборку можно оценивать по лимиту Total Upload в 64 MiB. Если она помещается, один лишь размер бандла не вынуждает платить минимум $5 за Paid. Речь не о бесплатном продакшене при любом масштабе, а о возможности проверить спрос до того, как появится необходимость платить за использование среды выполнения.

Агентство может удалить устаревшую проверку из CI

Ответственный за сборку в агентстве мог скопировать прежний порог gzip во все клиентские репозитории. Если оставить такую проверку, сборки продолжат падать из-за правила, которое Cloudflare уже не применяет.

Замените её проверкой несжатого Total Upload и задайте внутренний порог ниже 64 MiB, сохранив запас. Тогда клиентские проекты будут останавливаться из-за актуального ограничения платформы, а не исторического.

Команда на Rust или WebAssembly получает больше места, но не новую среду выполнения

WebAssembly, или сокращённо Wasm, позволяет Worker выполнять бинарный код, скомпилированный из таких языков, как Rust, Go или C. Cloudflare отмечает, что Workers на Wasm обычно больше сопоставимых Workers на JavaScript: бинарный файл часто содержит дополнительные зависимости среды выполнения.

Увеличенный допустимый размер развёртывания оставляет такой команде больше места для модуля Wasm и окружающего его кода. Wrangler напрямую поддерживает загрузку .wasm и .wasm?module. Оптимизация размера по-прежнему важна, и для уменьшения бинарного файла Cloudflare рекомендует wasm-opt.

Платформенная команда может отказаться от обходной архитектуры

Инженеры платформенной команды на Workers Paid могли разделить цельный сервис, удалить полезную зависимость или построить собственный механизм внешних модулей лишь ради того, чтобы остаться ниже порога 10 MB после сжатия. Теперь такое решение стоит пересмотреть.

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

Как проверить реальный размер бандла перед развёртыванием

Не нужно гадать по размеру node_modules, каталога с исходным кодом или архива, который создала отдельная сборка фреймворка. Запустите тестовое развёртывание Wrangler из проекта Worker, чтобы получить именно тот артефакт, который отправился бы в Cloudflare.

1. 1

   Соберите проект без развёртывания

   Выполните команду тестового развёртывания из документации Cloudflare:

   wrangler deploy --outdir bundled/ --dry-run

   Wrangler соберёт Worker и сохранит результат локально, не развёртывая его.

2. 2

   Проверьте Total Upload

   Найдите Total Upload в выводе команды. Это размер бандла без сжатия, который Cloudflare теперь сопоставляет с лимитом 64 MiB. Значение gzip можно оставить для диагностики, но оно больше не определяет, пройдёт ли развёртывание.

3. 3

   Измените лимит в CI

   Замените все правила для сжатого размера 3 MB на Free или 10 MB на Paid правилом по Total Upload. Установите внутренний лимит команды ниже максимума платформы, чтобы одно обновление зависимости не израсходовало весь запас.

4. 4

   Проверьте запуск при реальном развёртывании

   При следующем обычном развёртывании или загрузке версии запишите значение startup_time_ms из вывода Wrangler. Бандл может соответствовать лимиту загрузки, но не пройти отдельную проверку времени запуска Cloudflare.

Типичная ошибка — по привычке смотреть на меньшее значение gzip, которое прежде определяло судьбу развёртывания. Теперь это не так: строкой бюджета стал Total Upload.

Какие ограничения не выросли вместе с лимитом до 64 MiB

Большие бандлы могут дольше разбираться и инициализироваться. Код с затратными операциями в глобальной области, то есть вне обработчика запросов, по-прежнему способен провалить проверку с сообщением Script startup exceeded CPU time limit и кодом ошибки 10021. Размер менее 64 MiB лишь открывает бандлу путь через проверку объёма, но не гарантирует нормальный запуск.

Особенно это важно для тяжёлых фреймворков и Wasm. Раньше загрузку часто первой останавливал старый лимит. Теперь больше кода доходит до следующего ограничения, где проявляются требования к памяти и поведению при инициализации.

Если Worker всё ещё слишком велик, актуальная документация предлагает три практических выхода:

• Удалить пакеты и зависимости, которые не использует развёрнутый путь выполнения.
• Хранить конфигурацию, статические ресурсы и бинарные данные в Workers Static Assets, KV, R2 или D1, а не внутри бандла Worker.
• Разделить функциональность между несколькими Workers с помощью Service Bindings.

Вызовы через Service Binding не создают дополнительную плату за второй запрос. Cloudflare тарифицирует первый вызов Worker и суммарное процессорное время всех задействованных Workers. Поэтому разделение подходит как способ уменьшить размер, но дополнительную границу между сервисами всё равно следует вводить осознанно.

Что сделать в понедельник

Действуйте уже на этой неделе, если Worker недавно не прошёл старую проверку размера, команда урезала зависимости фреймворка ради прежнего лимита или размер бандла был единственной причиной перейти на Paid. Запустите тестовое развёртывание, запишите Total Upload и пересмотрите это решение.

Можно подождать, если Worker и раньше был намного меньше старого лимита, а в конвейере развёртывания нет жёстко заданной проверки gzip. В среде выполнения приложения ничего не изменилось.

Оставайтесь на Paid, если этот тариф оправдан количеством запросов, процессорным временем, подзапросами или другой платной возможностью. Более высокий лимит загрузки на Free — не повод переносить продакшен-нагрузку на тариф с неподходящими эксплуатационными квотами.

Главное действие на понедельник простое: замените в проверке сборки gzip на Total Upload, а тариф выбирайте по объёму использования, а не по размеру бандла.

Следующее практически важное изменение платформы придёт в рассылке.