設定

Wrangler はオプションで wrangler.toml 設定ファイルを使用して、Worker の開発およびデプロイメント設定をカスタマイズします。

wrangler.toml を Worker の設定の真実のソースとして扱うことがベストプラクティスです。

サンプル `wrangler.toml` 設定

# トップレベルの設定
name = "my-worker"
main = "src/index.js"
compatibility_date = "2022-07-12"

workers_dev = false
route = { pattern = "example.org/*", zone_name = "example.org" }

kv_namespaces = [
  { binding = "<MY_NAMESPACE>", id = "<KV_ID>" }
]

[env.staging]
name = "my-worker-staging"
route = { pattern = "staging.example.org/*", zone_name = "example.org" }

kv_namespaces = [
  { binding = "<MY_NAMESPACE>", id = "<STAGING_KV_ID>" }
]

環境

Worker の設定は、異なる環境を定義すると複雑になる可能性があり、各環境には独自の設定があります。デフォルトの（トップレベルの）環境と、環境固有の設定を提供する名前付き環境があります。

これらは [env.name] キーの下に定義されており、例えば [env.staging] のように、wrangler コマンドで -e / --env フラグを使用してプレビューまたはデプロイできます。例えば npx wrangler deploy --env staging のように。

ほとんどのキーは継承可能であり、トップレベルの設定を環境で使用できます。バインディング、例えば vars や kv_namespaces は継承できず、明示的に定義する必要があります。

さらに、トップレベルにのみ現れるキーがいくつかあります。

トップレベル専用キー

トップレベルのキーは Worker 全体に適用され（したがってすべての環境に）、名前付き環境内で定義することはできません。

keep_vars boolean optional
- デプロイ時にダッシュボードで設定された変数を Wrangler が保持するかどうか。真実のソースを参照してください。
send_metrics boolean optional
- Wrangler がこのプロジェクトの使用状況メトリクスを Cloudflare に送信するかどうか。
site object optional
- 詳細については、下記の Workers Sites セクションを参照してください。このアプローチよりも Cloudflare Pages が推奨されます。

継承可能なキー

継承可能なキーはトップレベルで設定可能であり、環境固有の設定によって継承（または上書き）できます。

name string required
- Worker の名前。英数字（a,b,c など）とダッシュ（-）のみ使用可能。アンダースコア（_）は使用しないでください。
main string required
- 実行される Worker のエントリポイントへのパス。例えば: ./src/index.ts。
compatibility_date string required
- yyyy-mm-dd 形式の日付で、使用される Workers ランタイムのバージョンを決定するために使用されます。互換性の日付を参照してください。
account_id string optional
- ゾーンに関連付けられたアカウントの ID です。複数のアカウントを持っている場合があるため、提供するゾーン/ルートに関連付けられたアカウントの ID を使用してください。また、CLOUDFLARE_ACCOUNT_ID 環境変数を通じて指定することもできます。
compatibility_flags string[] optional
- Workers ランタイムの今後の機能を有効にするフラグのリストで、通常は compatibility_date と一緒に使用されます。互換性の日付を参照してください。
workers_dev boolean optional
- *.workers.dev サブドメインを使用して Worker をテストおよびデプロイすることを有効にします。scheduled イベント専用の Worker がある場合は、これを false に設定できます。デフォルトは true です。
route Route optional
- Worker をデプロイするルート。routes または route のいずれか一方が必要です。ルートの種類を参照してください。
routes Route[] optional
- Worker をデプロイするルートの配列。routes または route のいずれか一方が必要です。ルートの種類を参照してください。
tsconfig string optional
- カスタム tsconfig へのパス。
triggers object optional
- Worker の scheduled 関数をトリガーする Cron 定義。トリガーを参照してください。
rules Rule optional
- インポートするモジュールとそのインポートタイプを定義する順序付きリスト。Text、Data、CompiledWasm モジュールを使用するためにルールを指定する必要があります。また、.js ファイルを CommonJS ではなく ESModule として扱う場合にもルールを指定する必要があります。
build Build optional
- Worker をビルドする際に Wrangler によって実行されるカスタムビルドステップを設定します。カスタムビルドを参照してください。
no_bundle boolean optional
- 内部ビルドステップをスキップし、Worker スクリプトを直接デプロイします。依存関係のないプレーンな JavaScript Worker が必要です。
minify boolean optional
- アップロード前に Worker スクリプトを最小化します。
node_compat boolean optional
- 非推奨 — 代わりに、nodejs_compat_v2 互換性フラグを有効にするを使用してください。これにより、組み込みの Node.js API が有効になり、必要に応じてポリフィルが追加されます。 node_compat = true を設定すると、Node.js の組み込みモジュールとグローバルのポリフィルが Worker のコードに追加されます。これは Wrangler とバンドルされます。これは @esbuild-plugins/node-globals-polyfill によって提供され、さらに rollup-plugin-node-polyfills ↗ によって支えられています。
preserve_file_names boolean optional
- Wrangler が Worker とバンドルされた追加モジュールのファイル名を保持するかどうかを決定します。デフォルトは、ファイル名の前にコンテンツハッシュを追加することです。例えば、34de60b44167af5c5a709e62a4e20c4f18c9e3b6-favicon.ico のようになります。
logpush boolean optional
- Worker のための Workers Trace Events Logpush を有効にします。このプロパティを持つスクリプトは、アカウントに設定された Workers Logpush ジョブによって自動的に取得されます。デフォルトは false です。
limits Limits optional
- 実行時に課せられる制限を設定します。制限を参照してください。

