Cloudflare環境でアプリを作っていたところ、Cloudflare Workers(以降Workers) で Service Binding RPC が使えると知りました。

　
Cloudflare Pages (以降Pages) とWorkersの連携でも RPC が使えるのか気になりました。調べてみたところ、使えそうという記事がありました。

　
そこで、Workers と Pages の RPC による連携として

Workers は C3 で作成し、RPC用関数を定義
Pages は Hono で作成し、WorkersのRPC用関数から値をもらって表示

をためしてみたところ、色々ハマったことから、メモを残しておきます。

環境
Service Binding RPCを使わない、Pages と Workers を作成
Service Bindings RPC を使って、WorkersとPagesを連携する
Wrangler で Workers と Pages をデプロイ
- Workers のデプロイ
- Pages のデプロイ
Githubと連携して、Pagesをデプロイする
セキュリティ面から Named entrypoint を使うように修正する
今回の記事を作るにあたり悩んだこと
ソースコード

環境

Windows 11 WSL2
Wrangler 3.60.3
Bun 1.1.13
Cloudflare Workers
- C3 で生成
Cloudflare Pages
- Hono 4.4.6
開発向けツール
- concurrently 8.2.2
  - ローカルで、PagesとWorkersを同時に起動するため
- Biome 1.8.1
  - Linter & Formatter

Service Binding RPCを使わない、Pages と Workers を作成

まずは、ローカルでそれぞれが連携しない、Pages と Workers を作成してみます。

事前準備

全体で使うパッケージをインストールします。

$ bun add -d wrangler concurrently

$ bun add --dev --exact @biomejs/biome

　
今回のWorkersとPagesですが、Bunのworkspace機能を使ってモノレポにします。

　
具体的には、 packages の下に2つのディレクトリを用意します。

app-worker
- Workers用。C3で作り、Bunで動作
app-page
- Pages用。Honoで作り、Bunで動作

　
まずは package.json に Bun workspace 用の設定を追加します。

{
  "private": true,  // 追加
  "workspaces": ["packages/*"],  // 追加
  "dependencies": {},
  "devDependencies": {
    "biome": "^0.3.3",
    "concurrently": "^8.2.2",
    "wrangler": "^3.60.3"
  }
}

　
また、Bunのworkspaceを使うときのサブディレクトリ packages も作成し、その中へ移動しておきます。

$ mkdir packages

$ cd packages/

Workersの作成

今回は Cloudflare C3 を使い、Workers を作成します。
Create projects with C3 CLI · Cloudflare Pages docs

必要最低限の実装だけあればよいので、

ディレクトリは ./app-worker
C3のテンプレートは "Hello World" Worker

とし、あとは任意な設定とします。

なお、 bun create 時に cloudflare@latest とすると、最新版を探しに行って帰ってこなかったことから、明示的に2024/6/15の最新バージョン 2.21.7 を指定しています。

$ bun create cloudflare@2.21.7

using create-cloudflare version 2.21.7

╭ Create an application with Cloudflare Step 1 of 3
│ 
├ In which directory do you want to create your application?
│ dir ./app-worker
│
├ What type of application do you want to create?
│ type "Hello World" Worker
│
├ Do you want to use TypeScript?
│ yes typescript
│
├ Copying template files 
│ files copied to project directory
│ 
├ Updating name in `package.json` 
│ updated `package.json`
│ 
├ Installing dependencies 
│ installed via `bun install`
│ 
├ Installing dependencies 
│ installed via `bun install`
│ 
╰ Application created 

╭ Configuring your application for Cloudflare Step 2 of 3
│ 
├ Installing wrangler A command line tool for building Cloudflare Workers 
│ installed via `bun install wrangler --save-dev`
│ 
├ Installing @cloudflare/workers-types 
│ installed via bun
│ 
├ Adding latest types to `tsconfig.json` 
│ skipped couldn't find latest compatible version of @cloudflare/workers-types
│ 
├ Retrieving current workerd compatibility date 
│ compatibility date 2024-06-14
│ 
╰ Application configured 

