Deno Deployの代替サービス比較：料金と移行作業で選ぶ移行先

Deno Deployの代替を検討するなら、最初の候補はCloudflare Workersです。Denoが移行先として挙げており、Deployは今後6か月間稼働するとしています。Denoベースのエッジ処理を使うサイトにはNetlify、データベースを使うAPIにはSupabase Edge Functions、フレームワークを軸に構築したアプリにはVercel Functions、小規模な定期実行ジョブにはVal Townが候補になります。Deno KVを使っている場合は、関数の実行先を決める前に、まずデータの移行先を選んでください。

料金とドキュメントの確認日は2026年10月12日です。本記事は公開料金、ランタイムの仕様、移行に必要な作業を比較したもので、ログインしてデプロイを試した結果ではありません。サービス終了までの期間は、Denoの10月9日の発表に基づいています。

Deno Deployの代替サービスを料金と用途で比較

移行先は、アプリの動作を維持でき、移行後も保守し続ける変更が最小限で済むものを選びます。外部データベースを呼び出すTypeScriptのエンドポイントと、トランザクション、スケジュール、キューをすべてDeno Deploy内に持つアプリでは、必要な移行作業が異なります。

各プランの情報源は、Cloudflare、Netlify、Supabase、Vercel、Val Townとその請求に関するFAQ、DigitalOceanのVPS料金表です。いずれも利用を始める際の料金であり、月額の総支払額を保証するものではありません。

Denoは何を発表し、終了までの期間をどう示したのか

Deno Deployはサービスを終了しますが、Denoランタイムの保守期間はそれとは別です。2026年10月9日の発表で、Ryan Dahlは次のように述べています。

Deno Deployは今後6か月間稼働を続け、その後終了します。

同じ発表では、Cloudflare Workersへ移行する有料顧客への支援を約束しています。また、Denoランタイムはバグ修正とセキュリティ更新を含む月次リリースを今後1年間続け、その後Denoによる開発を終了するとしています。ランタイム自体は引き続きオープンソースです。JavaScriptとTypeScriptのパッケージレジストリであるJSRは、インフラをCloudflareへ移し、運営を継続します。Denoの発表を読む。

Denoが示したのは終了までの期間であり、具体的な終了日ではありません。 発表から独自の締め切り日を作ったり、ランタイムの保守期間が長いことをDeployの利用猶予と取り違えたりしないようにしてください。有料顧客は移行支援を活用し、アプリとデータの移行を一緒に計画するのがよいでしょう。

1. Cloudflare Workers：最初に検討したい移行先

Cloudflare Workersは、リクエストハンドラーやバックグラウンド処理を実行するマネージドプラットフォームです。Denoが顧客に明示的に案内しているため、まず検討する候補として最も有力です。TypeScript API、外部データベース、定期的なクリーンアップ処理で事業を運営しているなら、主な作業はランタイムに依存する部分とデプロイ設定の変更です。一方、Deno KVを中心に作られたアプリでは、ストレージを別途設計し直す必要があります。移行先の基盤としてWorkersを選ぶ場合も、そのままでは動かないDeno固有の部分にかかる作業を予算へ織り込んでください。

向いている用途： マネージドインフラを活用したいAPI、Webhook、cronジョブ、キュー、サイト。
特徴： Denoが挙げた移行先であり、移行先のプラットフォームにストレージとスケジュール実行のサービスがそろっています。
料金： Workers Freeを用意。Workers Paidはアカウントごとに最低$5 USD/月で、Enterpriseの利用料金は契約に従います。
無料での試用： 継続利用できるWorkers Freeで評価できます。
移行の負担： ステートレスなハンドラーなら低〜中。KVのトランザクションやキュー処理の再設計が必要なら高。

TypeScriptコードのどこを変更する必要があるか

Workersが使うのはworkerdランタイムで、Denoランタイムではありません。グローバルなDeno名前空間も提供されません。Request、Response、fetchなどの標準Webインターフェースは移植の足掛かりになりますが、Deno.serve、Deno.env、Deno.openKv、Deno.cronを使う箇所は置き換えが必要です。Node.jsとの互換性もAPIの一部に限られるため、開発中にパッケージをインポートできただけでは、その実行時依存関係まで動作するとは判断できません。WorkersのランタイムAPI。

WranglerはCloudflareのデプロイ用コマンドラインツールです。Deno公式のWranglerチュートリアルでは、Denoを開発ツールチェーンとして使い続ける方法を紹介しています。npm:wranglerを追加し、Workersの型を生成し、fetchハンドラーを持つモジュールをエクスポートします。Deno方式のモジュール解決が必要な場合は、Denoプラグインを組み込んだesbuildでバンドルします。アップロードするコードをDenoでビルドしても、デプロイ後のWorkerがDenoプロセスになるわけではありません。

