Deno переходит в Cloudflare: Deploy закроется через шесть месяцев

Команда Deno переходит в Cloudflare. Райан Даль объявил об этом 9 октября 2026 года и назвал сроки для существующих продуктов: Deno Deploy продолжит работать ещё шесть месяцев, а runtime Deno будет получать ежемесячные исправления и обновления безопасности ещё год. После этого команда завершит его разработку. Для проектов на Deno это повод заранее оценить зависимости и составить план дальнейшей эксплуатации.

В центре нового направления — Cloudflare Workers и Durable Objects, включая запуск на собственной инфраструктуре. Разбираем, что подтверждено в анонсах, какие продукты продолжат работу и с чего начинать проверку приложения перед возможным переносом.

Что объявили Deno и Cloudflare

В Cloudflare переходит вся команда Deno. По совместному сообщению компаний, Райан Даль и Берт Белдер возглавят работу над полноценной поддержкой самостоятельного размещения приложений, построенных по модели Workers. В неё войдут код и идеи celld — проекта команды Deno для распределённых Durable Objects.

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

Исходный код Deno останется открытым; команда приветствует продолжение разработки другими участниками. Платящим клиентам Deploy обещана помощь с миграцией в Cloudflare Workers. Сроки в сообщении заданы длительностью, поэтому для рабочего проекта нужно отслеживать дальнейшие уведомления сервиса и условия переноса.

Почему важна разница между runtime и хостингом

Runtime — среда выполнения, которая запускает код. Хостинг — сервис, на котором приложение размещено. Реестр пакетов — место распространения библиотек. Они могут использоваться вместе, но зависимость от каждого из них нужно проверять отдельно.

Например, у команды может быть Deno-приложение на собственном сервере. Для него вопрос касается будущего среды выполнения и используемых библиотек. У другого проекта код развёрнут в Deno Deploy: здесь добавляется задача переноса самого сервиса, его настроек и данных. Автоматически считать эти проекты одинаковыми было бы ошибкой.

Третий случай — библиотека из JSR в приложении на другой платформе. Документация JSR описывает использование пакетов с Deno, Node.js, Bun и другими инструментами, а также совместимость с npm. Поэтому наличие JSR-зависимости само по себе не означает, что приложение размещено в Deno Deploy.

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

Что Cloudflare собирается делать с celld и workerd

workerd — открытая среда выполнения, лежащая в основе Cloudflare Workers. В совместном анонсе цель сформулирована как упрощение самостоятельного размещения приложений с Workers и Durable Objects. Компания планирует объединить наработки celld с workerd; новые сообщения о проекте обещаны в ближайшие месяцы.

Репозиторий celld описывает его как самостоятельно размещаемую реализацию распределённых Durable Objects. Это объясняет интерес к команде Deno: задача касается всей модели работы серверного приложения — исполнения кода, состояния и взаимодействия между частями системы.

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

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

Зачем в этой истории Durable Objects

Durable Objects — механизм Cloudflare для приложений с состоянием. Объект объединяет вычисления и хранилище, имеет уникальное имя и может координировать обращения нескольких клиентов. В документации среди примеров названы совместное редактирование, интерактивные чаты и многопользовательские приложения.

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

Применительно к своему проекту стоит начать с простых вопросов: какие данные переживают отдельный запрос, кто их изменяет и как восстанавливается работа после сбоя. Ответы важнее общего обещания «приложение переедет в serverless». Serverless — модель, в которой платформа управляет запуском вычислений; архитектурные решения приложения всё равно остаются задачей команды.

Что проверить перед переносом в Workers

Начните с совместимости используемых API и пакетов. Cloudflare публикует список поддерживаемых Node.js API: часть реализована полностью, часть — частично. Для отдельных модулей существуют заглушки, позволяющие импортировать пакет, хотя вызов конкретного метода может не работать. Поэтому успешная установка зависимостей ещё не подтверждает работоспособность сервиса.

Проверьте рабочие сценарии: обработку HTTP-запросов, доступ к внешним API, авторизацию, фоновые действия и сохранение данных. Если код использует специфичные для Deno возможности, запишите их отдельно и определите, чем они будут обеспечены на целевой платформе. Это редакционная рекомендация по подготовке переноса, а не утверждение о наличии готового конвертера.

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

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

Практический план для проекта на Deno Deploy

Предлагаем разбить подготовку на четыре этапа:

1. Инвентаризация. Перечислите проекты в Deploy, ответственных, используемые домены, хранилища, интеграции и процедуру выпуска. Выделите сервисы, от которых зависят пользователи или бизнес-процессы.
2. Пробный перенос. Возьмите небольшой сервис и разверните тестовую копию на выбранной платформе. Запишите необходимые изменения и проверьте основные сценарии.
3. Подготовка переключения. Опишите перенос данных и настроек, проверки после запуска и условия возврата к прежнему варианту. Оцените время на исправление найденных проблем.
4. Перенос и наблюдение. Выполните переключение в согласованное окно, проверьте доступность, ошибки и работу интеграций. Обновите инструкцию поддержки.

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

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

Что это означает для новых проектов

При выборе платформы теперь нужно учитывать объявленный жизненный цикл продуктов. Для существующего приложения полезно проверить, сколько работы потребует альтернативный вариант. Для нового — оценить, какие части завязаны на конкретный runtime или управляемый сервис и как будут переноситься данные.

Это не повод менять всю инфраструктуру за выходные. Сегодняшнее действие — выяснить, затрагивает ли анонс ваш проект, назначить ответственного и начать тестирование там, где нужен перенос. Переход команды Deno в Cloudflare уже подтверждён, а пригодность новой архитектуры для каждой системы предстоит проверить на её собственных задачах.