使用モデル

2024年3月1日以降、Worker の wrangler.toml に設定された使用モデルは無視されます。スタンダード使用モデルが適用されます。

一部の Workers Enterprise 顧客は、使用モデルを変更する能力を維持しています。使用モデルは、Cloudflare ダッシュボードで Workers & Pages > Worker を選択 > 設定 > 使用モデル に移動することで設定する必要があります。

非継承可能なキー

非継承可能なキーはトップレベルで設定可能ですが、環境によって継承することはできず、各環境に対して指定する必要があります。

define Record<string, string> optional
- Worker をデプロイする際に置き換える値のマップ。
vars object optional
- Worker をデプロイする際に設定する環境変数のマップ。環境変数を参照してください。
durable_objects object optional
- Worker がバインドされる Durable Objects のリスト。Durable Objectsを参照してください。
kv_namespaces object optional
- Worker がバインドされる KV 名前空間のリスト。KV 名前空間を参照してください。
r2_buckets object optional
- Worker がバインドされる R2 バケットのリスト。R2 バケットを参照してください。
vectorize object optional
- Worker がバインドされる Vectorize インデックスのリスト。Vectorize インデックスを参照してください。
services object optional
- Worker がバインドされるサービスバインディングのリスト。サービスバインディングを参照してください。
tail_consumers object optional
- Worker がデータを送信する Tail Workers のリスト。Tail Workersを参照してください。

ルートの種類

ルートには、カスタムドメイン、ルート、および workers.dev の3種類があります。

カスタムドメイン

カスタムドメインを使用すると、DNS 設定を変更したり、証明書管理を行ったりすることなく、Worker をドメインまたはサブドメインに接続できます。

pattern string required
- Worker が実行されるパターン。例えば、"example.com"。
custom_domain boolean optional
- Worker がルートではなくカスタムドメイン上で実行されるかどうか。デフォルトは false です。

例:

route = { pattern = "example.com", custom_domain = true }

# または

routes = [
  { pattern = "shop.example.com", custom_domain = true }
]

ルート

ルートを使用すると、ユーザーは URL パターンを Worker にマッピングできます。ルートは、ゾーン ID ルート、ゾーン名ルート、または単純なルートとして構成できます。

ゾーン ID ルート

pattern string required
- Worker が実行されるパターン。例えば、"example.com/*"。
zone_id string required
- pattern に関連付けられたゾーンの ID。ゾーンおよびアカウント ID を見つけるを参照してください。

例:

routes = [
  { pattern = "subdomain.example.com/*", zone_id = "<YOUR_ZONE_ID>" }
]

ゾーン名ルート

pattern string required
- Worker が実行されるパターン。例えば、"example.com/*"。
zone_name string required
- pattern に関連付けられたゾーンの名前。API トークンを使用している場合、これには Account スコープが必要です。

例:

routes = [
  { pattern = "subdomain.example.com/*", zone_name = "example.com" }
]

単純なルート

これは、パターンのみが必要な単純なルートです。

例:

route = "example.com/*"

`workers.dev`

Cloudflare Workers アカウントには、Cloudflare ダッシュボードで設定可能な workers.dev サブドメインが付属しています。

workers_dev boolean optional
- Worker がカスタム workers.dev アカウントサブドメインで実行されるかどうか。デフォルトは true です。

