← Все продукты

Workers

Cloudflare Workers выполняет код клиентов в изолятах V8 в сети Cloudflare, используя привязки к хранилищу, базам данных, очередям и сервисам инференса. На этой странице описаны модель выполнения, модель привязок, ограничения платформы, влияющие на архитектуру решений, и опубликованные тарифы.

Управление документом

Дана
Технический писатель, Integrity Czech Republic s.r.o.

Обзор

В serverless-платформе Cloudflare Workers код развёртывается в сети, а не в конкретном регионе, и каждый вызов обрабатывается в том дата-центре, который принял запрос. Здесь нет инстансов, размер которых нужно подбирать, и нет рантайма, который нужно патчить, но платформа задаёт явные ограничения по CPU, памяти, количеству подзапросов и размеру скрипта, которые определяют, что на ней можно построить. Эти ограничения описаны в разделе «Лимиты и ограничения», и их стоит прочитать до начала проектирования, а не после.

Распространены два способа использования. В первом Worker ставят перед существующим origin-сервером, и он берёт на себя маршрутизацию, изменение заголовков, аутентификацию, персонализацию или кеширование, а само приложение остаётся на месте. Во втором приложение целиком строится на платформе, на её сервисах хранения и базах данных, без традиционного origin-сервера.

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

Архитектура

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

Но и запуск изолята не всегда обходится даром. Время холодного старта зависит от размера скрипта, объёма работы на уровне модуля и от того, нужно ли создавать экземпляр модуля WebAssembly. Крупные бандлы и тяжёлая инициализация дают измеримые задержки холодного старта.

Среда выполнения реализует веб-платформенные API: fetch, Request и Response, URL, Web Crypto, потоки, WebSocket и подмножество API Node.js, которое включается флагом совместимости nodejs_compat. Поведение среды выполнения фиксируется датой совместимости и флагами совместимости в конфигурации Worker. Так платформа вносит изменения в поведение, не ломая уже развёрнутый код.

Привязки соединяют Worker с ресурсами платформы. Привязка объявляется в конфигурации и добавляется в объект окружения во время выполнения, поэтому к пространству имён KV, бакету R2, базе данных D1, очереди, пространству имён Durable Object, модели AI или другому Worker код обращается как к возможности (capability), а не через строку подключения или встроенные учётные данные.

Развёртывание через Wrangler CLI публикует новую версию. Gradual Deployments направляют на новую версию заданную долю трафика, то есть во время такого развёртывания одновременно работают две версии. Поэтому в этом режиме развёртывание не атомарно, и код должен корректно работать, когда обе версии обращаются к одним и тем же данным.

В конвейере обработки запросов Cloudflare фазы безопасности выполняются до вызова Worker, поэтому запрос, заблокированный WAF или правилом защиты от DDoS, не доходит до кода Worker.

Возможности

Модель настройки

Worker определяется своим кодом и файлом конфигурации, wrangler.jsonc или wrangler.toml. Конфигурация задаёт следующее:

• Точка входа и настройки сборки. Точка входа модуля и любой этап сборки.
• Дата и флаги совместимости. Поведение среды выполнения, под которое был написан код. Смена даты совместимости (compatibility date) даёт заметные последствия, поэтому её делают осознанно и проверяют как изменение кода.
• Привязки. Пространства имён KV, бакеты R2, базы данных D1, пространства имён Durable Object, очереди, service bindings к другим Workers, AI bindings и обычные переменные окружения.
• Секреты. Хранятся вне файла конфигурации, задаются через Wrangler или панель управления и доступны в объекте окружения во время выполнения.
• Триггеры. Routes и Custom Domains для вызова по HTTP, cron-выражения для вызова по расписанию и объявления потребителей очередей.
• Окружения. Именованные варианты конфигурации для тестового и боевого окружений, каждый со своими привязками и секретами.
• Лимиты. Там, где это поддерживается, явный лимит CPU для Worker.

