Cloudflare Workersの心臓部をセルフホスト！JavaScript/Wasmサーバーランタイム — workerd

アーキテクチャ・仕組み

• Cloudflare Workersの本番環境と同一のコードベースから構築されたJavaScript/Wasmランタイム
• 内部的にはV8エンジン（Google ChromeのJavaScriptエンジン）を使用
• 設定ファイルはCap'n Protoテキスト形式で記述
• 「ナノサービス」アーキテクチャ：複数のサービスを同一スレッド・プロセス内で実行し、関数呼び出し並みのパフォーマンスで通信
• 「Capability bindings（ケイパビリティバインディング）」により、グローバル名前空間ではなくケイパビリティベースでリソースを接続。SSRF攻撃（サーバー側リクエスト偽造）を構造的に防止

対応環境・プラットフォーム

• Linux: x86-64 / arm64（glibc 2.35以上）
• macOS: x86-64 / arm64（macOS 13.5以上、Xcode Command Line Tools必要）
• Windows: x86-64
• CPU要件: x86_64はSSE4.2とCLMUL拡張、arm64はCRC拡張（armv8.1-a以降はデフォルト有効）

ビルド要件

高性能ビルド（Thin LTO有効）:

bazel build --config=thin-lto //src/workerd/server:workerd

主要な機能・用途

• アプリケーションサーバー: Cloudflare Workers向けアプリのセルフホスト
• 開発ツール: ローカル開発・テスト（Wrangler v3.0以上と連携可能）
• プログラム可能なHTTPプロキシ: フォワード/リバースプロキシとしてリクエストの傍受・加工・ルーティング
• Web標準API: fetch()などのWeb Platform Standards準拠のAPI
• 互換性日付システム: バージョン番号が日付で、過去の日付を指定するとその時点のAPIを忠実に再現

本番運用

• systemdとの統合が推奨されており、--socket-fdフラグで親プロセスからソケットを継承可能
• 特権ポート（80/443）をsystemdのソケットユニットで開き、workerd自体は非特権ユーザー（nobody）で実行可能
• クラッシュ時の自動再起動、NoNewPrivilegesによるセキュリティ強化が設定例として提供

セキュリティに関する注意点

• workerd単体ではサンドボックスとしての防御は十分ではない
• 信頼できないコードを実行する場合は、仮想マシンなど追加のセキュリティレイヤーが必要
• Cloudflare本番環境では多層防御を実装済み
• セキュリティバグはCloudflareのバグバウンティプログラム（HackerOne）で報奨金対象

配布方法

• プリビルドバイナリはnpm経由で配布（npx workerdで実行可能）
• ソースからのビルドはBazelを使用

ライセンス

• Cloudflareが管理するオープンソースプロジェクト（GitHubリポジトリで公開）

npm経由で実行する場合（最も手軽）

npx workerd serve my-config.capnp

ソースからビルドする場合

1. Bazelisk（推奨）をインストール
2. Linux: clang-19以上、libc++-19以上、lld-19以上、python3、tcl8.6を用意
3. macOS: Xcode 16.3、Homebrew経由のtcl-tkを用意
4. ビルド実行:

bazel build //src/workerd/server:workerd

リリースモードでビルド:

bazel build //src/workerd/server:workerd --config=release

簡単なHello World設定ファイル例

hello.js:

addEventListener("fetch", event => {
  event.respondWith(new Response("Hello World"));
});

実行:

workerd serve my-config.capnp