シークレットとリソースへのアクセスはバインディングへ移します。バインディングとは、Workerからデータベース、キュー、環境変数などへアクセスするために設定する参照先です。アプリのファイルだけでなく、依存ライブラリも確認してください。ルートハンドラーがWeb APIしか使っていなくても、内部のユーティリティーがファイルシステムを呼び出している場合があります。Cloudflareのバインディング。

サービス名ではなく動作に合わせて置き換える

特に重要なのは、Workers KVとDeno KVの違いです。Workers KVは読み取りが多く、書き込みが比較的少ない用途に向いており、キャッシュから古い値が返ることがあります。在庫の引き当て、口座残高、アトミックな一意性チェックを、名前が似ているという理由だけで移さないでください。Workers KVの仕組み。

SQLへ移すならD1が候補です。キーのプレフィックスやセカンダリインデックスを、明確なスキーマへ落とし込みます。D1のバッチAPIは文をトランザクションとして実行しますが、Denoの楽観的なチェックが自動的に移植されるわけではありません。状態と調整役となる実行インスタンスを組み合わせるDurable Objectsは、ルームやアカウントなど、エンティティー単位で処理を直列化する必要がある場合に検討できます。D1のトランザクション、Durable Objects。

定期実行には、scheduledハンドラーとUTCのスケジュールを使うCron Triggersがあります。後で処理する仕事を渡すには、メッセージングを担うQueuesを使います。スケジュールは開始時刻を定め、キューは処理待ちの仕事を保持します。どちらか一方を置き換えても、もう一方の移行にはなりません。静的サイトにはWorkers Static Assetsを使い、生成済みファイルと動的なリクエスト処理を分けられます。

料金と実行制限を確認する

Workers Freeには1日100,000リクエストと呼び出しごとにCPU時間10 msが含まれます。Paidには月あたり1,000万リクエストとCPU時間3,000万ミリ秒が含まれ、超過分は100万リクエストごとに$0.30、CPU時間100万ミリ秒ごとに$0.02です。データベース、キュー、その他の製品の利用料金も別途計算する必要があります。Workersの現行料金。

バンドルサイズだけを理由にPaidを選ぶ必要は、もはやありません。FreeもPaidも非圧縮で64 MiBまで対応し、メモリは引き続き128 MBです。現在の上限と、バンドルサイズを理由とするアップグレードの解説を確認してください。アカウント内の各製品の位置付けは、Cloudflareのレビューで詳しく説明しています。

1. 1

   ランタイムに依存する箇所を洗い出す

   Deno名前空間の呼び出し、URLインポート、ファイルシステムへのアクセス、シークレット、KV操作、スケジュール、キューのコンシューマーを探します。移植可能なビジネスロジックを、これらの接続部分から分離してください。

2. 2

   Worker形式のエントリーポイントを用意する

   DenoのWranglerチュートリアルに沿って、モジュールハンドラーと生成されたWorkersの型を設定します。インポート方式に応じて、Denoに対応したカスタムビルドも構成してください。ハンドラーの呼び出し方を変えても、既存のレスポンス仕様は維持します。

3. 3

   状態の保存先とトリガーを設計して用意する

   レコードを取り込む前にデータベースを選びます。バインディングを追加し、スケジュールをCron Triggersへ割り当て、キューの送信側と受信側を書き換えてください。同じジョブが再配信された場合の動作も文書化します。

4. 4

   トラフィックを切り替える前にリハーサルする

   ローカルのテストデータと独立した移行先環境を使い、ステータスコード、ヘッダー、認証、状態の変化を比較します。コードのデプロイは確認事項の一部です。データとバックグラウンド処理も、同じ切り替えに間に合うよう準備する必要があります。

2. Netlify：Denoベースのエッジ処理を使うサイト向け

Netlifyは、DenoベースのEdge Functionsを備えたWebサイトのデプロイ基盤です。ローカライズ、認証チェック、リダイレクト、軽量なパーソナライズなど、受信リクエストに応じて動的な処理を行うサイトに向いています。新しいインフラの構成を採用するよりも、こうした処理をサイトのデプロイプレビューと一緒に管理できることに価値がある場合があります。ステートレスなエッジハンドラーなら移行しやすい候補ですが、キュー処理が中心のバックエンドでは、より多くの機能を切り離す必要があります。Webサイト自体がプロダクトで、エッジ処理がそれを支える構成なら、Netlifyが適しています。 Edge Functionsの概要。

