Что произошло с Deno

9 октября 2026 года Deno объявила о переходе всей команды в Cloudflare. Компания прекращает самостоятельное развитие собственного рантайма и хостинговой платформы, а разработки команды будут объединены с экосистемой Cloudflare Workers и Durable Objects.

Для пользователей у этого решения есть три практических последствия:

  • Deno Deploy продолжит работать ещё шесть месяцев, после чего будет закрыт.
  • Рантайм Deno получит примерно год ежемесячных обновлений, включая исправления ошибок и уязвимостей.
  • JSR — реестр пакетов JavaScript и TypeScript — продолжит работу, но его инфраструктура перейдёт под управление Cloudflare.

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

Важно аккуратно называть произошедшее: официально речь идёт о присоединении команды Deno к Cloudflare и интеграции разработок. Финансовые условия и юридическая структура сделки публично не раскрыты.

Почему это важно для Cloudflare

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

Cloudflare постепенно продаёт не просто вычислительные мощности, а собственную модель построения серверных приложений. Разработчик работает не с набором отдельных виртуальных машин, баз данных и очередей, а с распределёнными объектами, состоянием, сетевым взаимодействием и хранением данных внутри единой среды.

Такая модель удобна, но создаёт риск зависимости от поставщика. Чем больше деталей приложения завязано на специфические API, тем дороже последующая миграция. Именно здесь появляется обещание переносимости: workerd распространяется как открытый проект, а Cloudflare связывает его с возможностью запускать Workers и Durable Objects за пределами собственной сети.

Концептуальная схема зависимости приложения от облачной платформы и возможности переноса рантайма
Иллюстрация: ИИ

Это не устраняет зависимость автоматически. Открытый исходный код решает только часть задачи — прежде всего вопрос доступа к самому программному слою. Данные, секреты, журналы, мониторинг, биллинг, домены и операционные процессы могут по-прежнему оставаться привязанными к конкретному облаку.

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

«Выход» как инструмент продаж

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

Её позиция выглядит так: открытый код и возможность самостоятельного запуска не вредят бизнесу, а помогают продавать платформу. Клиент выбирает Cloudflare не потому, что заперт внутри, а потому, что управляемая облачная версия удобнее, быстрее и надёжнее самостоятельного развертывания.

Для провайдера это модель «открытое ядро плюс управляемый сервис». Открытая версия привлекает разработчиков и снижает опасения крупных компаний. Облачная версия монетизирует удобство: инфраструктуру не нужно самостоятельно обновлять, масштабировать, защищать и наблюдать.

Метафора модели «открытое ядро плюс управляемый облачный сервис»
Иллюстрация: ИИ

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

Что делать пользователям Deno Deploy

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

Минимальный чек-лист

  1. Составьте карту зависимостей. Отдельно перечислите API Deno Deploy, фоновые задачи, хранилища, переменные окружения, домены и механизмы авторизации.
  2. Проверьте переносимость в Workers. Совместимость рантайма не гарантирует совместимость всей архитектуры приложения.
  3. Экспортируйте данные и секреты. Уточните, в каком формате их можно получить и можно ли восстановить проект вне Cloudflare.
  4. Зафиксируйте наблюдаемость. Логи, метрики, трассировка и правила оповещений часто оказываются менее переносимыми, чем код.
  5. Проверьте условия поддержки. В официальном сообщении особое внимание уделено миграции платных клиентов; небольшим командам не стоит рассчитывать, что индивидуальное сопровождение будет доступно автоматически.
  6. Подготовьте тестовый сценарий самостоятельного запуска. Даже если переезд не планируется, такая проверка покажет, что именно в системе является открытым, а что — сервисной оболочкой.
Карта зависимостей приложения перед инфраструктурной миграцией
Иллюстрация: ИИ

Иллюстрации: ИИ

Пользователям самого рантайма Deno год исправлений даёт время для выбора. Можно перейти на другой JavaScript-рантайм, дождаться развития открытых компонентов Cloudflare или продолжить использовать Deno, опираясь на сообщество. Но после завершения регулярной разработки ответственность за безопасность и совместимость станет менее предсказуемой.

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

Что эта история говорит предпринимателям

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

Полезные вопросы для закупки инфраструктуры:

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

Для систем с AI-агентами этот вопрос становится ещё важнее. Агенту нужны состояние, доступ к инструментам, сетевые вызовы и длительное выполнение задач. Тот, кто контролирует среду исполнения, фактически получает влияние на архитектурный слой между моделью и бизнес-приложением.

Вывод

Cloudflare не просто усиливает Workers за счёт команды Deno. Компания пытается сделать открытый рантайм частью коммерческой стратегии: дать клиентам ощущение контроля, а затем предложить им более удобную управляемую версию.

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