Deno Deploy закрывается: как проверить сайт и автоматизации бизнеса

У хостинга и среды исполнения разные сроки

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

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

Cloudflare также описала будущую совместную работу над самостоятельным размещением workerd и celld. Это направление развития, а не подтверждение готового способа переноса вашего проекта. Для действующего бизнеса сначала важны место исполнения кода, хранение данных и проверенная замена зависимостей.

Как понять, затронут ли ваш бизнес

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

Обратное предположение тоже опасно: «у нас Node.js, значит, это нас не касается». Документация Deno прямо описывает поддержку в Deploy как Deno-, так и Node-приложений. Название языка, фреймворка или среды исполнения не заменяет подтверждение хостинга.

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

Какие доказательства нужны от подрядчика

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

1. Проект и рабочая среда. Название организации и проекта в панели размещения, назначение среды и подтверждение, что именно она обслуживает реальный трафик. Тестовый проект рядом с рабочим нужно обозначить отдельно.
2. Версия и способ выпуска. Репозиторий или переданный исходный код, версия действующего выпуска и процедура его повторной сборки. Уточните, что компания сможет делать при недоступности прежнего исполнителя.
3. Пути обращения. Домен, служебные адреса и вызывающие их системы. Попросите показать один разрешённый тест от входа до результата. Успешное открытие главной страницы не устанавливает, где обработалась форма.
4. Состояние вне кода. Где находятся база, файлы, ключи состояния, расписания и настройки внешних подключений; что принадлежит хостингу, а что уже находится в отдельном сервисе.
5. Контроль со стороны бизнеса. Кто уполномочен управлять размещением, доменом, оплатой и исходниками. В общий реестр включайте владельцев и порядок получения доступа, без паролей, токенов и секретных значений.

Уточните версию продукта в старых материалах. В документации Deploy встречается отдельное уведомление о прекращении Deploy Classic и Subhosting v1 с датой 20 июля 2026 года. Оно не задаёт срок нового октябрьского объявления. Инструкция перехода между поколениями Deploy также не подтверждает перенос в Workers.

Учебный пример: витрина остаётся, обработчик заявок переезжает

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

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

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

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

Почему работающий TypeScript ещё не доказывает готовность Workers

При выборе Workers попросите исполнителя проверить реальные зависимости приложения, а не только успешную сборку. В описании совместимости Node.js есть поддерживаемые, частично поддерживаемые и нефункциональные модули-заглушки. Последние можно импортировать, хотя нужного рабочего API у них нет. Проверка должна доходить до использования функции в вашем сценарии.

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

Состояние приложения требует своего решения: где будут жить данные, какие операции нужны и что произойдёт с ожидающими обработки событиями. Не принимайте совпадение слов «KV» или «очередь» за подтверждение одинаковых правил работы и готового переноса. Попросите показать выбранный способ на ограниченном тестовом наборе.

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

Как согласовать цену и внутренний срок

У платного плана Workers указан минимум 5 USD в месяц за аккаунт. Standard включает 10 млн запросов и 30 млн миллисекунд CPU за месяц; превышение стоит соответственно 0,30 USD за миллион запросов и 0,02 USD за миллион миллисекунд CPU. Хранение и связанные сервисы имеют собственные единицы учёта. Это параметры тарифа на дату проверки, а не оценка переноса вашего приложения.

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

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

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

Что подтвердит устранение зависимости

• Нужное действие обрабатывается на выбранной площадке, и в журнале виден именно новый исполнитель.
• Проверенный выпуск можно повторно развернуть без обращения к закрывающемуся Deploy.
• Задания по расписанию имеют подтверждённый новый путь запуска; сохранённое в исходниках расписание не считается таким подтверждением.
• Все сохраняющиеся обращения к Deploy перечислены явно и считаются незавершённой частью переноса. Изменения runtime оцениваются отдельно от выхода из хостинга.

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

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

Автор: редакция SABSUS. Первоисточники проверены 11 октября 2026 года UTC. Повод — объявления Deno и Cloudflare от 9 октября. Реестр проверки и пример сервисной компании — редакционные рекомендации, не описание клиентского внедрения. SABSUS не проводила перенос и измерения приложения для этого материала.