向いている用途： 軽量なDenoベースのリクエスト処理を使う静的サイトやWebアプリ。
特徴： Edge Functionsをサイトと一緒にデプロイでき、プレビューとロールバックも利用できます。
料金： Freeは期限なく$0、Personalは**$9/月**、Proは**$20/月でメンバー数無制限**、Enterpriseは個別見積もりです。
無料での試用： Freeの上限は月300クレジットです。
移行の負担： サイトとステートレスなエッジ処理なら低〜中。ストレージ、スケジュール、キューのコンシューマーを切り離す必要があると負担が増します。

ランタイムが似ていても、アプリ側の実装は変わる

Edge Functionでは、Netlifyのハンドラーとコンテキストを使います。インポートの確認も必要です。Netlifyのドキュメントでは、deno.json内のインポートマップではなく、独立したインポートマップファイルを使うと説明しており、npmパッケージへの対応はベータとされています。現在Denoの設定に依存関係の解決を任せているプロジェクトでは、具体的な移行作業になります。Edge Functions API。

実行制限はリクエストごとにCPU時間50 msで、レスポンスヘッダーのタイムアウトは40秒です。外部サービスの応答を待つ処理と、大きなドキュメントを変換する処理では、消費する実行枠が異なります。認証情報の照会は軽量なエッジ処理に収まる可能性がありますが、CPU負荷の高い処理は別の実行先を検討すべきです。Edge Functionの制限。

Deno KV、cron、キューは何に置き換えるか

キーで取得するコンテンツには、要件が合えばNetlify Blobsを使えます。リレーショナルデータやトランザクションによる更新が必要なら、PostgresサービスのNetlify Databaseが候補です。Blobsはオプションで強い整合性の読み取りに対応しますが、それだけでDeno KVの複数キーをアトミックに操作するAPIを再現できるわけではありません。ユーザー名の重複防止など、業務上必ず守るべき条件を、移行先のストレージ設計でも維持してください。

Scheduled Functionsは、Netlify Functions側の別機能です。Edge FunctionにDeno.cronが含まれていても、マネージドな定期実行へ自動的に引き継がれるわけではありません。タスクを切り出し、スケジュールを設定し、実行するランタイムも別途確認します。元のタスクがDeno KVのキューを消費しているなら、メッセージを永続化する保存先とコンシューマーを明確にしてください。関数を定期実行するだけでは、キュー内のメッセージは移行されません。

コンテンツサイトと毎時の同期タスクを運営している場合、この分離は十分管理できるでしょう。サイト配信とパーソナライズをWeb基盤に任せ、同期処理には専用の定期実行関数と永続的な状態の保存先を用意します。一方、アプリの大部分が相互に依存するバックグラウンドワーカーで構成されている場合は、魅力が薄れます。

クレジットとチーム構成から費用を計算する

Personalには月1,000クレジットが含まれます。Proの月額クレジット枠は、3,000クレジットで$20、5,000で$33、10,000で$63、15,000で$95、20,000で$126です。5,000クレジット以上の上位枠では、その月に使わなかったクレジットを次の請求期間へ繰り越せますが、基本枠では繰り越せません。Netlifyの現行クレジット枠。

自動チャージは初期状態でオフです。有効にすると、Personalは**$5で500クレジット**、Proは**$10で1,500クレジット**を追加できます。追加せずにアカウントの利用枠を使い切ると、プロジェクトが一時停止することがあります。公開時にはデプロイの判断と併せて、支出の方針も決める必要があります。現在のクレジット制プランを、以前のNetlifyのシート課金と混同しないようにしてください。

3. Supabase Edge Functions：データベースを中心に動くAPI向け

Supabase Edge Functionsは、Deno互換ランタイム上で動作するTypeScript関数です。移行に合わせて、リレーショナルデータベースのPostgresへデータを移す方針なら、最も適した候補になります。決済Webhookを受け取り、顧客レコードを更新するサブスクリプション型アプリなどは、自然に適合する用途です。使い慣れたランタイムによって変更箇所を減らせる一方、データベース設計が移行作業の中心になります。永続的なアプリデータを軸にアーキテクチャを組むなら、Supabaseを選びます。 Functionsのドキュメント。

向いている用途： Postgres、認証、ファイルストレージと同じ基盤に置きたいWebhookやAPI。
特徴： データベース基盤と統合されたDeno互換の関数。
料金： Freeは**$0/月**、Proは**$25/月から**、Teamは**$599/月から**、Enterpriseは個別見積もりです。
無料での試用： Freeには、プロジェクトごとにEdge Function呼び出し500,000回と500 MBのデータベースが含まれます。
移行の負担： 互換性のあるハンドラーなら中。Deno KVをリレーショナルスキーマへ変換し、トランザクション処理を作り直す場合は高。