╭ Deploy with Cloudflare Step 3 of 3
│ 
├ Do you want to deploy your application?
│ no deploy via `bun run deploy`
│
├  APPLICATION CREATED  Deploy your application with bun run deploy
│ 
│ Navigate to the new directory cd app-worker
│ Run the development server bun run start
│ Deploy your application bun run deploy
│ Read the documentation https://developers.cloudflare.com/workers
│ Stuck? Join us at https://discord.cloudflare.com
│ 
╰ See you again soon!

　
この時点で Workers ができているはずです。

そこで、 app-worker ディレクトリの中で bun run dev して、http://localhost:8787/ へアクセスしたところ、 Hello World! が表示されました。

Pages の作成

続いて、Honoを使ってPagesを作成します。

$ bun create hono app-page

create-hono version 0.7.1
✔ Using target directory … app-page
? Which template do you want to use? cloudflare-pages
✔ Cloning the template
? Do you want to install project dependencies? no
🎉 Copied project files
Get started with: cd app-page

　
上記ではインストールを選択しなかったので、改めて app-pageへ移動し、インストールを行います。

$ cd app-page

$ bun install
bun install v1.1.13 (bd6a6051)

+ @cloudflare/workers-types@4.20240614.0
+ @hono/vite-cloudflare-pages@0.4.0
+ @hono/vite-dev-server@0.12.1
+ vite@5.3.1
+ wrangler@3.60.3
+ hono@4.4.6

97 packages installed [1403.00ms]

　
bun run dev して、http://localhost:5173/ へアクセスすると、 Hello! が表示されました。

concurrently で Workers と Pages を同時に起動できるようにする

今後WorkersとPagesを連携して動作確認をしますが、それぞれのディレクトリで bun run dev するのは手間です。

そこで、 concurrently を使って、Workers と Pages を同時に起動できるようにします。

　
まずは、Workersである app-worker の package.json で、起動コマンドを dev:worker へ修正します。

{
  // ...
  "scripts": {
    "dev:worker": "wrangler dev",
    // ...
  },
  //...
}

　
続いて、Pagesである app-page の package.json で、 name の追加と dev:page への修正を行います。

また、Bunのドキュメントにある通り、依存先の Worker を指定します。
なお、ドキュメントと異なり devDpendencies に設定しましたが、特に意図はないです。。ドキュメントに従うなら dependencies のほうが良いかもしれません。
Configuring a monorepo using workspaces | Bun Examples

{
  "name": "app-page",
  // ...
  "scripts": {
    "dev:page": "vite",
    "deploy": "bun run build && wrangler pages deploy"
    // ...
  },
  //...
  "devDependencies": {
    "app-worker": "workspace:*"
  }
  // ...
}

　
最後に、ルートにある package.json に、concurrently で Workers と Pages を同時に起動できるような script を追加します。

その際、Bunのfilterを使って、Workers と Pages をそれぞれ指定します。
Filter – Package manager | Bun Docs

{
  //...
  "scripts": {
    "dev": "concurrently \"bun run --filter=\"app-worker\" dev:worker\" \"bun run --filter=\"app-page\" dev:page\""
  },
  //...
}

　
準備ができたので動作確認します。

ルートディレクトリで bun run dev すると、WorkersとPagesの両方が起動しました。

それぞれのURLへアクセスしても、先ほどと同じように表示されます。

$ bun run dev

bun run dev
$ concurrently "bun run --filter="app-worker" dev:worker" "bun run --filter="app-page" dev:page"
app-worker dev:worker $ wrangler dev
[0] │ 
[0] │  ⛅️ wrangler 3.60.3
[0] │ -------------------
[0] │ 
[0] │ ⎔ Starting local server...
[wrangler:inf] Ready on http://localhost:8787
[0] └─ Running...
app-page dev:page $ vite
[1] │ 
[1] │   VITE v5.3.1  ready in 592 ms
[1] │ 
[1] │   ➜  Local:   http://localhost:5173/
[1] │   ➜  Network: use --host to expose
[1] └─ Running...