workers_dev = false

トリガー

トリガーを使用すると、Worker の scheduled 関数を呼び出すための cron 式を定義できます。サポートされている cron 式を参照してください。

crons string[] required
- cron 式の配列。
- Cron トリガーを無効にするには、crons = [] に設定します。crons キーをコメントアウトしても Cron トリガーは無効になりません。

例:

[triggers]
crons = ["* * * * *"]

カスタムビルド

Worker がデプロイされる前に実行されるカスタムビルドステップを設定できます。カスタムビルドを参照してください。

command string optional
- Worker をビルドするために使用されるコマンド。Linux および macOS では、コマンドは sh シェルで実行され、Windows では cmd シェルで実行されます。&& および || シェル演算子を使用できます。
cwd string optional
- コマンドが実行されるディレクトリ。
watch_dir string | string[] optional
- wrangler dev を使用している間に変更を監視するディレクトリ。デフォルトは現在の作業ディレクトリです。

例:

[build]
command = "npm run build"
cwd = "build_cwd"
watch_dir = "build_watch_dir"

制限

Worker の動作に制限を課すことができます。制限はスタンダード使用モデルのみサポートされています。制限は Cloudflare のネットワークにデプロイされたときのみ適用され、ローカル開発では適用されません。CPU 制限は最大 30,000 ミリ秒（30 秒）に設定できます。

Each isolate has some built-in flexibility to allow for cases where your Worker infrequently runs over the configured limit. If your Worker starts hitting the limit consistently, its execution will be terminated according to the limit configured.

cpu_ms number optional
- 各呼び出しごとに許可される最大 CPU 時間（ミリ秒単位）。

例:

[limits]
cpu_ms = 100

バインディング

ブラウザレンダリング

Workers Browser Rendering API を使用すると、開発者はヘッドレスブラウザインスタンスをプログラムで制御し、アプリケーションや製品の自動化フローを作成できます。

ブラウザバインディングは、Worker に専用の Chromium ブラウザインスタンスと対話するための認証されたエンドポイントを提供します。

binding string required
D1データベースを参照するために使用されるバインディング名。設定した値（文字列）は、Worker内でこのデータベースを参照するために使用されます。バインディングは、有効なJavaScript変数名 ↗でなければなりません。例えば、binding = "MY_DB"やbinding = "productionDB"は、どちらもバインディングの有効な名前です。

例:

browser = { binding = "<BINDING_NAME>" }

# または

[browser]
binding = "<BINDING_NAME>"

D1データベース

D1はCloudflareのサーバーレスSQLデータベースです。Workerは、D1のクライアントAPIのために各データベースへのbindingを作成することで、D1データベース（またはデータベース）をクエリできます。

D1データベースをWorkerにバインドするには、以下のオブジェクトの配列を[[d1_databases]]キーに割り当てます。

binding string required
- D1データベースを参照するために使用されるバインディング名。設定した値（文字列）は、Worker内でこのデータベースを参照するために使用されます。バインディングは、有効なJavaScript変数名 ↗でなければなりません。例えば、binding = "MY_DB"やbinding = "productionDB"は、どちらもバインディングの有効な名前です。
database_name string required
- データベースの名前。これは異なるデータベースを区別するための人間が読みやすい名前で、データベースを最初に作成する際に設定されます。
database_id string required
- データベースのID。データベースIDは、最初にwrangler d1 createを使用したときや、wrangler d1 listを呼び出したときに利用可能で、データベースを一意に識別します。
preview_database_id string optional
- このD1データベースのプレビューID。提供された場合、wrangler devはこのIDを使用します。そうでない場合は、database_idを使用します。このオプションは、wrangler dev --remoteを使用する際に必要です。
- データベースのID。データベースIDは、最初にwrangler d1 createを使用したときや、wrangler d1 listを呼び出したときに利用可能で、データベースを一意に識別します。

例:

d1_databases = [
  { binding = "<BINDING_NAME>", database_name = "<DATABASE_NAME>", database_id = "<DATABASE_ID>" }
]

# または

[[d1_databases]]
binding = "<BINDING_NAME>"
database_name = "<DATABASE_NAME>"
database_id = "<DATABASE_ID>"

ディスパッチネームスペースバインディング（プラットフォーム用Worker）