エンドポイントと一緒にデータモデルも移す

Deno KVの呼び出しをPostgresへのアクセスに置き換えます。たとえば、ユーザーの保存済み項目を表すプレフィックスは、クエリできるリレーションへ、一意性チェックはデータベース制約やトランザクションへ変換します。重要なクエリのたびに文字列を解析しなければならなくなるなら、取り込みが簡単に見えるという理由だけで、意味を読み取れないキー文字列の集合をそのまま残すべきではありません。

たとえば決済ハンドラーでは、イベントの記録と利用権限の更新を一緒に行う必要があるかもしれません。この場合の合格条件は、再試行しても利用権限を二重に付与しないことです。新しい関数が成功のHTTPレスポンスを返しただけでは、ストレージを書き換えた後もその条件が守られているとは証明できません。

Supabaseは、データベース処理やEdge Functionの呼び出しを実行できるCronと、Postgresを使ってメッセージを永続化するQueuesも提供しています。Deno.cronへの登録と、Deno KVのキューへの追加・消費処理を、これらのサービスへ明示的に置き換えます。メッセージの処理完了をどう通知するか、失敗したタスクをどう再試行の対象へ戻すかも決めてください。

ランタイムの制限と導入時の総額を把握する

Edge Functionsの上限はメモリ256 MB、リクエストごとにCPU時間2秒です。ワーカーの実経過時間の上限はFreeで150秒、有料プランで400秒ですが、存続時間が長くてもCPU時間の枠は増えません。別々の制限であり、長時間動作するワーカーの能力を同じ意味で表す数字ではありません。関数の制限。

ProとTeamには関数呼び出し200万回が含まれ、超過分は100万回ごとに$2です。Freeではアクティブなプロジェクトを2件利用でき、利用がないプロジェクトは1週間で一時停止します。有料プランには、Microインスタンスをまかなえる月$10のコンピュートクレジットが含まれます。Supabaseの料金。

サイトの静的フロントエンドを移す先としては、Supabaseの適性は下がります。関数の制限に関するドキュメントでは、HTMLの配信にはカスタムドメインが必要で、使わない場合はtext/htmlのレスポンスがtext/plainへ書き換えられるとされています。フロントエンドのホスティング先は、APIとは分けて選んでください。

4. Vercel Functions：Webフレームワークを軸に移行するアプリ向け

Vercel Functionsは、Webデプロイに組み込まれたマネージドのサーバー側関数です。フロントエンドのフレームワークやリリースの流れを主な理由として移行するアプリに向いています。すでにVercel対応のフレームワークを中心にアプリを組み直しているなら、APIルートもその構成へ移すのが合理的です。逆に、ほかの部分を変えずにDenoサービスだけを移したい場合は、直接的な移行先とはいえません。アプリの開発・運用フローを理由にVercelを選び、ランタイムとストレージの移植は明確に計画してください。

向いている用途： フレームワークを中心に構築し、フロントエンドとAPIルートを一緒に管理するWebアプリ。
特徴： サーバー側関数を含め、アプリを共通のワークフローでデプロイできます。
料金： Hobbyは**$0/月**、Proは**$20/月**、Enterpriseは個別見積もりです。
無料での試用： Proにはトライアルの案内があります。Hobbyは個人の非商用利用に限られます。
移行の負担： ランタイムとルートの変更なら中。ストレージとバックグラウンド処理も置き換える場合は高。

移植するか、コミュニティー版ランタイムでDenoを使うか

Vercelは公式対応のランタイムとしてNode.jsなどを挙げ、Denoについてはコミュニティー版ランタイムのvercel-denoを掲載しています。この選択によって保守の体制が変わります。期限に追われる移行では、本番稼働を支える依存先にする前に、コミュニティーによる連携機能の互換性と保守の担い手を確認してください。採用しない場合は、フレームワークが使う公式対応ランタイムへ、ハンドラーと依存ライブラリを移植します。Vercelのランタイムに関するドキュメント。

Deno KVについては、データベースを選んでAPIを置き換えます。Vercelのストレージガイドは、ファイル用のBlob、設定用のGlobal Config、アプリデータ用のMarketplace経由のデータベースを区別しています。便利なキーバリューのインターフェースに見えるという理由だけで、設定用ストアをトランザクションが必要な顧客レコードの標準的な保存先にしてはいけません。

Vercel Cronで置き換えられるのはスケジュールであり、Deno.cronによるコード内の登録処理がそのまま使えるわけではありません。Hobbyのジョブ実行は1日1回で、時刻の精度は1時間単位です。Proの最短間隔は1分に1回です。頻繁に同期するジョブなら、スケジュールの条件だけでもHobbyは候補から外れます。Cronの利用条件と料金。