Service Bindings RPC を使って、WorkersとPagesを連携する

WorkersとPagesができたので、次は Pages から Workers を呼び出す Service Bindings RPC を試してみます。

Workers で WorkerEntrypoint を使った実装へと差し替える

公式ドキュメントにある通り、 WorkerEntrypoint クラスを使った実装へと差し替えます。
The WorkerEntrypoint Class - Service bindings - RPC (WorkerEntrypoint) · Cloudflare Workers docs

今回は hello というメソッドを用意し、Pagesから呼び出せるようにします。

なお、今回はサンプルコードにあるように、 default export を使った実装にします。

また、 fetch メソッドも実装しておかないとエラーになるため、忘れずに実装しておきます。

import { WorkerEntrypoint } from 'cloudflare:workers'

export default class MyWorkerEntrypoint extends WorkerEntrypoint {
  async hello() {
    // biome-ignore lint: debug
    console.log('called worker!')
    return 'Hello my worker!'
  }

  fetch() {
    return new Response('Hello World!')
  }
}

　
以上で Workers の準備は完了です。

Pagesで Service Bindings RPC 用の設定を wrangler.toml に追加する

続いて Pages を実装します。

まずは、Service Bindings RPC 用の設定を wrangler.toml に追加します。
Service bindings - Configuration - Wrangler · Cloudflare Workers docs

Workersでは default export を使ったため、今回は binding と service を定義します。

[[services]]
# ソースコードの中で参照する名前
# hono的には c.env.MY_WORKERのように参照する
binding = "MY_WORKER"

# serviceは app-workerのwrangler.tomlにある `name` と同じ名前にする必要がある
service = "app-worker"

Pages で Service Bindings RPC を使って、Workers を呼び出す

設定が終わったので、次は実装です。

Honoの app.get() の中で、 c.env.MY_WORKER.hell() のようにして、Service Bindings RPC を使います。

なお、 Service Bindings RPC を使うときには async を使うとのことです。
All calls are asynchronous | Remote-procedure call (RPC) · Cloudflare Workers docs

app.get('/', async (c) => {
  const r = await c.env.MY_WORKER.hello()

  return c.render(r)
})

usingを使ったRPCリソースの開放が必要か検討する

今回、Service Binding RPC を使っています。RPCにはLifecycleがあります。
Workers RPC — Lifecycle · Cloudflare Workers docs

そのため、以下のLifecycleのドキュメントや記事にある通り、リソースの開放が必要になるかもしれません。

　
今回の使い方を見てみると

app.get('/', async (c) => {
  const r = await c.env.MY_WORKER.hello()

  return c.render(r)
})

のように、Honoの app.get() 、Cloudflare 的には fetch handler の中でRPCを使っています。

Lifecycleの Automatic disposal and execution contexts に記載されている例に該当しそうなことから、今回は using キーワードを使わない実装で良さそうです。

End of event handler / execution context

When an event handler is “done”, any stubs created as part of the event are automatically disposed.

For example, consider a fetch() handler which handles incoming HTTP events. The handler may make outgoing RPCs as part of handling the event, and those may return stubs. When the final HTTP response is sent, the handler is “done”, and all stubs are immediately disposed.

　

More precisely, the event has an “execution context”, which begins when the handler is first invoked, and ends when the HTTP response is sent. The execution context may also end early if the client disconnects before receiving a response, or it can be extended past its normal end point by calling ctx.waitUntil().

　

For example, the Worker below does not make use of the using declaration, but stubs will be disposed of once the fetch() handler returns a response

　

https://developers.cloudflare.com/workers/runtime-apis/rpc/lifecycle#automatic-disposal-and-execution-contexts

　
以上より、 Pages の実装も完了です。

動作確認

