---
title: "Cloudflare Workers 上の Web 層"
description: "機能を一部に限定した Quire Web 層を Cloudflare Workers で実行します。"
image: "https://docs.quirelms.com/og.png"
---

> Documentation Index
> Fetch the complete documentation index at: https://docs.quirelms.com/ja/llms.txt
> Use this file to discover all available pages before exploring further.

# Cloudflare Workers 上の Web 層

<span id="the-web-tier-on-cloudflare-workers"></span>

設計は `docs/architecture/23-ops.md` のセクション 6 にあります。Workers では機能を一部に限定した Web 層を実行します。Workers で全機能をそろえることは対象外です (PRD セクション 12)。この環境でできないことは起動時に名前を明記して拒否されます。

## このリリースの状態 <!--quire:status-in-this-release-->

設定は用意されています (`apps/web/wrangler.jsonc`、`cloudflare-module` Nitro プリセット、Hyperdrive ブリッジ、起動時チェック)。Worker には R2 用の S3 互換ストレージ (`QUIRE_STORAGE_DRIVER=s3`)、リクエスト間で動作するリアルタイムドライバー (`QUIRE_REALTIME_DRIVER=durable_objects` または `centrifugo`)、共有キャッシュ (`QUIRE_CACHE_DRIVER=postgres` または `valkey`)、HTTP メールプロバイダーが必要です。設定がない場合は Worker の起動を拒否し、不足している設定名をログに表示します。Durable Objects ドライバーは `apps/realtime-worker` のリアルタイム Worker を利用します (チャネルごとに Durable Object を作り、配信、プレゼンス、履歴を処理します。切断は利用者ごとのオブジェクトで処理します)。以下の手順で併せてデプロイするか、Centrifugo を使ってください。

## 各コンポーネント <!--quire:the-pieces-->

| コンポーネント | Cloudflare 上の実行先 |
| --- | --- |
| `web` | `nodejs_compat` を使う Worker |
| Postgres | Hyperdrive 経由の外部 DB: アプリケーションロール用 `HYPERDRIVE`、同一 DB のレポートロール用 `REPORT_HYPERDRIVE`。起動時に接続文字列を `DATABASE_URL` と `QUIRE_REPORT_DATABASE_URL` にコピーします |
| ファイル | S3 API 経由の R2 (`S3_ENDPOINT=https://<account>.r2.cloudflarestorage.com`); `FILES` binding でバケットを接続 |
| バックグラウンドジョブ | 書き込みと同時に登録するジョブには Hyperdrive 経由の pg-boss を使います。連携 worker で `QUIRE_QUEUE_DRIVER=cloudflare` にすると、軽量ジョブ (順序を問わない通知、webhook 配信) は Cloudflare Queues 経由になり Postgres をポーリングしません。両方を連携 worker が実行します |
| リアルタイム | Durable Objects を使うリアルタイム Worker `apps/realtime-worker` |
| `worker`、`scheduler`、`collab`、`content`、ClamAV、Gotenberg、ffmpeg | 連携コンテナホスト。Worker では実行できません |
| トレース | `wrangler.jsonc` で有効にする Workers observability |

`REPORT_HYPERDRIVE` は `HYPERDRIVE` が示す物理 DB のレポートロールを提供します。以下の説明のとおり、この環境では追加の物理 DB に固定されたテナントを扱いません。

## この環境でできないこと <!--quire:what-this-target-cannot-do-->

起動時にすべての問題を列挙して拒否します。

- **SMTP は使えません。** `QUIRE_EMAIL_PROVIDER_CONFIG` に HTTP プロバイダーを指定します。
- **ローカルディスクは使えません。** `QUIRE_STORAGE_DRIVER` にオブジェクトストレージを指定します。
- **プロセス内リアルタイム機能やキャッシュは使えません。** Worker はリクエスト間でメモリーを共有しないため、`QUIRE_REALTIME_DRIVER=inprocess` と `QUIRE_CACHE_DRIVER=memory` は拒否されます。
- **Worker で ClamAV、Gotenberg、ffmpeg は使えません。** Worker に設定した `CLAMAV_URL`、`GOTENBERG_URL`、`FFMPEG_PATH` は拒否されます。代わりに連携 worker に設定してください。
- **専用 DB の組織は利用できません。** Worker の Hyperdrive binding はデプロイ時に固定されるため、独自 DB を持つ組織には明確な「ここでは利用できません」ページが表示されます。Compose または Vercel で提供してください。