Vercel Queuesは現在、全プランでベータ版を利用できます。永続化されたトピック、自動再試行、少なくとも1回の配信保証を備えています。Deno KVのキュー処理の移行先にはなりますが、送信側、受信側、処理完了の通知方法は引き続き書き換える必要があります。このキューが顧客の注文を履行する唯一の経路になるなら、ベータ版である点も判断に含めてください。

デプロイする人数が増えると料金も変わる

Proの基本料金には、デプロイ権限付きシート1席と毎月$20の利用クレジットが含まれます。有料シートの追加は1席あたり$20/月で、閲覧専用シートは無料です。クレジットを超える利用分と有料アドオンは別料金になります。Proの請求に関する詳細。

事業でDeno Deployから移行する場合、無料のHobbyを本番環境の予算にはできません。商用利用できるプランを出発点に、データベースとキューの要件を加えて見積もってください。安く見えた移行が、想定外の個別請求の積み重ねになるのを防げます。

5. Val Town：小規模なAPIと定期実行ジョブ向け

Val Townは、HTTP、メール、cronをトリガーに小さなプログラムを動かせるホスティング環境です。特定の仕事をこなす小規模なサービスによく合います。外部システムを更新するWebhook、社内ツールから使うAPI、定期配信のダイジェストなどが例です。Denoランタイムを使うため今回の移行先候補になりますが、ストレージとトリガーのインターフェースは異なります。運用すべき大きな基盤ではなく、コンパクトな自動化を作りたいなら、Val Townが適しています。 Val Townのドキュメント。

向いている用途： 小規模なAPI、Webhookハンドラー、定期的なシステム連携、社内向けユーティリティー。
特徴： トリガーとSQLiteストレージを備えたコード実行環境。
料金： Freeは**$0**、Proは年払いで月額$21、Businessは年払いで月額$167から、Enterpriseは個別見積もりです。公式FAQの月払い料金は、Proが$25、Businessが$200です。
無料での試用： Freeは継続利用できますが、カスタムドメインと非公開のvalには対応していません。
移行の負担： ステートレスなユーティリティーなら低。状態を保存する小さなジョブなら中。状態を持つ大きなアプリなら高。

請求期間の違いは重要です。年払いを選択した料金ページの金額を、毎月解約できる契約でも同じ料金であるかのように扱うべきではありません。Val TownのFAQでは月払いとの比較ができ、Denoランタイムを使っていることも確認できます。

移行が小さく済むのは、仕事自体が小さい場合

ハンドラーをvalへ移します。valは、Val Townでバージョン管理されるアプリのコンテナです。その呼び出しをHTTPまたはcronのトリガーへ対応付けます。外部APIを呼んでダイジェストを送るだけのジョブなら、永続化する状態は「最後に処理した項目」だけかもしれません。複数のトランザクション対象とキューのコンシューマーを持つ顧客向けアプリより、はるかに設計を把握しやすい構成です。

Deno KVは、要件に合えばVal TownのvalごとのSQLiteデータベースへ置き換えるか、外部データベースを使い続けます。キーによる取得とアトミックなチェックは、データベース操作へ書き換えてください。Deno.openKvが終了予定のホスト済みストアを参照したままでは、移行完了とはいえません。

キュー処理では、未処理のジョブを設計上明確に扱う必要があります。cronがジョブテーブルを定期的に走査する構成も考えられますが、ジョブの取得権の確保、再試行、重複処理への対応は自分で実装しなければなりません。Deno KVキューの動作が自動的に保たれるわけではありません。

実行頻度、非公開要件、実行時間でプランを選ぶ

Freeのcronの最短間隔は15分で、実経過時間の上限は実行ごとに1分です。Proでは間隔が1分、実行時間の上限が10分になります。料金カードにはカスタムドメイン10件と非公開のval 2,000件も記載されています。現行の料金と制限。

公開の日次ダイジェストならFreeで足りる可能性があります。一方、非公開の連携処理や、より頻繁なポーリングが必要なジョブは、アクセスがごく少なくても別のプランが必要です。ソースコードの非公開とエンドポイントへのアクセス制御も別の要件です。ソースを非公開にしただけでは、誰がHTTPエンドポイントを呼べるかは定まりません。

単純なトリガーで動くステートレスなユーティリティーなら移行の負担は低く、ジョブの永続的な状態も移すなら中、大きなアプリのランタイムとデータ構成を再現しようとするなら高くなります。これは作業範囲の評価であり、所要時間の見積もりではありません。

6. Denoのセルフホスティング：ランタイムの動作を維持したい場合