ディスパッチネームスペースバインディングは、動的ディスパッチWorkerとディスパッチネームスペース間の通信を可能にします。ディスパッチネームスペースバインディングは、プラットフォーム用Workerで使用されます。プラットフォーム用Workerは、顧客の代わりにサーバーレス関数をプログラム的にデプロイするのに役立ちます。

binding string required
- バインディング名。設定した値（文字列）は、Worker内でこのデータベースを参照するために使用されます。バインディングは、有効なJavaScript変数名 ↗でなければなりません。例えば、binding = "MY_NAMESPACE"やbinding = "productionNamespace"は、どちらもバインディングの有効な名前です。
namespace string required
- ディスパッチネームスペースの名前。
outbound object optional
- service string required バインドするアウトバウンドWorkerの名前。
- parameters array optional データを動的ディスパッチWorkerからアウトバウンドWorkerに渡すためのパラメータのリスト。

[[dispatch_namespaces]]
binding = "<BINDING_NAME>"
namespace = "<NAMESPACE_NAME>"
outbound = {service = "<WORKER_NAME>", parameters = ["params_object"]}

デュラブルオブジェクト

デュラブルオブジェクトは、Workersプラットフォームのための低遅延の調整と一貫したストレージを提供します。

デュラブルオブジェクトをWorkerにバインドするには、以下のオブジェクトの配列をdurable_objects.bindingsキーに割り当てます。

name string required
- デュラブルオブジェクトを参照するために使用されるバインディングの名前。
class_name string required
- デュラブルオブジェクトのエクスポートされたクラス名。
script_name string optional
- デュラブルオブジェクトがこのWorkerの外部に定義されている場合、そのWorkerの名前。このオプションは、ローカルおよびリモート開発の両方で使用できます。ローカル開発では、外部Workerを別のプロセスで実行する必要があります（wrangler devを介して）。リモート開発では、適切なリモートバインディングを使用する必要があります。
environment string optional
- バインドするscript_nameの環境。

例:

durable_objects.bindings = [
  { name = "<BINDING_NAME>", class_name = "<CLASS_NAME>" }
]

# または

[[durable_objects.bindings]]
name = "<BINDING_NAME>"
class_name = "<CLASS_NAME>"

マイグレーション

デュラブルオブジェクトクラスに変更を加える際は、マイグレーションを実行する必要があります。デュラブルオブジェクトのマイグレーションを参照してください。

tag string required
- このマイグレーションの一意の識別子。
new_classes string[] optional
- 定義されている新しいデュラブルオブジェクト。
renamed_classes {from: string, to: string}[] optional
- 名前が変更されたデュラブルオブジェクト。
deleted_classes string[] optional
- 削除されるデュラブルオブジェクト。

例:

[[migrations]]
tag = "v1" # 各エントリに対して一意である必要があります
new_classes = ["DurableObjectExample"] # 新しいクラスの配列

[[migrations]]
tag = "v2"
renamed_classes = [{from = "DurableObjectExample", to = "UpdatedName" }] # 名前変更指示の配列
deleted_classes = ["DeprecatedClass"] # 削除されたクラス名の配列

メールバインディング

You can send an email about your Worker’s activity from your Worker to an email address verified on Email Routing. This is useful for when you want to know about certain types of events being triggered, for example.

Before you can bind an email address to your Worker, you need to enable Email Routing and have at least one verified email address. 次に、必要なメールバインディングのタイプでオブジェクト（send_email）に配列を割り当てます。

name string required
- バインディング名。
destination_address string optional
- メールを送信する選択したメールアドレス。
allowed_destination_addresses string[] optional
- メールを送信する許可リストのメールアドレス。

You can add one or more types of bindings to your wrangler.toml file. However, each attribute must be on its own line:

send_email = [
    {name = "<NAME_FOR_BINDING1>"},
     {name = "<NAME_FOR_BINDING2>", destination_address = "<YOUR_EMAIL>@example.com"},
     {name = "<NAME_FOR_BINDING3>", allowed_destination_addresses = ["<YOUR_EMAIL>@example.com", "<YOUR_EMAIL2>@example.com"]},
]

環境変数

環境変数は、テキスト文字列やJSON値をWorkerに添付するためのバインディングの一種です。

例:

name = "my-worker-dev"

[vars]
API_HOST = "example.com"
API_ACCOUNT_ID = "example_user"
SERVICE_X_DATA = { URL = "service-x-api.dev.example", MY_ID = 123 }

ハイパードライブ