Главное архитектурное решение здесь: какое хранилище выбрать. Это зависит от нужной модели согласованности и характера доступа к данным. Используйте KV для частого чтения данных, которым достаточно согласованности в конечном счёте; D1 для реляционных запросов; R2 для объектов; Durable Objects, если нужна строгая согласованность или координация на уровне отдельной сущности; Queues, если обработку нужно вынести за пределы запроса.

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

Лимиты и ограничения

Значения ниже взяты из документации Cloudflare о лимитах платформы (https://developers.cloudflare.com/workers/platform/limits/), проверено 2026-08-31. Они могут измениться без предупреждения, поэтому перепроверьте их, прежде чем закладывать в решение.

Подзапросом (subrequest) считается любой запрос, который Worker отправляет через Fetch API или к сервису Cloudflare через привязку, поэтому вызовы fetch и вызовы через привязки расходуют общий бюджет одного вызова Worker.

Ограничения сервисов хранения (дата обращения 2026-08-28):

• Workers KV. Размер ключа 512 байт, размер значения 25 МиБ; документированный лимит: примерно одна запись в секунду в один и тот же ключ. KV согласован в конечном счёте: запись, сделанная в одной точке присутствия, может стать видна в другой не сразу.
• R2. Объекты больше лимита для одного запроса загружаются по частям (multipart upload), и для размера части есть свои ограничения. Исходящий трафик в интернет не тарифицируется, операции тарифицируются по классу.
• D1. На максимальный размер базы данных и на отдельные запросы действуют ограничения. База данных D1 не заменяет горизонтально масштабируемый реляционный кластер, поэтому перед планированием объёма данных уточните текущее максимальное значение.
• Durable Objects. Объект однопоточный, поэтому пропускная способность на объект ограничена, а шаблоны обращения к «горячим» ключам необходимо исключать ещё на этапе проектирования. Действуют лимиты хранения на объект, которые отличаются для бэкендов на основе «ключ-значение» и SQLite.

Дополнительные ограничения:

• Python Workers доступны в открытой бета-версии и требуют флага совместимости python_workers. Планируя на них продакшен-нагрузку, вы принимаете бета-статус и возможные изменения поведения.
• Время CPU измеряет время, потраченное на выполнение, а не реальное время (wall-clock). Ожидание подзапроса не расходует время CPU, но общая длительность запроса всё равно подчиняется тайм-аутам HTTP и поведению клиента.
• Холодный старт полностью не устраняется. Большие бандлы, объёмная инициализация на уровне модуля и создание экземпляров WebAssembly ощутимо увеличивают время запуска.
• При постепенном развёртывании одновременно работают две версии, поэтому на время развёртывания изменения схемы и формата данных должны сохранять обратную совместимость.
• Совместимость с Node.js частичная и зависит от флага nodejs_compat и даты совместимости. Библиотеки, которым требуются неподдерживаемые API Node.js, нативные модули или долгоживущие необработанные TCP-соединения, могут не работать.
• На уровне аккаунта действуют ограничения по параллелизму и частоте запросов. Если для рабочей нагрузки ожидаются экстремальные всплески параллелизма, это следует подтверждать по условиям контракта, а не принимать как данность.

Доступность по планам

Развёртывание

Предварительные требования.

• Определите подходящую нагрузку и классифицируйте её: edge-логика перед существующим origin-сервером, API, задача по расписанию или полноценное приложение.
• Сопоставьте рабочую нагрузку с примитивами платформы и зафиксируйте требования к согласованности для каждой части состояния, поскольку именно это определяет выбор хранилища.
• Перед написанием кода сверьте нагрузку с документированными лимитами: пиковое использование CPU на запрос, пиковое использование памяти, количество исходящих вызовов на запрос, размер бандла и любые зависимости, которым нужны неподдерживаемые API Node.js.
• Подтвердите выбранную среду выполнения. Если предлагается Python, зафиксируйте, что Python Workers находятся в открытой бета-версии, и получите решение, приемлем ли такой статус.
• Зафиксируйте, где сейчас хранятся секреты и как они будут передаваться в качестве секретов Worker.
• Зафиксируйте текущий путь трафика и маршрут отката к нему.

Поэтапная проверка. Реализуйте нагрузку в тестовом окружении с собственными привязками и собственными данными и проверьте её на репрезентативном трафике. Замерьте время CPU на вызов, использование памяти и число подзапросов относительно лимитов тарифного плана, а также поведение при холодном старте на боевом размере бандла, а не на урезанном. Убедитесь, что данные наблюдаемости доходят до нужного назначения, прежде чем направлять на сервис реальный трафик.

Настройка.

1. Явно объявляйте привязки и указывайте дату совместимости, не полагаясь на значение по умолчанию.
2. Перенесите все учётные данные в секреты Worker и убедитесь, что в репозитории или конфигурационном файле их не осталось.
3. Настройте отдельные стейджинг- и продакшен-окружения с разными ресурсами хранения, чтобы ошибка при развёртывании не могла привести к записи в продакшен-данные.
4. Настройте CI так, чтобы развёртывание выполнялось пайплайном с ограниченным по правам API-токеном, а не с рабочей станции разработчика.
5. Добавьте ограничение частоты запросов перед общедоступными маршрутами Worker, а также кеширование там, где это допускает ответ, чтобы ограничить объём запросов и, соответственно, расходы.
6. Оцените стоимость при ожидаемом трафике по страницам тарификации каждого сервиса, включая классы операций хранения, и настройте оповещения о выставлении счетов.

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

Верификация.

• Прежде чем увеличивать долю трафика, проверьте частоту ошибок и задержку на каждом её значении относительно зафиксированного базового уровня.
• Убедитесь, что время CPU на один вызов остаётся в пределах установленного лимита при характерной для продакшена структуре трафика, поскольку превышение лимита под нагрузкой проявляется как перемежающиеся сбои.
• Убедитесь, что логи и метрики формируются и хранятся так, как предполагалось.
• Убедитесь, что объём операций с хранилищем соответствует ожидаемому, поскольку во многих архитектурах на стоимость больше влияет количество операций, чем количество запросов.
• Убедитесь, что предыдущий путь по-прежнему работает, чтобы откат оставался возможен.

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

Вопросы эксплуатации

Отслеживайте время CPU, частоту ошибок и количество подзапросов по каждому маршруту, а не только объём запросов. Сбои, связанные с лимитами, проявляются под нагрузкой и незаметны в тестовой среде с низким трафиком.

Периодически пересматривайте дату совместимости. Если оставить её неизменной надолго, Worker будет работать со всё более устаревшим поведением среды выполнения; если же изменить дату без тестирования, поведение изменится непредсказуемо. Относитесь к изменению даты как к отдельному изменению, которое требует собственной проверки.

Следите за количеством операций с хранилищем наряду с количеством запросов. Если архитектура выполняет несколько операций с KV или D1 на каждый запрос, стоимость определяется в основном этими операциями, и изменение кеширования может существенно изменить сумму счёта в любую сторону.

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

Проектируйте ключи Durable Object так, чтобы нагрузка распределялась между объектами. Если один объект обрабатывает непропорционально большую долю трафика, он становится потолком пропускной способности, который не устраняется никаким масштабированием платформы.

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

Известные особенности

• Python Workers находятся в открытой бета-версии и требуют флага совместимости. Если упомянуть их рядом с общедоступными средами выполнения без этой оговорки, архитектор может заложить в план продакшена бета-версию среды выполнения.
• У платформы есть ограничения по ресурсам. Время CPU, память, размер бандла, количество подзапросов и квоты на уровне сервиса ограничивают возможности одного вызова.
• Холодный старт есть. Для компактных JavaScript-бандлов он незначителен, а для крупных бандлов и создания экземпляров WebAssembly увеличивается.
• Постепенное развёртывание намеренно не атомарно. Две версии обслуживают запросы одновременно, и это требование к совместимости данных, а не просто деталь реализации.
• KV обеспечивает согласованность в конечном счёте и имеет ограничение на частоту записи для каждого ключа. Использование KV в качестве основного хранилища для быстро изменяющегося состояния приводит к проблемам с корректностью данных, которые проявляются только при параллельном доступе.
• Durable Object однопоточен. Пропускная способность на объект ограничена архитектурно, а не тарифным планом аккаунта.
• Совместимость с Node.js частичная. Дерево зависимостей, которое успешно собирается локально, всё же может дать сбой во время выполнения из-за неподдерживаемого API.
• Переносимость частичная. Стандартные веб-API, совместимый с S3 API R2 и диалект SQLite в D1 сохраняют переносимость большей части логики приложения, тогда как перенос Durable Objects и других платформозависимых сервисов потребует изменения архитектуры. На этапе проектирования определите, к какой категории относится каждый компонент.

Взаимодействие с другими продуктами

Workers выполняются после фаз безопасности конвейера обработки запросов Cloudflare, поэтому решения WAF, DDoS и Bot Management применяются раньше, чем запускается код Worker. Заблокированный запрос никогда не доходит до Worker.

Workers взаимодействуют с CDN через Cache API и через Cache Rules. Если и Cache Rule, и логика кеширования Worker применяются к одному и тому же запросу, приоритет определяется задокументированной последовательностью обработки трафика.

R2 может служить origin-сервером для CDN и лежит в основе Cache Reserve, поэтому объектное хранилище, кеширование и вычисления работают вместе без традиционного origin-сервера.

Service bindings позволяют одному Worker вызывать другой без обращения по сети, что даёт возможность разбивать приложение на отдельно развёртываемые модули и сохранять низкую задержку вызовов.

Валидацию Turnstile можно выполнять в Worker, то есть на границе сети, а не в бэкенде приложения.

Access можно разместить перед маршрутом Worker, чтобы запросы проходили аутентификацию и авторизацию до вызова, без необходимости реализовывать аутентификацию в самом Worker.

Часто задаваемые вопросы

Требуется ли полная миграция приложения для перехода на Workers? Нет. Обычно Worker ставят на маршрут перед существующим origin-сервером, где он обрабатывает редиректы, логику кеширования, аутентификацию или персонализацию, а само приложение остаётся на месте. Переносить ли само приложение, решается отдельно.

Что на самом деле измеряет ограничение CPU? Время, затраченное на выполнение кода, а не общая длительность запроса. Ожидание подзапроса не расходует время CPU, поэтому запрос может длиться дольше, чем лимит CPU, не превышая его.

Где хранить состояние сессии или координации? Durable Objects, если требуется строгая согласованность или координация на уровне отдельных сущностей. KV обеспечивает согласованность в конечном счёте и ограничивает частоту запросов на ключ, поэтому не подходит для быстро изменяющегося состояния в рамках одного ключа.

Какие части приложения на Workers можно перенести на другую платформу? Код, написанный с использованием стандартных веб-API, данные в R2 через S3-совместимый API, а также схемы и запросы D1 на диалекте SQLite в основном переносимы. Durable Objects и другие платформенно-зависимые сервисы потребуют переработки архитектуры.

Источники

• https://developers.cloudflare.com/workers/, дата обращения 2026-08-28.
• https://developers.cloudflare.com/workers/platform/limits/, дата обращения 2026-08-28.
• https://developers.cloudflare.com/workers/platform/pricing/, дата обращения 2026-08-28.
• https://developers.cloudflare.com/workers/languages/python/, дата обращения 2026-08-28.
• https://developers.cloudflare.com/workers/configuration/compatibility-dates/, дата обращения 2026-08-28.
• https://developers.cloudflare.com/workers/configuration/versions-and-deployments/gradual-deployments/, дата обращения 2026-08-28.
• https://developers.cloudflare.com/kv/, дата обращения 2026-08-28.
• https://developers.cloudflare.com/r2/, дата обращения 2026-08-28.
• https://developers.cloudflare.com/d1/, дата обращения 2026-08-28.
• https://developers.cloudflare.com/durable-objects/, дата обращения 2026-08-28.

Снимок контента: 2026-08-28.

История изменений