OpenWorkers – Rustで実装されたセルフホスティング可能なCloudflare Workers

 (openworkers.com)
19 ポイント 投稿者 GN⁺ 2026-01-02 | 1件のコメント | WhatsAppで共有
  • OpenWorkersは、V8ベースでJavaScriptを実行するオープンソースランタイムで、エッジコンピューティングを自社インフラ上で実現可能
  • KVストア、PostgreSQL、S3/R2互換ストレージ、サービスバインディング、環境変数とシークレットをサポート
  • fetch、ReadableStream、crypto.subtle など主要なWeb APIを含み、Cloudflare Workersとの高い互換性を維持
  • V8 Isolateサンドボックス、cronスケジューリング、Docker Composeベースのデプロイなどにより、簡単にセルフホスティング可能
  • 約7年にわたって発展してきたプロジェクトで、ベンダーロックインのないJavaScript実行環境を目指している

OpenWorkers 概要

  • OpenWorkersは、Rustで書かれたCloudflare Workers互換ランタイムで、V8 Isolateを利用してJavaScriptを実行
    • エッジコンピューティングの利点を自前のサーバー環境でも活用可能
    • オープンソースとして公開されており、自由に配布・改変可能

主な機能

  • **バインディング（Bindings）**機能を通じて、さまざまな外部リソースと連携
    • KVストレージ: get, put, delete, list をサポート
    • PostgreSQLデータベース連携
    • S3/R2互換ストレージをサポート
    • サービスバインディング、環境変数およびシークレット管理を含む
  • Web APIサポート
    • fetch、Request、Response、ReadableStream などの標準APIを提供
    • crypto.subtle、TextEncoder/Decoder、Blob、setTimeout、AbortController を含む

アーキテクチャ

  • システムはnginxプロキシ、ダッシュボード、API、ログサービス、ランナー（runner）、PostgreSQL、NATS、スケジューラなどで構成
    • 各ランナーはV8 Isolate内でコードを実行し、CPU 100ms、メモリ 128MBの制限を適用
    • 5〜6フィールドのcron構文をサポートする内蔵スケジューラを含む
    • Cloudflare Workersとの構文互換性を維持

セルフホスティング

  • デプロイは単一のPostgreSQLデータベースとDocker Composeファイルだけで可能
    • git clone、.env設定、docker compose up コマンドで簡単に起動可能
    • マイグレーションおよびトークン生成手順を含む

開発の背景

  • 約7年間の開発過程を経て完成したプロジェクト
    • 初期にはvm2でJSサンドボックスを実験し、その後Cloudflare Workersモデルに着想を得て発展
    • Deno-coreを経て、現在はrusty_v8ベースへと書き直された
  • 目標は、**Cloudflare Workersレベルの開発体験（DX）**を提供しつつ、ベンダーロックインを排した自前サーバー実行環境を構築すること
  • 今後は実行履歴と再生機能による**決定的デバッグ（deterministic debugging）**機能の追加を予定

関連記事