ルートディレクトリで bun run dev し、http://localhost:5173/ にアクセスします。

すると、 Hello my worker! というWorkerから取得した Hello my worker! が表示されました。

Wrangler で Workers と Pages をデプロイ

今まではローカルで Service Bindings RPC を動かしてきました。

次はCloudflareへデプロイし、動作を確認してみます。

Workers のデプロイ

まずは Workers からデプロイします。

app-worker ディレクトリの中に入り、以下を実行すると、デプロイが終わりました。

$ bun run deploy

Pages のデプロイ

Workers のデプロイが完了したことを確認後、Pages のデプロイを行います。

bun run deploy すると、初回デプロイのため、Pages の proeject が作成されます。

また、production ブランチについての質問もあります。ここまでの開発は feature ブランチ上で行ってきましたが、productionは main ブランチにします。

$ bun run deploy

$ bun run build && wrangler pages deploy
$ vite build
vite v5.3.1 building SSR bundle for production...
✓ 41 modules transformed.
dist/_worker.js  27.90 kB
✓ built in 249ms
The project you specified does not exist: "app-page". Would you like to create it?"
❯ Create a new project
✔ Enter the production branch name: … main
✨ Successfully created the 'app-page' project.
🌎  Uploading... (1/1)

✨ Success! Uploaded 1 files (1.78 sec)

✨ Compiled Worker successfully
✨ Uploading Worker bundle
✨ Uploading _routes.json
🌎 Deploying...
✨ Deployment complete! Take a peek over at https://***.pages.dev

　
デプロイ後、 Cloudflare console を確認すると、 Preview な Environment にデプロイされました。

　
次に、今までの実装を main ブランチに取り込み & main ブランチへ切り替えしてから、デプロイします。

$ git branch
  feature/add_pages_and_workers
* main

$ bun run deploy
$ bun run build && wrangler pages deploy
$ vite build
vite v5.3.1 building SSR bundle for production...
✓ 41 modules transformed.
dist/_worker.js  27.90 kB
✓ built in 270ms
🌍  Uploading... (1/1)

✨ Success! Uploaded 0 files (1 already uploaded) (0.50 sec)

✨ Compiled Worker successfully
✨ Uploading Worker bundle
✨ Uploading _routes.json
🌎 Deploying...
✨ Deployment complete! Take a peek over at https://d10acd67.app-page-7vt.pages.dev/

　
Cloudflareのconsoleを確認すると、 Production へのデプロイが成功していました。

　
また、デプロイ先のURLを開くと、Workerから取得した値が表示されました。

　
ちなみに、初回デプロイ時によく見かけたのが、Pagesのデプロイで示されたURLを開くと Internal Server Error となることです。

Pagesのログを見ると "TypeError: e.env.MY_WORKER.hello is not a function" のようなエラーが出ていました。

{
  "outcome": "ok",
  "scriptName": "pages-worker--2956310-production",
  "diagnosticsChannelEvents": [],
  "exceptions": [],
  "logs": [
    {
      "message": [
        "TypeError: e.env.MY_WORKER.hello is not a function"
      ],
      "level": "error",
      "timestamp": 1718434302398
    }
  ],
}

　
ただ、手元では20分ほど待つと環境構築が終わり、Cloudflare上で Service Bindings RPC で Worker からデータを取得・表示できるようになりました。

また、一度解消してしまえば、再発はしないようでした。

Githubと連携して、Pagesをデプロイする

Cloudflare Pagesは、Wrangler以外にも、Githubと連携してデプロイすることができます。
Git integration · Cloudflare Pages docs

そこで、Githubと連携したときのデプロイ方法を確認してみます。

Pagesの wrangler.toml に設定を追加

今回のGithubからのデプロイでも Bun を使います。

ただ、今のままではデプロイ時の Bun のバージョンはデフォルトのままになってしまいます(2024/6/15時点では、1.0.1)。
Language support and tools · Cloudflare Pages docs