ハイパードライブバインディングを使用すると、Worker内から任意のPostgresデータベースと対話し、クエリを実行できます。

binding string required
- バインディング名。
id string required
- ハイパードライブ構成のID。

例:

# データベースドライバが機能するために必要
compatibility_flags = ["nodejs_compat_v2"]

[[hyperdrive]]
binding = "<BINDING_NAME>"
id = "<ID>"

KVネームスペース

Workers KVは、グローバルで低遅延のキー・バリューデータストアです。データは少数の集中データセンターに保存され、その後、アクセス後にCloudflareのデータセンターにキャッシュされます。

KVネームスペースをWorkerにバインドするには、以下のオブジェクトの配列をkv_namespacesキーに割り当てます。

binding string required
- KVネームスペースを参照するために使用されるバインディング名。
id string required
- KVネームスペースのID。
preview_id string optional
- このKVネームスペースのプレビューID。このオプションは、リモートリソースに対して開発するためにwrangler dev --remoteを使用する際に必要です。ローカルで開発する場合（--remoteなし）、これはオプションのフィールドです。wrangler devはこのIDをKVネームスペースに使用します。そうでない場合、wrangler devはidを使用します。

例:

kv_namespaces = [
  { binding = "<BINDING_NAME1>", id = "<NAMESPACE_ID1>" },
  { binding = "<BINDING_NAME2>", id = "<NAMESPACE_ID2>" }
]

# または

[[kv_namespaces]]
binding = "<BINDING_NAME1>"
id = "<NAMESPACE_ID1>"

[[kv_namespaces]]
binding = "<BINDING_NAME2>"
id = "<NAMESPACE_ID2>"

キュー

キューはCloudflareのグローバルメッセージキューサービスで、配信保証とメッセージバッチ処理を提供します。Workerを使用してキューと対話するには、メッセージをキューに送信するプロデューサーWorkerと、キューからメッセージのバッチを引き出すコンシューマーWorkerが必要です。単一のWorkerは、複数のキューに対して生産および消費を行うことができます。

プロデューサーWorkerにキューをバインドするには、以下のオブジェクトの配列を[[queues.producers]]キーに割り当てます。

queue string required
- Cloudflareダッシュボードで使用されるキューの名前。
binding string required
- Worker内でキューを参照するために使用されるバインディング名。バインディングは、有効なJavaScript変数名 ↗でなければなりません。例えば、binding = "MY_QUEUE"やbinding = "productionQueue"は、どちらもバインディングの有効な名前です。
delivery_delay number optional
- デフォルトでキューに送信されるメッセージを遅延させる秒数。この値は、メッセージまたはバッチごとにオーバーライドできます。

例:

[[queues.producers]]
  binding = "<BINDING_NAME>"
  queue = "<QUEUE_NAME>"
  delivery_delay = 60 # メッセージを消費者に配信する前に60秒遅延させる

コンシューマーWorkerにキューをバインドするには、以下のオブジェクトの配列を[[queues.consumers]]キーに割り当てます。

queue string required
- Cloudflareダッシュボードで使用されるキューの名前。
max_batch_size number optional
- 各バッチで許可される最大メッセージ数。
max_batch_timeout number optional
- バッチが消費者Workerに送信される前に、メッセージがバッチを満たすのを待つ最大秒数。
max_retries number optional
- メッセージが失敗した場合、またはretryAll()が呼び出された場合の最大再試行回数。
dead_letter_queue string optional
- メッセージが少なくともmax_retries回処理に失敗した場合に送信される別のキューの名前。
- dead_letter_queueが定義されていない場合、繰り返し処理に失敗したメッセージは破棄されます。
- 指定された名前のキューが存在しない場合、自動的に作成されます。
max_concurrency number optional
- 一度に実行される最大同時コンシューマー数。この値を設定しないと、呼び出しの数は現在サポートされている最大数にスケールします。
- メッセージが再試行されるときのコンシューマーの自動スケーリングに関する詳細は、コンシューマーの同時実行性を参照してください。
retry_delay number optional
- 再試行されたメッセージを遅延させる秒数。この値は、メッセージまたはバッチごとにオーバーライドできます。

例:

[[queues.consumers]]
  queue = "my-queue"
  max_batch_size = 10
  max_batch_timeout = 30
  max_retries = 10
  dead_letter_queue = "my-queue-dlq"
  max_concurrency = 5
  retry_delay = 120 # 再試行されたメッセージを2分遅延させてから再配信を試みる