1件のコメント

 
GN⁺ 2026-01-02
Hacker Newsのコメント

  • エッジコンピューティングの力を自前インフラに持ち込むという発想は興味深い。
    ただ、セルフホスティングはエッジコンピューティングの本質とはやや相反するようにも感じる。
    Cloudflareのような大手ベンダーが世界中に300以上のPoP（Point of Presence）を持っているからこそ成立するモデルだ。
    もちろん、より小規模で倫理的なベンダーを組み合わせて似た構成を作ることはできるが、はるかに多くの労力とリスクを伴う。

    • エッジモデルの利点を得るのに、本当に300のPoPが必要なのかは疑問。
      主要地域に10か所程度あれば十分ではないかと思う。
    • Cloudflareの独占を崩すために、分散型ホストネットワークが協調するモデルが可能なのか気になる。
      ただし、安全かつ信頼性高く調整するのは難しすぎるのではないかという懸念もある。

  • サンドボックスソリューションの問題は、コードがサンドボックスを脱出できないという強力な保証をしなければならない点にある。
    それを証明するには、さまざまな攻撃シナリオに対するテスト結果と詳細な文書が必要だ。
    しかし、そのレベルの文書は非常にまれで、実際に信頼できる例を見つけるのは難しい。
    だから私は、大企業が実運用環境で使っていて、セキュリティチームが保守している事例があるかどうかを確認する。

    • 私も同意する。AIが生産性を上げるのは確かだが、高セキュリティ環境で「Claudeの助けを借りてrusty_v8上に書き直した」と言われると、むしろ不安になる。
    • Cloudflare Workersランタイムが安全である理由の1つは、V8メインラインとの同期を非常に積極的に維持していること。
      Chromeより先にV8リリースを適用することさえある。
    • V8 isolateはメモリ分離を提供し、CPU（100ms）とメモリ（128MB）の制限を設けている。
      各ワーカーは別プロセスではなくisolateとして実行され、Cloudflareのモデルに近い。
      ただし、完全に信頼できないサードパーティコードを扱う場合は、コンテナやVMでさらに一段隔離するのが望ましい。
      このサンドボックスはセキュリティというより、リソース分離に重点が置かれている。
    • そんな完璧な保証を求めるのは非現実的だと思う。
      「私たちが検証したので安全です、信じてください」レベルのセキュリティ監査では不十分だ。
    • Cloudflareではユーザーコードが悪意を持つ可能性があるためサンドボックスの安全性が必須だが、
      セルフホスティング環境ではすでにシステムへのアクセス権があるので、サンドボックス脱出を心配する必要は比較的少ない。

  • すばらしいプロジェクトだと思う。
    workerdがオープンソースなら、OpenWorkersの差別化ポイントは完全な環境を提供する点なのか気になる。
    ランタイム自体の違いや、今後マネージドサービスの予定があるのかも知りたい。

    • 主な違いは3つある。
      1️⃣ workerdはランタイムのみを提供するが、OpenWorkersは**ダッシュボード、API、スケジューラ、ログ、バインディング（KV、S3/R2、Postgres）**まで含む完全なプラットフォーム。
      2️⃣ workerdはC++ベース、OpenWorkersはRust + rusty_v8ベースで、よりシンプルでハックしやすい。
      3️⃣ すでにdash.openworkers.comにマネージド版があり、無料ティアもある。
      ただし、セルフホスティングを第一級市民として設計している。

  • Cloudflare Workersの核心は関数単位の課金だが、セルフホスティングだと結局ハードウェアを事前に確保する必要がある。

    • 今でも多くの企業が自社データセンターのサーバーを運用している。
      すべてを外部委託する必要はなく、似たような選択肢が存在するのは良いことだ。
      こうしたオプションは導入障壁を下げる助けになる。

  • 以前、deno_coreを切り出す作業をかなりやっていたので、raw rusty_v8へ移行したのは理解できる。
    deno_coreにはレガシーコードが多く、修正するとテストが頻繁に壊れた。

    • ありがとう！ deno_coreは今でもすばらしいコードベースなので、openworkers-runtime-denoとして維持している。
      ただ、ランタイム内部をより細かく制御するためにrusty_v8へ移行した。
      そして後でdenoランタイムにも不足している機能を再追加する予定だ。

  • ベンダーロックインの軽減を助けるプロジェクトなら無条件で賛成。
    クラウドサービスが価格を現実的な水準にするよう圧力がかかってほしい。
    今はNATのような基本機能にまで過剰な料金を課している。
    もちろんクラウドは便利だが、DIYと比べた高コストが問題だ。

    • Cloudflare Workersランタイムはすでにオープンソース: cloudflare/workerd
    • 最近のRAM価格上昇で、セルフホスティングがさらに難しくならないか心配。
      大企業が資源を独占すれば、個人が自分でホスティングするのは難しくなるかもしれない。
    • NATコストが「無料より高い」という表現は興味深い。
      ただ実際には、多くの国で自前運用のほうがコストは高い。
      導入して終わりではなく、保守要員や監視のコストがかなりかかる。

  • 現在動作しない機能やロードマップをドキュメントに明記するとよいと思う。

    • 良い提案です！ まだ実装されていない機能はDurable Objects、WebSockets、HTMLRewriter、cache APIです。
      次の優先事項はデバッグ用の実行記録/再生機能で、ドキュメントにロードマップのセクションも追加する予定です。

  • ASCIIアーキテクチャ図がPixel + Firefoxで崩れて見える。
    テキストベースの図は魅力的だが、実際には画像にコンパイルした版を公開するほうが実用的だ。

    • 報告ありがとう！ モバイル向けに簡略化したASCII版を追加して修正した。
    • 私のiPhone 11のSafariでは完璧にレンダリングされる。

  • 技術的にも構造的にも優れた製品アイデアだ。
    特に、大手ベンダーのオープンソースプロジェクトに対して、逆にオープンソースで返すモデルが気に入った。
    つまり、彼らがオープンソースを持ち帰って商用化する代わりに、私たちは彼らのモデルをオープンソースに戻すということだ — まさにこういうアプローチが正しいと思う。

  • 「クラウドを自分たちのコンピュータで直接ホストしたらどうだろう？」という流れがまた戻ってきたように見える。
    最近こうしたセルフホスティングのトレンドをあちこちで見かける。
    関連する発表動画も興味深い。

    • でも、それはもはや「クラウド」と呼ぶのは難しいと思う。
      クラウドの本質は**弾力性（elasticity）**にある。
      必要に応じてインスタンスを増減し、使った分だけ支払う仕組みだ。
      セルフホスティングはデプロイツールこそ便利でも、結局はサーバー全体のコストを負担しなければならない。
      負荷が一定または予測可能なら問題ないが、そうでなければ非効率だ。
      （たとえるなら、バスに乗るのとバンを所有する違いのようなもの。）
    • FaaS（Function-as-a-Service）の価値は、「クラウド」という言葉そのものよりイベント中心のフレームワークを提供することにある。
      開発者はイベントハンドラの実装に集中でき、キューや耐久実行まで含めればさらに強力になる。
      結局のところFaaSは、ボイラープレートコードを抽象化してくれる高水準ツールだ。