デプロイログにはこんな感じで出力されており、 Bun 1.0.1 が使われていることが分かります。

2024-06-15T02:56:03.647712Z  Detected the following tools from environment: bun@1.0.1, nodejs@18.17.1
2024-06-15T02:56:03.648272Z Installing project dependencies: bun install --frozen-lockfile
2024-06-15T02:56:03.913028Z bun install v1.0.1 (31aec4eb)

　
そこで、Pages の wrangler.toml に環境変数を設定し、指定した Bun のバージョンを使ってデプロイするようにします。

[vars]
BUN_VERSION = "1.1.12"

Cloudflare と Github を連携する

続いて、Cloudflareのドキュメントに従い、CloudflareからGithubへアクセスできるようにします。
Git integration guide · Cloudflare Pages docs

今回は、必要最低限のリポジトリのみアクセス可能な設定としました。

Cloudflare dashboard からデプロイ

最後に、上記のGit integration guideに従って Cloudflare dashboard を操作し、 Deploy a site from your account まで移動します。

その後は、以下の内容を選択・入力し、 Save and Deploy ボタンをクリックします。

項目	値
Github account	thinkAmi-sandbox
Select a repository	cf_service_binding_rpc-example
Project name	cf-service-binding-rpc-example (デフォルトのまま)
Production branch	main
Build Settings - Framework preset	None
Build Settings - Build command	bun install && bun run build
Build Settings - Build output directory	dist
Build Settings - Root directory - Path	packages/app-page
Build Settings - Environment variables	(なし)

　
するとビルドが進行し、デプロイまで正常に完了しました。

Connect to project ボタンを押した後、数分待ち、アプリが展開されるのを待ちます。
(展開されるまでは「このサイトにアクセスできません」な旨が表示されます)

動作確認

アプリの展開が完了後、 Visit site をクリックして Pages で作ったサイトへ遷移すると、 Hello my worker! が表示されました。

セキュリティ面から Named entrypoint を使うように修正する

ここまで、RPCで使う Worker のentrypointは、default export したクラスでした。

ただ、Cloudflareのブログによると、default export した entrypoint ではなく、 named export して named entrypoint を使ったほうがセキュリティが向上するようです。