仮想専用サーバーであるVPS上でDenoを動かせば、ランタイムを維持しながら、ホスティングの責任を自分で引き受けられます。コンテナを使うと、ランタイムとアプリをまとめて、選んだホストで実行できます。ファイルシステムへのアクセス、Deno固有のAPI、長時間稼働するプロセスの動作が移植作業の大部分を占めるなら、検討する価値があります。ランタイムを維持することで省ける複雑さが、サーバー運用で増える複雑さを上回るなら、セルフホスティングを選びます。 DenoはDockerの公式ガイドを公開しています。

向いている用途： Denoへの依存が大きく、担当者がサーバーやコンテナのデプロイを管理できるアプリ。
特徴： ランタイム、ファイルシステム、プロセスのライフサイクルを制御できます。
料金： オープンソースのランタイム自体にマネージドホスティングのプランはありません。ホストの一例として、DigitalOceanのBasic Regular DropletはRAM 512 MiBで**$4.00/月**、1 GiBの構成は**$6.00/月**です。
無料での試用： DigitalOceanはプロモーション用クレジットに言及していますが、料金ページに継続利用できるDropletの無料枠はありません。
移行の負担： ランタイムの書き換えは減る一方、運用責任が増します。ホスト済みデータには、引き続きエクスポート、インポート、復旧の計画が必要です。

これらはVPSの掲載料金であり、あらゆるDenoアプリにこの構成を推奨するものではありません。バックアップ用ストレージ、監視、自分の運用時間も判断に含めてください。すでに所有しているサーバーなら新規のホスティング契約は不要かもしれませんが、保守作業は発生します。

Deno KVとcronはどうなるのか

Deno KVはローカルの永続的なデータベースパスを利用でき、CLIでは内部にSQLiteを使います。他社のストレージサービスへ移るより、KV APIを使うコードを多く残せる可能性があります。ただし、ホスト済みのレコードをコピーしたり、分散ホスティングを再現したり、一時的なコンテナのファイルシステムを永続化したりする機能ではありません。データをエクスポートして計画的に取り込み、永続ストレージをマウントしたうえで、バックアップから復元できることを確認してください。Deno KVのドキュメント。

スケジュール実行でも同じ区別が必要です。CLIのDeno.cronは実行状態をメモリに保持し、各プロセスが独立したタスク群を持ちます。アプリのレプリカを複数動かすなら、どれが定期ジョブを担当するか、または互いにどう調整するかを決めなければなりません。API呼び出しを変えずに残しても、Deployのマネージドなスケジュール実行サービスまで維持されるわけではありません。Denoのcronの動作。

単一サーバーで動く小さなアプリなら、この運用範囲を許容できるかもしれません。冗長化されたインフラが必要なのに、バックアップ、パッチ適用、復旧を誰も引き受けたがらない事業では、VPSの安い請求額がかえって高くつく遠回りになり得ます。

workerdとcelldは別系統のセルフホスティング

Cloudflareの発表では、現時点で利用できるセルフホスティングの選択肢としてworkerdとcelldを挙げています。これらはWorkersのプログラミングモデルを使うため、Workers形式へ移植した後の選択肢です。既存のDenoコードをすべて無変更で実行できるという意味ではありません。Cloudflareは、単体のworkerdにおけるDurable Objectsの実装には単一インスタンスを超えるスケーリングの課題があることも認め、celldの成果やアイデアをworkerdへ統合する方針を説明しています。Cloudflareの発表。

どちらも、架空の無料枠が付いた新しいマネージドサービスとして見積もるべきではありません。必要な予算は、自分たちが用意するインフラと運用の費用です。移行を急ぐチームは、現在使える機能と、自分たちで実行できる復旧計画を評価してください。将来の統合作業を、今必要な判断の代わりにはできません。

Denoのセルフホスティングは橋渡しとして使えますが、Denoが発表したサポート期間を踏まえると、ランタイムを長期的にどう保守するかも重要です。

プロジェクトで動かしている処理から移行先を選ぶ

移行で最も難しい対象がコードではなく状態になると、選ぶべき移行先も変わります。移行の負担は、具体的に必要となる変更で評価します。低は、外部にある状態の保存先を変えず、ハンドラーやビルドを調整する場合。中は、ランタイムとの接点やストレージAPIの書き換えが加わる場合。高は、トランザクションの再設計、キュー内の仕事の移送、新たな運用責任が加わる場合です。小さなアプリでも、正しく動くためにこれらの挙動へ依存しているなら、移行の負担は大きくなり得ます。

Deno固有のAPIを使わないTypeScript関数なら、Workersから検討します。 リクエストとレスポンスの仕様を保ち、エントリーポイントとデプロイ方法を調整します。関数がサイトへのリクエストを加工するならNetlify、主にデータベースを操作するならSupabaseの魅力が増します。周辺のフレームワーク自体が移行の理由なら、Vercelが有力です。どの移行先でも、ステートレスなハンドラーは一般に最も負担が小さいケースです。