R2バケット

Cloudflare R2 Storageは、開発者が通常のクラウドストレージサービスに関連する高額な出口帯域幅料金なしで、大量の非構造化データを保存できるようにします。

R2バケットをWorkerにバインドするには、以下のオブジェクトの配列をr2_bucketsキーに割り当てます。

binding string required
- R2バケットを参照するために使用されるバインディング名。
bucket_name string required
- このR2バケットの名前。
jurisdiction string optional
- このR2バケットが存在する管轄区域。管轄区域が指定されている場合は、管轄区域の制限を参照してください。
preview_bucket_name string optional
- このR2バケットのプレビューネーム。提供された場合、wrangler devはこの名前をR2バケットに使用します。そうでない場合、bucket_nameを使用します。このオプションは、wrangler dev --remoteを使用する際に必要です。

例:

r2_buckets  = [
  { binding = "<BINDING_NAME1>", bucket_name = "<BUCKET_NAME1>"},
  { binding = "<BINDING_NAME2>", bucket_name = "<BUCKET_NAME2>"}
]

# または

[[r2_buckets]]
binding = "<BINDING_NAME1>"
bucket_name = "<BUCKET_NAME1>"

[[r2_buckets]]
binding = "<BINDING_NAME2>"
bucket_name = "<BUCKET_NAME2>"

ベクトル化インデックス

ベクトル化インデックスを使用すると、セマンティック検索、分類、その他のベクトル検索ユースケースのためにベクトル埋め込みを挿入およびクエリできます。

ベクトル化インデックスをWorkerにバインドするには、以下のオブジェクトの配列をvectorizeキーに割り当てます。

binding 文字列必須
- Workerコードからバインドされたインデックスを参照するために使用されるバインディング名。
index_name 文字列必須
- バインドするインデックスの名前。

例:

vectorize  = [
  { binding = "<BINDING_NAME>", index_name = "<INDEX_NAME>"}
]

# または

[[vectorize]]
binding = "<BINDING_NAME>"
index_name = "<INDEX_NAME>"

サービスバインディング

サービスバインディングを使用すると、HTTPリクエストを別のWorkerに送信できますが、そのリクエストはインターネットを経由しません。リクエストはすぐに下流のWorkerを呼び出し、サードパーティサービスへのリクエストと比較してレイテンシを減少させます。サービスバインディングについてを参照してください。

他のWorkerを自分のWorkerにバインドするには、以下のオブジェクトの配列をservicesキーに割り当てます。

binding 文字列必須
- バインドされたWorkerを参照するために使用されるバインディング名。
service 文字列必須
- Workerの名前。
entrypoint 文字列任意
- バインドするエントリポイントの名前。エントリポイントを指定しない場合、Workerのデフォルトエクスポートが使用されます。

例:

services = [
  { binding = "<BINDING_NAME>", service = "<WORKER_NAME>", entrypoint = "<ENTRYPOINT_NAME>" }
]

# または

[[services]]
binding = "<BINDING_NAME>"
service = "<WORKER_NAME>"
entrypoint = "<ENTRYPOINT_NAME>"

アナリティクスエンジンデータセット

Workers Analytics Engineは、Workersからの分析、可観測性、およびデータロギングを提供します。データポイントをWorkerバインディングに書き込み、SQL APIを使用してデータをクエリします。

アナリティクスエンジンデータセットをWorkerにバインドするには、以下のオブジェクトの配列をanalytics_engine_datasetsキーに割り当てます。

binding 文字列必須
- データセットを参照するために使用されるバインディング名。
dataset 文字列任意
- 書き込むデータセット名。指定しない場合、バインディングと同じ名前がデフォルトになります。

例:

analytics_engine_datasets = [{ binding = "<BINDING_NAME>", dataset = "<DATASET_NAME>" }]

# または

[[analytics_engine_datasets]]
binding = "<BINDING_NAME>"
dataset = "<DATASET_NAME>"

mTLS証明書

クライアント認証を必要とするオリジンと通信するために、WorkerはサブリクエストでmTLSの証明書を提示できます。Wranglerは、これらの証明書をアップロードおよび管理するためのmtls-certificate コマンドを提供します。

WorkerのmTLS証明書へのバインディングを作成するには、以下の形のオブジェクトの配列をmtls_certificatesキーに割り当てます。