n the past, service bindings would bind to the "default" entrypoint, declared with export default {. But, the default entrypoint is also typically exposed to the Internet, e.g. automatically mapped to a hostname under workers.dev (unless you explicitly turn that off). It can be tricky to safely assume that requests arriving at this entrypoint are in any way trusted.

　

With named entrypoints, this all changes. A named entrypoint is only accessible to Workers which have explicitly declared a binding to it. By default, only Workers on your own account can declare such bindings. Moreover, the binding must be declared at deploy time; a Worker cannot create new service bindings at runtime.

　
We've added JavaScript-native RPC to Cloudflare Workers

　
そこで、Named entrypoint を使うよう、Workers と Pages を修正します。

Workers の修正

WorkerEntrypoint を継承したクラス MyWorkerEntrypoint は named export するように修正します。

ただ、Workers として動かすためには、 fetch handlerは default export に含む必要があります。

そこで、fetch を MyWorkerEntrypoint のメソッドではなく default export の方へと移動しました。

なお、結果を分かりやすくするよう、hello メソッドの戻り値も Hello my named export worker! へと変更しています。

import { WorkerEntrypoint } from 'cloudflare:workers'

export class MyWorkerEntrypoint extends WorkerEntrypoint {
  async hello() {
    // biome-ignore lint: debug
    console.log('called worker!')
    return 'Hello my named export worker!'
  }
}

export default {
  async fetch() {
    return new Response('Hello Worker World!')
  },
}

Pages の修正

Pages では wrangler.toml に entrypoint を追加するよう修正します。

[[services]]
binding = "MY_WORKER"
service = "app-worker"

# Workersでexportされたクラス名を設定
entrypoint = "MyWorkerEntrypoint"  # 追加

動作確認

修正が終わったので動作確認します。

まずはローカルでの確認です。

ルートディレクトリで bun run dev した後、 http://localhost:5173/ を表示すると、 Workers からの戻り値が差し替わっていました。

named export での動作になっているようです。

　
続いて、WorkersとPagesをデプロイし、Cloudflare上で動作を確認してみます。

こちらも Workers からの戻り値が差し替わり、named export での動作になっていました。

　
以上より、 Service Bindings RPC を使った Pages と Workers の連携を一通り確認できました。

今回の記事を作るにあたり悩んだこと

ここまで書いてきた内容以外にも、いくつか悩んだところがあったため、メモとして残しておきます。

Service Bindings RPC 関係

Workersで使う WorkerEntryPoint クラスにはハンドラの実装が必要

Workers には以下のようなハンドラがあります。
Handlers · Cloudflare Workers docs

そのため、RPC向けのメソッドしか使わないWorkersであっても、WorkerEntryPoint クラスには何かしらのハンドラの実装が必要なようです。

もしハンドラを実装しない場合、ローカルでは正常に動作します。

一方、Cloudflare上へデプロイするときにはエラーが発生します。

$ bun run deploy

...
Total Upload: 0.21 KiB / gzip: 0.18 KiB

✘ [ERROR] A request to the Cloudflare API (/accounts/***) failed.

  The uploaded script has no registered event handlers. [code: 10068]
  
  If you think this is a bug, please open an issue at:
  https://github.com/cloudflare/workers-sdk/issues/new/choose


error: script "deploy" exited with code 1

　
そのため、今回の記事の WorkerEntryPoint では、以下のコミュニティページでも書かれているように、お手軽な fetch ハンドラを実装しました。
No event handlers were registered. This script does nothing - Developers / Workers - Cloudflare Community

Cloudflare dashboard 上では、Pages の Service Bindings が使えないような表示になる

Cloudflare dashboard 上で Pages の Settings > Functions とたどると、Service bindings があります。

ただ、現時点ではスクリーンショットのように

This Worker no longer exists and can not be used. Please try using a different Worker.

という表示になっています。

　
最初この表示を見た時は「Service Binding RPC の設定がうまくいっていないのかな...」と悩みました。

ただ、

実際には Service Bindings が使えていること
Cloudflareのdiscordで探したところ、2024/5/9時点で「表示バグであり、実際には使える」と書かれていたこと

から、自分の環境も表示バグなだけと判断しました。

Cloudflare dashboard + Github での Pages デプロイ関係

デプロイ時の Environment variables で Bun のバージョンを指定しても反映されない

デプロイ時の設定として Environment variables (advance) があります。

そのため、 wrangler.toml ではなく、ここに BUN_VERSION に 1.1.12 を指定しても良さそうです。

しかし、

Environment variables に BUN_VERSION を指定
wrangler.toml には BUN VERSION を指定しない

という場合は、デフォルトのBunのバージョンが利用されます。

デプロイログの途中には Build environment variables: (none found) と出ているの気になりますが。。

2024-06-15T02:57:57.922697Z  Cloning repository...
...
2024-06-15T02:58:00.466151Z Found wrangler.toml file. Reading build configuration...
2024-06-15T02:58:00.471401Z pages_build_output_dir: dist
2024-06-15T02:58:00.471716Z Build environment variables: (none found)
2024-06-15T02:58:00.577156Z Successfully read wrangler.toml file.
2024-06-15T02:58:00.737961Z Detected the following tools from environment: bun@1.0.1, nodejs@18.17.1
2024-06-15T02:58:00.738593Z Installing project dependencies: bun install --frozen-lockfile
2024-06-15T02:58:00.995652Z bun install v1.0.1 (31aec4eb)
...

Bun workspace を使っている場合、Build command には bun install も含めた方が良さそう

上記の説明では bun install && bun run build を指定していました。

ただ、元々は bun run build を使おうとしました。

しかし、 Bun の workspace を使っていることもあり、必要なパッケージが存在していない状態だとデプロイエラーになってしまいます。

例えば、以下の例では vite が見当たらないためにデプロイエラーになりました。

2024-06-15T02:15:35.790971Z  Cloning repository...
...
2024-06-15T02:15:39.536526Z Detected the following tools from environment: bun@1.1.12, nodejs@18.17.1
2024-06-15T02:15:39.537111Z Installing bun 1.1.12
2024-06-15T02:15:39.67107Z  Downloading Bun v1.1.12...
2024-06-15T02:15:40.784889Z Archive:  /tmp/asdf-bun.nxn8/bun.zip
2024-06-15T02:15:41.511631Z   inflating: /opt/buildhome/.asdf/downloads/bun/1.1.12/bun  
2024-06-15T02:15:41.575948Z Installing Bun v1.1.12...
2024-06-15T02:15:41.669111Z Bun v1.1.12 is installed successfully!
2024-06-15T02:15:42.151087Z Executing user command: bun run build
2024-06-15T02:15:42.408963Z $ vite build
2024-06-15T02:15:42.412208Z /usr/bin/bash: line 1: vite: command not found
2024-06-15T02:15:42.412421Z error: script "build" exited with code 127
2024-06-15T02:15:42.414061Z Failed: Error while executing user command. Exited with error code: 127
2024-06-15T02:15:42.423082Z Failed: build command exited with code: 1
2024-06-15T02:15:43.330076Z Failed: error occurred while running build command

　
そこで、 Build commandの先頭で bun install を実行することにより、 bun.lockb などを生成してパッケージ不足にならないようにしています。

bun install が必要なことには以下の記事を見て気づきました。記事ではpnpmを使っていますが、Bunでも同じことが起きました。
Cloudflare Pagesでpnpmを使ってデプロイする

Cloudflare dashboard + Github でデプロイできるのは、2024/6時点では Pages だけ

Cloudflare dashboard の表示を見ると、Pagesタブにしか Github 連携できる表示がありません。

　
また、monorepo のページも Pages のドキュメントにしかありません。
Monorepos · Cloudflare Pages docs

ただ、 Workers のディレクトリを指定したらどうなるのか気になりました。

　
そこで、 app-worker のディレクトリを指定して Cloudflare dashボードからデプロイしてみました。

すると、途中で色々Skipはされたものの、Workerのソースコードのデプロイ自体は成功しました。

2024-06-15T02:05:07.299536Z  Cloning repository...
...
2024-06-15T02:05:09.881621Z Found wrangler.toml file. Reading build configuration...
2024-06-15T02:05:09.980638Z A wrangler.toml file was found but it does not appear to be valid. Did you mean to use wrangler.toml to configure Pages? If so, then make sure the file is valid and contains the `pages_build_output_dir` property. Skipping file and continuing.
2024-06-15T02:05:10.060341Z No build command specified. Skipping build step.
2024-06-15T02:05:10.061276Z Note: No functions dir at /functions found. Skipping.
2024-06-15T02:05:10.061419Z Validating asset output directory
...
2024-06-15T02:05:19.424876Z Success: Your site was deployed!

　
しかし、デプロイ後のdashboardを見ると Pages として認識されているようでした。

　
当然、この状態では Workers として正常に動作していません。

ということで、2024/6時点では Workers は Wrangler でデプロイするのが良さそうでした。

　
ちなみに、Cloudflareのアナウンスによると、2024年の後半にはWorkersでもGithubからデプロイできるようになるかもしれません。

While today’s launch represents just a few of the many upcoming additions to converge Pages and Workers, we also wanted to share a few milestones that are on the horizon, planned later in 2024

...

Workers CI/CD. Later this year, we plan to bring the CI/CD system from Cloudflare Pages to Cloudflare Workers. Connect your repositories to Cloudflare and trigger builds for your Workers with every commit.

　

https://blog.cloudflare.com/pages-workers-integrations-monorepos-nextjs-wrangler