Cloudflare купил Deno: что это реально значит

9 октября 2026 года Cloudflare объявил, что вся команда Deno переходит к ним. Формулировка в новостях — «Cloudflare купил Deno» — звучит как «ещё один рантайм умер под катком облачного гиганта», и часть сообщество отреагировала ровно так: Node-экосистема потеряла ещё один независимый дом, а значит, надо бежать обратно к Cloudflare. Это прочтение — неверное, и оно переворачивает смысл сделки на 180°.

Если читать сами анонсы (пост Райана Дала на блоге Deno и совместный пост Дала с Кентоном Вардой на блоге Cloudflare), становится видно: купили не JavaScript-рантайм. Рантайм deno даже закрывают — через год активной разработки. Купили другое: модель программирования Workers и человека, который всё лето писал open-source способ запускать эту модель на чужом железе. Этот проект — celld. Цель сделки по формулировке Дала — сделать так, чтобы вы могли запускать ту же модель «whether you run on Cloudflare’s network or your own infrastructure» — то есть у себя.

Это первая и установочная статья серии «Edge после сделки Cloudflare + Deno». Здесь разберём: что именно произошло по фактам и датам (с оговоркой — сроки двигаются, их надо переснимать по источнику), что такое Durable Objects и почему за них платят, почему это разворот «от Cloudflare», а не «к нему», и карту из трёх путей для того, у кого уже что-то живёт на Deno. Для читателя с PHP+VPS — отдельная часть про то, почему вам это, возможно, вообще не про вас, и когда всё-таки про.

Термин-ловушка — снять сразу. В серии у нас уже есть статья про сервис-воркеры и офлайн-режим. Там Service Worker — это скрипт в браузере, прокси между страницей и сетью. Здесь Cloudflare Workers и рантайм workerd — это серверная история, код исполняется на машине провайдера или на вашей. Имя почти одно, природа противоположная: клиентский посредник против серверного рантайма. Дальше под «воркером» мы имеем в виду именно серверный Workers-воркер.

Часть I. Что произошло и в какие сроки (фактбаза с оговоркой)

Начнём с того, что можно процитировать, и сразу отделим факт от предсказания.

1. Официальный текст сделки

Из блога Deno (9 октября 2026, Райан Дал) — что именно обещано:

«Today we’re announcing that the entire Deno team is joining Cloudflare to take that work further.»

Конкретика по продуктам, там же:

Runtim deno: поддержка ещё год — ежемесячные релизы с багфиксами и обновлениями безопасности; после этого прекращение активной разработки. Рантайм остаётся open source, и команда «приветствует тех, кто хочет продолжить его развитие».
Deno Deploy: проработает ещё шесть месяцев, затем остановка; платящим клиентам обещана поддержка переезда на Cloudflare Workers.
JSR (реестр модулей): продолжит работу, инфраструктура переезжает под Cloudflare.
workerd: будут продолжать поддерживать и двигаться к интеграции в него наработок Deno (rusty_v8 и celld).

Из совместного поста на блоге Cloudflare (Дал + Варда) — цель:

«We’re joining Cloudflare to make the Workers programming model a mainstream way to build servers.» «…whether you run on Cloudflare’s network or your own infrastructure.»

2. Почему цифры дат — ориентир, а не гарантия

«Год от 9 октября» — это ≈ октябрь 2027 для рантайма, «шесть месяцев» — ≈ апрель 2027 для Deno Deploy. Часть СМИ так и пишет, но с пометкой «проверить перед публикацией», потому что это выведенные из интервала даты, а не названные в анонсе. В самом официальном тексте стоит относительный срок («another year», «six months»), а не конкретный день останова.

Для вас это значит практичную вещь: в планировании переезда закладывайте буфер и переснимайте точную дату по официальному анонсу в тот день, когда принимаете решение. Эта статья фиксирует метод, а не календарь. Сроки — живой параметр сделки, они могут сдвинуться в любую сторону, и полагаться на дату, переписанную из чужого пересказа, — так же наивно, как на «повесил llms.txt — и тебя цитируют» (об этом разбор в GEO-серии).

3. Реакция сообщества и её честный вес

Независимые обзоры (например, heise) встретили сделку скептически: заголовок-комментарий буквально — «judged by its own promises» («судить по её же обещаниям»). Смысл претензии: вендор обещает год патчей и открытый код, но у открытого рантайма без команды-драйвера будущее зависит от того, найдётся ли кто-то, кто потянет форк. Это не опровержение фактов анонса, а здоровый контрвес: ни один из них не утверждает обратного насчёт celld и workerd. Мы держим обе рамки: модель и self-hosting — это то, что реально движется; судьба отдельного рантайма deno — под вопросом, и решение «остаться на нём» надо принимать, исходя из готовности сообщества его содержать.