binding 文字列必須
- 証明書を参照するために使用されるバインディング名。
certificate_id 文字列必須
- 証明書のID。Wranglerはこれをmtls-certificate uploadおよびmtls-certificate listコマンドを介して表示します。

mTLS証明書バインディングを含むwrangler.toml構成の例:

mtls_certificates = [
    { binding = "<BINDING_NAME1>", certificate_id = "<CERTIFICATE_ID1>" },
    { binding = "<BINDING_NAME2>", certificate_id = "<CERTIFICATE_ID2>" }
]

# または

[[mtls_certificates]]
binding = "<BINDING_NAME1>"
certificate_id = "<CERTIFICATE_ID1>"

[[mtls_certificates]]
binding = "<BINDING_NAME2>"
certificate_id = "<CERTIFICATE_ID2>"

mTLS証明書バインディングは、実行時にfetchメソッドを介してセキュアなオリジンと通信するために使用できます。

Workers AI

Workers AIを使用すると、Cloudflareネットワーク上で自分のコードから機械学習モデルを実行できます。これには、Workers、Pages、またはREST APIを介しての実行が含まれます。

他のバインディングとは異なり、このバインディングはWorkerプロジェクトごとに1つのAIバインディングに制限されています。

binding 文字列必須
- バインディング名。

例:

ai = { binding = "<AI>" }

# または

[ai]
binding = "AI" # Workerコード内の`env.AI`で利用可能

バンドル

rulesキーを使用して、Workerにアセットをバンドルできます。これにより、Workerが呼び出されたときにこれらのアセットをインポートできるようになります。rulesキーは以下のオブジェクトの配列になります。

type 文字列必須
- アセットのタイプ。ESModule、CommonJS、CompiledWasm、TextまたはDataのいずれかでなければなりません。
globs string[] 必須
- グロブルールの配列（例: ["**/*.md"]）。グロブ ↗を参照してください。
fallthrough ブール値任意
- ルールにtrueが設定されている場合、同じTypeの複数のルールを持つことができます。

例:

rules = [
  { type = "Text", globs = ["**/*.md"], fallthrough = true }
]

Worker内でのアセットのインポート

Worker内でこれらのアセットをインポートして参照することができます。次のようにします:

import markdown from './example.md'

export default {
  async fetch() {
    return new Response(markdown)
  }
}

ローカル開発設定

ローカルプロトコルやポートなど、ローカル開発のさまざまな側面を構成できます。

ip 文字列任意
- ローカル開発サーバーがリッスンするIPアドレス。デフォルトはlocalhostです。
port 数値任意
- ローカル開発サーバーがリッスンするポート。デフォルトは8787です。
local_protocol 文字列任意
- ローカル開発サーバーがリクエストをリッスンするプロトコル。デフォルトはhttpです。
upstream_protocol 文字列任意
- ローカル開発サーバーがリクエストを転送するプロトコル。デフォルトはhttpsです。
host 文字列任意
- リクエストを転送するホスト。Workerの最初のrouteのホストがデフォルトです。

例:

[dev]
ip = "192.168.1.1"
port = 8080
local_protocol = "http"

シークレット

シークレットは、Workerに暗号化されたテキスト値を添付できるバインディングの一種です。

When developing your Worker or Pages Function, create a .dev.vars file in the root of your project to define secrets that will be used when running wrangler dev or wrangler pages dev, as opposed to using environment variables in wrangler.toml. This works both in local and remote development modes.

The .dev.vars file should be formatted like a dotenv file, such as KEY="VALUE":

SECRET_KEY="value"
API_TOKEN="eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9"

モジュールエイリアス

特定のパッケージのインポート呼び出しを、選択したモジュールに置き換えるようにWranglerを構成できます。aliasフィールドを設定します:

[alias]
"foo" = "./replacement-module-filepath"

export const bar = "baz";

上記の構成により、fooモジュールのインポートまたはrequire()の呼び出しは、置き換えモジュールを指すようにエイリアスされます:

import { bar } from "foo";

console.log(bar); // "baz"を返します

例: NPMからの依存関係のエイリアス

モジュールエイリアスを使用して、Workersで動作しないNPMパッケージの実装を提供できます。これは、依存関係の依存関係としてNPMパッケージに間接的に依存している場合でも適用されます。

たとえば、一部のNPMパッケージはnode-fetch ↗に依存しています。このパッケージは、Node.jsに組み込まれる前にfetch() APIのポリフィルを提供しました。