拒否はされませんが、**Workers では事前レンダリングと段階的な静的再生成が動作しません**。フレームワークのドキュメントに記載があっても同じです。すべてのルートはリクエストごとにレンダリングします。

この環境ではトランザクションを短くし、ネットワーク呼び出しをまたいで保持しないでください。接続がプールに戻ると Hyperdrive がセッション状態をリセットするため、テナントコンテキストはトランザクションごとに設定します。

## デプロイ <!--quire:deploying-->

1. リソースを作成します。
   ```sh
   bun run --bun wrangler hyperdrive create quire-app --connection-string="postgres://quire_app:...@db.example.com:5432/quire"
   bun run --bun wrangler hyperdrive create quire-report --connection-string="postgres://quire_report:...@db.example.com:5432/quire"
   bun run --bun wrangler r2 bucket create quire-files
   bun run --bun wrangler queues create quire-jobs
   ```
   2 つの Hyperdrive ID を `apps/web/wrangler.jsonc` に設定します。
2. `bun run --bun wrangler secret put <NAME>` を `apps/web` から 1 つずつ実行して、`QUIRE_SECRET_KEY`、`QUIRE_MASTER_KEY`、`QUIRE_EMAIL_PROVIDER_CONFIG`、`S3_ACCESS_KEY_ID`、`S3_SECRET_ACCESS_KEY`、`QUIRE_COLLAB_SIGNING_KEY`、`QUIRE_REALTIME_WORKER_SECRET` を設定します。通常の設定 (`QUIRE_APP_ORIGIN`、`QUIRE_CONTENT_ORIGIN`、`QUIRE_PLATFORM_DOMAINS`、`QUIRE_DATABASE_ID`、`S3_ENDPOINT`、`S3_BUCKET`、`QUIRE_COLLAB_URL`) は `vars` に設定します。
3. `apps/web` からビルドしてデプロイします。
   ```sh
   NITRO_PRESET=cloudflare-module bun run build
   bun run --bun wrangler deploy
   ```
4. リアルタイム Worker をデプロイします。Web 層の `QUIRE_REALTIME_WORKER_SECRET` と、トークンシークレットを `QUIRE_REALTIME_TOKEN_SECRET` に設定します。Web 層は独自の `QUIRE_REALTIME_TOKEN_SECRET`、未設定なら `QUIRE_SECRET_KEY` を使ってリアルタイムトークンに署名するため、同じ値を設定してください。Web 層の `QUIRE_REALTIME_WORKER_URL` には Worker のアドレスを指定します。
   ```sh
   cd apps/realtime-worker
   bun run --bun wrangler secret put QUIRE_REALTIME_WORKER_SECRET
   bun run --bun wrangler secret put QUIRE_REALTIME_TOKEN_SECRET
   bun run --bun wrangler deploy
   ```
5. Cloudflare Queues で軽量ジョブを実行する場合、軽量キューごとにキューを作成し、Queues の読み取り・書き込み権限を持つ API token とともに連携 worker に次を設定します。
   ```sh
   bun run --bun wrangler queues create quire-events-notifications
   bun run --bun wrangler queues create quire-events-notifications-dead
   bun run --bun wrangler queues create quire-events-webhooks
   bun run --bun wrangler queues create quire-events-webhooks-dead
   ```
   `QUIRE_QUEUE_DRIVER=cloudflare`、`CLOUDFLARE_ACCOUNT_ID`、`CLOUDFLARE_QUEUES_TOKEN`、必要なら `QUIRE_QUEUE_PREFIX` (既定値 `quire-`) を設定します。
6. [Vercel ガイド](/ja/ops/vercel/)の手順 3 と同じように連携ホストを実行します。Worker の各デプロイ前に、そこでマイグレーションを実行します。

設定が拒否されると `bun run --bun wrangler tail` に Web 層が Cloudflare で起動しなかったこと と、不足設定の一覧が表示されます。

Source: https://docs.quirelms.com/ja/ops/cloudflare/index.mdx