アプリを作る

Cloudflare にデプロイする

Hane のアプリを、BFF の Worker と静的なアセットとして Cloudflare Workers に載せ、前に Cloudflare Access を置いて公開する方法です。

このページでは、Hane の上に作ったアプリを Cloudflare Workers にデプロイする一般的な形を説明します。参照アプリと同じく、1 つの Worker が BFF と画面のファイルの両方を返し、前に置いた Cloudflare Access がログインを受け持ちます。

形

利用者のブラウザ
   │  Cloudflare Access（ログイン）
   ▼
アプリの Worker
   ├─ /bff/*・/auth/*・/healthz → BFF（Access のトークンを Hane でトークン交換）
   └─ それ以外 → 静的なアセット（画面）。CSP を付けて返す
   │
   ▼
Hane の公開 API（入口）

Worker は Hane の内部の binding を持たず、公開の URL で入口を呼びます。顧客アプリはいつも公開 API だけを使います。
セッションは持ちません。Access が要求に付ける利用者のトークン（Cf-Access-Jwt-Assertion）を id_token としてトークン交換し、得たアクセストークンを、同じ Access のトークンの間だけメモリで使い回します。

手順

画面をビルドする

vite build --config app/vite.config.ts   # app/dist に出る

Worker の入口を書く

BFF の口（Hono など）に、Access のトークンでセッションを引く関数を渡します。API の口にないパスだけを静的なアセットに渡します。

export default {
  fetch(req: Request, env: Env, ctx: ExecutionContext) {
    const app = createApp(env); // /bff/* と /auth/* の口
    app.get("*", (c) => {
      const path = c.req.path;
      if (path.startsWith("/bff/") || path.startsWith("/auth/")) return c.notFound();
      return env.ASSETS.fetch(c.req.raw);
    });
    return app.fetch(req, env, ctx);
  },
};

Access のトークンにメールアドレスがない要求（サービストークンで通った要求）は、利用者がいないので、ログインしていないものとして扱います。

wrangler の設定を書く

{
  "name": "my-hane-app",
  "main": "bff/worker.ts",
  "compatibility_date": "2026-10-01",
  "assets": {
    "directory": "app/dist",
    "binding": "ASSETS",
    "not_found_handling": "single-page-application",
    "run_worker_first": true
  },
  "vars": {
    "HANE_API": "https://<Hane の入口の URL>",
    "HANE_ORG": "acme",
    "HANE_PROJECT": "fleet",
    "HANE_ENV": "prod"
  }
}

run_worker_first で、すべての要求をまず Worker が受け、画面にも CSP を付けられます。

秘密値を入れる

アプリのサービスアカウントの API キーを、Worker の secret に入れます。コードと wrangler の設定には書きません。
ターミナルウィンドウ
```
npx wrangler secret put HANE_API_KEY
```
Hane の入口の前にも Cloudflare Access がある環境では、入口を通るための Access のサービストークンも secret に入れ、入口へのすべての要求に cf-access-client-id・cf-access-client-secret のヘッダーを付けます。
デプロイする
ターミナルウィンドウ
```
npx wrangler deploy
```
Cloudflare Access で覆う

Zero Trust のダッシュボードで、Worker のホスト名を覆う Access のアプリケーションを作り、ログインの方法と通す人の方針を決めます。ログアウトは /cdn-cgi/access/logout です。
確かめる

BFF に /healthz?gateway=1 を用意しておくと、BFF から Hane の入口に届くかを {"ok":true,"gateway":200} で確かめられます。最後に、組織のメンバーの利用者でログインし、画面が開くことを確かめます。メンバーでない人は、トークン交換で FORBIDDEN になります。

環境を分ける

環境ごとに、別のサービスアカウントと API キーを作ります。API キーは 1 つのプロジェクトと環境に結び付いています。
HANE_ENV などの値は wrangler の環境ごとの設定で替え、コードには環境の違いを書きません。
定義は、dev で確かめた ReleaseBundle を hanectl release promote で stage・prod に昇格します。prod の有効化は人が自分のログインで行います（hanectl）。

Hane に配信を任せるプレビュー

自分の Cloudflare のアカウントを使わず、Hane にアプリを配信させる形も用意しています。

形	中身
静的なアプリ	`hanectl app create` でひな形を作り、`hanectl app deploy` でファイルを置く
アプリコンテナ	コンテナのイメージを公開ゲート・脆弱性の照合・署名に通して登録し、`Application` の定義で固定する。アプリの前段がトークン交換をして、短命のアクセストークンを要求ごとに渡すので、コンテナは API キーを持たない

どちらも提供の範囲と手順が変わる可能性があります。使う前に提供元に確かめてください。

次に読む

アプリの構成BFF と画面の分け方

認証トークン交換とスコープ

セキュリティ資格情報の扱い

Cloudflare にデプロイする

形

手順

環境を分ける

Hane に配信を任せる プレビュー

次に読む

Hane に配信を任せるプレビュー