Workersではnode-fetchは必要ありません。なぜなら、fetch() APIはWorkersランタイムによって提供されるからです。また、node-fetchは、http/httpsモジュールの現在サポートされていないNode.js APIに依存しているため、Workersでは動作しません。

すべてのnode-fetchのインポートを、Workersランタイムに組み込まれたfetch() APIに直接指すようにエイリアスできます:

[alias]
"node-fetch" = "./fetch-nolyfill"

export default fetch;

例: Node.js APIのエイリアス

モジュールエイリアスを使用して、Workersランタイムでまだ利用できないNode.js APIの独自のポリフィル実装を提供できます。

たとえば、依存しているNPMパッケージがfs.readFile ↗を呼び出すとします。次のように、fsモジュールをエイリアスできます:

[alias]
"fs" = "./fs-polyfill"

export function readFile() {
  // ...
}

多くの場合、これにより依存関係を機能させるために必要なAPIを提供できます。Cloudflare WorkersのNode.js APIサポートについては、Cloudflare Workers Node.js APIドキュメントページを参照してください。

ソースマップ

ソースマップは、コンパイルおよびミニファイされたコードを元のコードに戻します。ソースマップは、JavaScriptランタイムから返されるスタックトレースと組み合わされて、スタックトレースを表示します。

upload_source_maps ブール値
- upload_source_mapsがtrueに設定されている場合、Wranglerはwrangler deployまたはwrangler versions deployを実行するときにソースマップファイルを自動的に生成してアップロードします。

例:

upload_source_maps = true

Workers Sites

Workers Sitesを使用すると、静的ウェブサイトや、VueやReactなどのフレームワークを使用した動的ウェブサイトをWorkers上でホストできます。

bucket 文字列必須
- 静的アセットを含むディレクトリ。wrangler.tomlファイルに対して相対的なパスでなければなりません。
include string[] 任意
- バケットの場所からファイルまたはディレクトリ名に一致する.gitignoreスタイルのパターンの排他的リスト。一致した項目のみがアップロードされます。
exclude string[] 任意
- アップロードから除外すべきバケット内のファイルまたはディレクトリに一致する.gitignoreスタイルのパターンのリスト。

例:

[site]
bucket = "./public"
include = ["upload_dir"]
exclude = ["ignore_dir"]

プロキシサポート

企業ネットワークには、プロキシが存在することが多く、これが接続の問題を引き起こすことがあります。Wranglerを適切なプロキシの詳細で構成するには、以下の環境変数を使用します:

https_proxy
HTTPS_PROXY
http_proxy
HTTP_PROXY

macOSでこれを構成するには、Wranglerコマンドの前にHTTP_PROXY=http://<YOUR_PROXY_HOST>:<YOUR_PROXY_PORT>を追加します。

例:

$ HTTP_PROXY=http://localhost:8080 wrangler dev

ITチームがコンピュータのプロキシ設定を構成している場合、Wranglerが外部リクエストを行う際に、このリストの最初の非空の環境変数が使用されることに注意してください。

たとえば、https_proxyとhttp_proxyの両方が設定されている場合、Wranglerは外部リクエストに対してhttps_proxyのみを使用します。

真実の源

wrangler.tomlファイルをWorker構成の真実の源として扱うことをお勧めします。Wranglerを使用している場合、Cloudflareダッシュボードを介してWorkerに変更を加えることは避けてください。

CloudflareダッシュボードからWorkerに変更を加える必要がある場合、ダッシュボードはwrangler.tomlファイルにコピーするためのTOMLスニペットを生成します。これにより、wrangler.tomlファイルが常に最新の状態に保たれます。

Cloudflareダッシュボードで環境変数を変更すると、次回デプロイ時にWranglerがそれらを上書きします。この動作を無効にしたい場合は、wrangler.tomlにkeep_vars = trueを追加します。

ダッシュボードでルートを変更すると、Wranglerは次回のデプロイ時にwrangler.tomlに設定されたルートで上書きします。Cloudflareダッシュボードのみでルートを管理するには、wrangler.tomlファイルからすべてのrouteおよびroutesキーを削除します。その後、wrangler.tomlファイルにworkers_dev = falseを追加します。詳細については、非推奨事項を参照してください。

Wranglerは、wrangler secret delete <key>を実行しない限り、シークレット（暗号化された環境変数）を削除しません。

Cloudflare Dashboard Discord Community Learning Center Support Portal

Cookie Settings