Deno KVは、先にストレージのモデルを選びます。 読み取り中心のコンテンツならWorkers KVやNetlify Blobsが候補です。トランザクションが必要なレコードはD1、Postgres、または守るべき条件に合わせて設計できる別のデータベースを検討します。処理の協調が必要ならDurable Objectsが候補になります。小さなユーティリティーならVal TownのSQLiteだけで足りるかもしれません。セルフホストしたローカルKVはコードを多く残せますが、永続性と復旧の責任は自分に移ります。ホスト済みKVの移行は、トランザクションとインデックスを洗い出して負担が小さいと確認できるまでは、少なくとも中程度の作業として扱ってください。

cronは、実行条件を比較します。 日次レポートと頻繁なポーリングでは、必要なプランの条件が異なります。マネージドサービスではWorkers Cron Triggersを最初に検討し、小さなジョブにはVal Town、データベースの保守にはSupabase Cron、サイトに関連する処理にはNetlify Scheduled Functionsが適しています。Vercel Hobbyは日次実行の制限があるため、頻繁なジョブには使えません。スケジュールの再登録は小さな作業でも、重複実行による影響の防止は簡単とは限りません。

キューは、処理待ちの仕事とコンシューマーを一緒に移します。 Cloudflare QueuesとSupabase Queuesは明確な移行先で、Vercel Queuesもベータ版の選択肢になります。移行対象には、メッセージの識別、再試行、処理完了の通知、すでに待機しているジョブまで含まれます。タイマーだけでは置き換えられません。キュー内の仕事が有料顧客への履行義務を表すなら、負担の大きい移行として扱います。

静的サイトは、不要なサーバーコードを移植する前に、生成済みファイルを移します。 Workers Static AssetsとNetlifyが直接的な候補です。サイトのフレームワークがVercelのワークフローを生かせるなら、Vercelも候補に入ります。リダイレクト、ヘッダー、フォーム、認証、動的ルートはそれぞれ確認してください。単純な静的出力の移行は、リクエストごとにパーソナライズしたレスポンスを生成するサイトより負担が小さくなります。

アプリの動作を変えずにDeno KVを移行するには

コードのデプロイとデータ移行では、成功の条件が異なります。コードは正しい応答を返せれば成功ですが、データ移行では、その応答を正しくするためのレコードとルールが移行先でも保たれていなければなりません。

エクスポート前に、利用中のKV機能を洗い出します。型付きの複合キー、プレフィックス検索、有効期限、セカンダリインデックス、楽観的なバージョンチェック、アトミック更新、ウォッチャーが対象です。DenoのKVガイドを読むと、キーの集合が、単純なオブジェクトのダンプから想像する以上に多くのアプリの動作を担っていることが分かります。

ユーザー名のインデックスを例に考えると分かりやすくなります。ユーザーレコードと、ユーザー名からユーザーを探す参照データを保存している場合、両方のレコードをコピーするだけでは不十分です。新しい書き込み処理も、両者の関係を保ち、競合する更新を拒否する必要があります。同様に、セッションを失効させていたタイムスタンプには、移行先での明確な扱いが必要です。その動作を引き継がずに値だけ取り込むと、本来より長く有効なままになる可能性があります。

キューについては、移行元が情報を提供している範囲で、未処理、完了、失敗の仕事を分けて一覧化します。切り替え前に旧コンシューマーで処理し切るか、安全に再実行できる識別子を付けて移すかを決めてください。冪等性とは、タスクを繰り返しても業務上の効果が重複しない性質です。領収書の送信ジョブを再試行しても何通も送らず、注文履行のメッセージが再送されても二重に作業を起こさないために必要になります。

1. 1

   コピー中の書き込みをどう扱うか決める

   移行元をバックアップし、コピー中の書き込み方針を決めます。小さなアプリなら短時間の書き込み停止で対応できる場合があります。より複雑な同期方式を使うなら、差分の照合が必要です。エクスポートから切り替えまでの間に、同時進行の変更が気付かないまま消えないようにしてください。

2. 2

   レコードと動作の両方を検証する

   エンティティーの種類ごとの件数、代表的な値、キーのエンコードを比較します。制御されたテストデータを使い、重複送信、競合する更新、有効期限切れ、レコード欠落を試してください。新しいAPIが成功を返すかだけでなく、期待した業務上の結果になるかを確認します。