4. Кто такие Дал и Варда (чтобы понять, почему это всерьёз)

Райан Дал — создатель Node.js: он же автор той самой демонстрации 500-строчного IRC-сервера, с которой JS пошёл на сервер. Deno он начал, чтобы «искать более мощные абстракции» и упрощать. Кентон Варда — один из ключевых инженеров Cloudflare, архитектор Workers и Durable Objects. Когда создатель Node.js и архитектор Durable Objects вместе говорят «мы объединяем workerd и celld, чтобы запускать это на вашей инфраструктуре», это не маркетинг слияния ради доли рынка — это совпадение двух людей вокруг одной инженерной цели. Отсюда и доверие к тезису «разворот наружу» в Части III.

Часть II. Что именно купили: Durable Objects и `celld`

Чтобы понять ценность, надо на одну минуту забыть про «рантайм» и посмотреть на модель программирования.

1. Durable Object — это не «функция», это маленький сервер

Классическая облачная «функция» (serverless) stateless: вызвали — отдала ответ — исчезла. Состояние вы выносите наружу: в БД, в кэш, в очередь. Cloudflare Workers пошли другим путём и добавили абстракцию Durable Objects (DO). Дал описывает её так (свободный пересказ его поста):

Каждый Durable Object — как небольшой индивидуально адресуемый сервер со своей реляционной базой (SQLite). Его JavaScript-исполнение однопоточное (его легко рассуждать как), он держит WebSocket-соединения, и к его локальной базе можно обращаться синхронно.

Разберём, почему это сильно, на их же примере чата. Строите приложение — не «одну машину IRC», а один DO на каждый канал. Каждый канал — это:

свой адрес (можно послать запрос конкретно в #общий),
своя SQLite-база с историей этого канала,
свои живые WebSocket-соединения пользователей канала,
однопоточное исполнение — нет гонок внутри канала, рассуждать легко.

Тем самым шардирование данных и соединений встроено в модель: вы не собираете кластер из балансировщика, реплик БД и брокера сообщений — вы просто создаёте «ещё один DO на ещё один канал», и платформа сама решает, где его разместить, как дорутить запрос и как хранить базу. Дал прямо формулирует мечту: «could the programming model make partitioning across machines part of the design from the start?» — и отвечает: Durable Objects это и есть.

Поверх одной абстракции DO, по его словам, строятся остальные сервисы: очереди, KV, «Durable Execution» (Workflow API), даже Git-хранилище. Одна примитивная сущность — и вокруг неё целая платформа.

2. `celld` — то, ради чего, собственно, покупка

До лета 2026 у модели Workers была одна практическая проблема: она жила только внутри Cloudflare. Runtim workerd выпущен в open source (об этом ниже), но Durable Objects в нём работали только в режиме одного экземпляра — годилось для локального теста, но не для распределения по машинам. Варда пишет это прямым текстом, с признанием вины:

«workerd has always had one big gap in its production-readiness: Durable Objects. Workerd implements them, but only in a single-instance way, good enough for local testing, but unable to scale.»

То есть сам вендор признаёт: то, что делает Workers по-настоящему мощным (масштабируемые DO), в их же открытом рантайме не работало. Они пытались починить — «embarrassingly, it didn’t work», по словам Варды.

Август 2026 — команда Deno выпускает celld (celld.dev): open-source реализацию именно распределённых Durable Objects для self-hosting’а. Идея Дала после опыта с Deno Deploy: не строить ещё одно облако с десятками склеенных сервисов, а дать один бинарник на Rust, внешний единственный dependency — объект-хранилище (S3-совместимый bucket). Хостинг приложения сводится к тому, что вы гоняете много инстансов celld и один bucket. Это ровно та простота, за которой, по его словам, он шёл «с самого первого демо Node.js».

Вот это купили. celld + людей, которые его написали, чтобы слить обратно в workerd и сделать self-hosting Workers распределённым, а не «single-instance для теста». Прямая цитата:

«we’re merging workerd and celld!» «…make workerd self-hosting a first-class supported way to build and run apps using the Workers programming model.»

3. Почему это покупка модели, а не рантайма

Теперь сопоставьте два факта рядом:

Самому рантайму deno — счёт на годы, и потом остановка.
celld/workerd — инвестиция и будущее команды.

Если бы целью было «убить конкурента и забрать пользователей», приоритеты были бы обратными. Здесь же явно убирают конкурирующий рантайм (свой deno закрывают) и вкладываются в общий порт для выхода наружу (workerd + celld). Это поведение не того, кто хочет вас привязать, а того, кто хочет, чтобы модель побеждала — в том числе у вас на сервере. Это и есть центральный тезис серии, и он переворачивает прочтение «Cloudflare всех купил».

Часть III. Почему это разворот «от Cloudflare», а не «к нему»

Самый популярный страх в сообществе: «теперь вообще всё будет через Cloudflare, lock-in станет нормой». Разберём, что говорит по этому поводу сам Cloudflare — и почему этот страх, по крайней мере в официальной рамке, адресован.

1. Миф про lock-in и ответ Варды

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

«»Lock-in» actually hurts us — that’s why we went open source»

Логика такая. Ходит теория: Workers специально сделали непохожими на другие облака, чтобы создать привязку; софт, написанный под Workers, тяжело унести; значит, загнав туда клиента, потом «выдёргивают коврик». Под эту теорию celld — угроза: открытая реализация Workers/Durable Objects, которая позволяет приложениям уйти к другому провайдеру или на своё железо. «No more trap!» — пишет Варда и отвечает: теория неверна.

Его аргументы:

Workers сделали другими не для привязки, а потому что иначе нельзя. «We built Workers differently because we believe it’s a better way to build web applications.» Привязка была бы удобна бизнесу («it would be a great benefit to our business if every kind of compute workload could simply be lifted and shifted onto Workers») — но выгоды совместимости они сознательно не получили бы, не пожертвуй моделью.
Открытость — условие, при котором крупные клиенты вообще согласились. Когда в 2022 питчили Workers for Platforms таким как Shopify, фидбек был прямой: «не построим на вас, пока рантайм не станет open source». И они открыли workerd — тот же код, что крутится в проде, не параллельная реализация.
Люди реально уходят — и это ок. «We have former customers that migrated away from us by using workerd. And that’s OK!» — по формулировке Варды, без открытого выхода эти клиенты никогда бы не пришли изначально.

2. Что отсюда следует практически

Самая практичная часть сделки — это дверь наружу, а не внутрь. Если вы боитесь привязки к вендору, то по логике анонса именно теперь Workers-модель перестаёт быть гарантированной ловушкой: вендор своими руками (и чужими ногами — командой Дала) строит workerd+celld так, чтобы приложение можно было поднять дома. Варда говорит: «I will personally be using it to host an instance of Cloudflare OS in my home.»

Но держим и честную рамку скептиков из Части I, §3: дверь обещана, но не гарантирована по срокам. «We’ll have more announcements about this work in the coming months» — то есть production-ready распределённый self-hosting workerd — это ещё в пути, сегодня вы можете начать поднимать celld или одиночный workerd, но «первый класс поддержки» обещают построить. Решение «уходить на self-hosting прямо сейчас» принимать, исходя из того, что кирпич уже есть и он рабочий, а вендорская «коробочная» зрелость — ещё нет.

3. Это меняет сам вопрос выбора

Раньше выбор «Workers или своё облако / свой VPS» включал в себя тихий пункт «если возьму Workers — не смогу унести». Сделка этот пункт переписывает. Дал формулирует новый вектор: «make this programming model the default way to build servers, whether you run on Cloudflare’s network or your own infrastructure». То есть вопрос смещается с «чьё облако выбрать» на «какая модель программирования вам удобна и можно ли её унести». Именно эти два вопроса — «какая модель переносима» и «можно ли её унести» — разбирают статьи №3 про self-hosting workerd и №5 про выбор архитектуры этой серии.

Часть IV. Карта путей: что делать, если у вас уже что-то на Deno

Это ядро для читателя с дедлайном. Не «бежать немедленно», а осознанно выбрать один из трёх путей по своей задаче.

1. Три двери — одним взглядом

У вас приложение на Deno / Deno Deploy (9 окт. 2026 → ...)
│
├─ ПУТЬ A. Мигрировать на Cloudflare Workers
│    · самый «обслуженный» путь: обещана поддержка переезда для платящих Deploy-клиентов
│    · но это привязка к модели Workers (см. Часть III: выход есть, но это другая экосистема)
│    · переписывается способ доставать ресурсы (bindings вместо URL-import/npm:) → тема №2 серии
│
├─ ПУТЬ B. Переезжать на self-host workerd / celld
│    · остаётесь в модели Workers, но на своей инфраструктуре
│    · сегодня: workerd рабочий, но DO — single-instance; celld добавляет распределение,
│      «коробочная» вендорская зрелость ещё строится
│    · для тех, кто хочет контроль и возможность уйти (тема №3 серии)
│
└─ ПУТЬ C. Остаться на рантайме deno под open-source-форком
     · рантайм не закрывается физически (остается открытый код); через год активной
       разработки судьба — за тем, кто подхватит форк (скепсис heise: «зависит от преемника»)
     · подходит, если вы используете мало и не гонитесь за фичами рантайма
     · риск: нет гарантий по безопасности/экосистеме после остановки команды

2. По какому критерию выбрать

Уже платите за Deno Deploy и он ваш прод → Путь A по умолчанию: вендор обещал помощь в миграции, дедлайн полгода, это наименьший операционный риск. Но понимайте: вы переходите в другую модель программирования, а не «настраиваете тот же код». Что именно ломается при таком переезде и что переносится один-в-один — это статья №2 серии.
Цените контроль / не хотите зависеть от чужого аптайма и цен → Путь B, self-host. Это прямой потомок линии «владей инфраструктурой», которую мы разбирали на примере моделей (Ollama на своём VPS): тот же аргумент — приватность данных, цена на потоке, автономность — только теперь про рантайм приложений, а не про инференс. Учтите зрелость: это ещё строится (Часть III, §2).
Deno у вас для пары скриптов и ничего критичного → возможно, Путь C, «посидеть и посмотреть». Активный рантайм до ≈окт. 2027 идёт, закрытого кода никто не отбирает. Риск — не сегодня, а потом, и он зависит от появления мейнтейнера форка.

3. Чего делать не стоит

Не стоит рефакторить всё под Workers «на всякий случай» до того, как посмотрели, чем вы реально пользуетесь. Значительная часть ценности Deno для простых случаев — это DX (один бинарник, встроенные тесты, форматирование, TS из коробки), и при переезде на Workers вы платите не за фичи, а за способ доставки до ресурсов и за другую экосистему деплоя. Решение «мигрировать» должно опираться на то, используете ли вы то, ради чего затеяна сделка — Durable Objects и распределение. Если у вас CRUD-эндпоинт на Deno.serve — у вас почти нет причин бежать прямо сейчас; если у вас реалтайм с сотнями live-каналов и общим состоянием — вы как раз в ядре того, что меняется.

Часть V. AI-угол сделки: агенты, а не инференс

Отдельная линия, важная для наших читателей, которые встраивают LLM в продукты.

1. Что Дал говорит про AI и Durable Objects

В финале своего поста Дал называет то, что его «больше всего волнует»:

«The need for better abstractions is especially acute with AI. Durable Objects bring together capabilities that are particularly useful for agent harnesses: inexpensive, serverless execution, persistent state, WebSockets, and a high-level JavaScript interface.»

Обратите внимание на список: дешёвое исполнение, персистентное состояние, WebSocket’ы. Это не «запустить большую модель на edge». Ничто в анонсе не обещает инференс LLM на PoP. Обещано другое — удобная обвязка вокруг агента: у агента есть память (состояние), живой канал (WebSocket к пользователю), и он платит только за исполнение, а не за постоянный сервер.

2. Почему для агента это и правда удобно

Агентный цикл по природе stateful и долгоживущий: держит историю шагов, ждёт ответа пользователя или инструмента, иногда висит на стриминге. Классический «бессмертный сервер» под каждого агента — расточителен; «бессерверная функция» — stateless, историю надо где-то хранить и реконструировать на каждый вызов. Durable Object закрывает ровно эту дыру: один DO = один агент/сессия со своей SQLite-памятью и живым сокетом. Это та же абстракция, что «один DO на канал чата» из Части II, только сущность — не канал, а агент.

3. Честная граница

Инференс остаётся там же, где был — в облаке LLM-API или на вашей машине (Ollama на VPS, песочница LocalNode). Edge-рантайм тут про оркестрацию и состояние, а не про то, чтобы гонять веса модели на PoP.
Приватность не появляется автоматически. Если агент на Workers ходит в чужое LLM-API, ваши данные всё равно уходят во внешнюю систему — тот же аргумент, что разбирает статья про безопасность ИИ и локальные модели. Edge лишь меняет, где живёт состояние агента.
MCP/лёгкие модели на Workers — отдельная практическая линия, и её зрелость надо сверять по источнику в момент написания; в этой статье мы фиксируем только рамку: сделка про состояние агента, не про инференс на краю.

Часть VI. А нужно ли это вам, если у вас WordPress + PHP + свой VPS

Честный ответ для основной аудитории сайта: чаще всего — пока нет, и это не вы отстали, а сделка не про вас. Но есть точные условия, при которых она становится про вас.

1. Где сделка вас не касается

Ваш продакшн — монолит WordPress на своём VPS с PHP-FPM и MySQL (разбирали слои конфигурации и анатомию VPS). Вы ничего не держите на Deno, у вас нет дедлайна из Части IV, и переезжать вам нечего. Модель Workers вам не нужна, чтобы отдавать страницы: для «контент рядом с пользователем» у вас уже есть CDN и кэш — база этого в статье про CDN и edge-вычисления. Тяжёлое состояние (пользователи, заказы, сессии WooCommerce) живёт в вашей MySQL — и сравнение архитектуры, которое выйдет в этой серии, как раз покажет, что на «один язык + тяжёлое состояние» свой VPS часто остаётся дешевле и под контрольнее.

2. Где она вас всё-таки касается

Вы строите на PHP/WordPress что-то реалтайм и stateful — чат, живой редактор, уведомления, счётчики в реальном времени. Здесь абстракция Durable Object («адресуемый маленький сервер с базой и сокетом») решает ровно ту задачу, ради которой на классическом стеке приходится городить отдельный сокет-сервер, Redis-состояния и шардинг (смежно — потоки SSE/WebSocket в браузере и очереди сообщений). Это точка, где стоит присмотреться.
У вас публичное API/микрофича с географией далеко и кодом тонко — тонкий слой на Workers у PoP снимает латентность, которую не уберёт оптимизация вашего origin (физика расстояния — в Части I CDN-статьи).
Вы строите агентные контуры вокруг LLM — тогда Часть V про «состояние агента» вам ближе, чем кажется.
Вы просто не хотите зависеть от одного вендора — иронично, но именно self-host-линия (workerd+celld) в эту сторону и смотрит; выбор «носить модель между платформами» становится доступнее, а не закрытее.

3. Что делать прямо сейчас

Ничего срочного. Прочитать Части II и V, понять, есть ли у вас реалтайм/stateful/агентный контур, и если да — держать в прицеле №3 про self-host и №5 про выбор. Если живёте на Deno — не паниковать, а открыть Часть IV и выбрать путь.

Инструменты под задачу

Перенести кусок кода / разобрать worker — AI-ассистент для кода на codestack.space: вставьте свой Deno.serve— или Workers-фрагмент и попросите показать, что ломается при переносе между рантаймами (это тема №2 серии).

Чек-лист граблей

Путаница имён. Service Worker (браузер, ваш офлайн-слой) ≠ Cloudflare Workers/workerd (сервер). В разговоре с командой и в доках всегда уточняйте, о каком «воркере» речь — иначе архитектурное решение принимается не о той технологии.
Дата из пересказа. «Остановят 31 октября 2027» — почти наверняка выведенный из «год от анонса» ориентир, а не названный день. Планируйте переезд от официального анонса и держите буфер, а не от чужого календаря.
Рантайм ≠ модель. «Deno закрывают» не значит «ваш код умер»: рантайм open source и живёт ещё год; но переезд на Workers — это смена способа достучаться до ресурсов, а не языка. Недооцените это — и миграция «в один вечер» растянется на переделку биндингов, env и деплоя.
Мигрировать ради миграции. Если у вас Deno.serve с парой эндпоинтов и вы не пользуетесь Durable Objects — у вас мало поводов бежать сегодня. Действуйте от фактической зависимости, а не от заголовка новости.
Привязка к Cloudflare при переезде. Путь A снимает один риск (закрытие Deno Deploy) и добавляет другой (вы в экосистеме Cloudflare). Если контроль критичен — см. Путь B; но «коробочная» зрелость self-hosting’а Workers ещё строится, это не готовый продакшн «на сегодня».
AI = не инференс на краю. Анонс говорит про состояние агента (DO), не про «LLM на PoP». Не закладывайте в архитектуру ожидание, что модель начнёт думать у границы сети, — веса остаются в облаке или на вашей машине.

👤 Зарегистрируйтесь, чтобы добавить материал в закладки.