3. 3

   トラフィックとジョブの担当を一緒に切り替える

   移行先の状態が整ってからリクエストを切り替えます。両方の基盤で同じ処理結果を重複して発生させないよう、旧スケジュールとコンシューマーを無効化するか、担当を引き継ぎます。シークレットとWebhookの送信先も、意図どおりに再設定してください。

4. 4

   監視し、実際に使えるロールバック手段を残す

   変更後はエラー、失敗したジョブ、業務上のイベントを監視し、移行元のバックアップを保持します。移行先がすでに新しい書き込みを受け付けているなら、DNSを戻すだけではロールバックになりません。データの差分を照合し、整合させる計画が必要です。

次の作業では、最も移行が難しい状態を扱う処理を洗い出し、その移行先を決めてください。ほかの部分を仕上げる前に、その処理を移植します。ステートレスなヘルスチェック用エンドポイントをもう1つ移すより、多くのリスクを明らかにできます。

比較対象をどう選んだか

候補は、Deno Deploy上のアプリが担うHTTP関数、永続的な状態、定期タスク、キュー処理、静的出力を基準に選びました。Cloudflareを最初に挙げたのは、Denoが移行先として案内しているためです。Netlify、Supabase、Val TownはDenoベースの実行環境と、それぞれに適した用途、VercelはWebデプロイのワークフロー、セルフホスティングはランタイムの制御を理由に選んでいます。

料金と機能は、2026年10月12日に各提供元の公開ページで確認しています。移行の負担は、ドキュメントに記載されたインターフェースから必要となる変更を評価したものです。実測した移行時間や負荷テストの結果ではなく、ログインして試用したと主張するものでもありません。汎用クラウドサービスを候補に加えなかったのは、提供元の名前を増やしても、ランタイム、状態、ジョブの担当をどう移すかという中心的な判断は解決しないためです。

今回の移行で避けたい選び方

トランザクションを使うDeno KVを、機械的にWorkers KVへ置き換えるのは避けてください。 読み書きの動作がデータの要件に合う場合にだけ選びます。ストレージ料金が安くても、整合性の前提が崩れては意味がありません。

CPU負荷の高いバックグラウンド処理にNetlify Edge Functionsを使うのは避けてください。 エッジのリクエスト実行枠は設計の判断基準です。有料プランにすれば実行モデルも変わるだろうと期待して、制限を回避しようとするものではありません。

商用アプリの本番環境にVercel Hobbyを選ぶのは避けてください。 料金ページでは、個人の非商用利用に限定されています。cronにも制限があるため、頻繁なジョブ向けの無料プランとして比較するのも適切ではありません。

ソースコードを非公開にする必要があるなら、Val Town Freeは避けてください。 トラフィック量より先に、プランの利用条件を確認する必要があります。また、一般的な静的サイトの標準的な移行先としてSupabase Edge Functionsを選ぶのも避け、フロントエンドのホスティング先を意識して選んでください。

復旧の担当者がいない状態でセルフホスティングを選ぶのは避けてください。 プロセスを動かすこと自体は、比較的簡単な部分です。データを復元し、サービスを再起動し、障害後にどのスケジューラーが処理を担当しているか説明できる人が必要です。

移行前によくある疑問

Deno Deployはいつ終了しますか？

発表で示されているのは具体的な日付ではなく、6か月間の稼働期間です。その期間に基づいて計画し、より長いランタイムの保守期間と取り違えないでください。

Deno Deployを離れてもDenoは使い続けられますか？

はい。Netlify Edge Functions、Supabase Edge Functions、Val Townには、DenoベースまたはDeno互換の実行環境があります。VPSやコンテナでDenoを自分で動かすこともできます。ただし、各マネージドサービスには固有のAPIと制限があります。Denoを使い続けても、ホスト済みのKVデータベース、スケジュール、キューが自動的に維持されるわけではありません。

Deno KVをそのままCloudflare KVへ移せますか？

APIを変更し、アプリが必要とする整合性をWorkers KVで満たせると確認できる場合に限ります。Deno KVのアトミックなチェック、トランザクション、インデックス、ウォッチャーには、明確な代替実装が必要です。トランザクションが必要なレコードはD1などのデータベース、エンティティー単位で調整が必要な状態はDurable Objectsを検討してください。

cronジョブを動かせる無料プランはどれですか？

まず実行頻度、実行枠、ソースコードの非公開要件、商用利用の可否を照らし合わせます。Val Town Freeの最短間隔は15分、実行時間の上限は1分です。Vercel Hobbyは日次ジョブと個人の非商用利用に限られます。Workers FreeはCPU時間の枠が小さく、NetlifyとSupabaseにもそれぞれプラン内で共有する利用枠があります。スケジューラーが無料でも、ジョブ全体が無料枠に収まるとは限りません。