BeaconAuth

Cloudflare deployment

Deploy the UI to Pages and the API to a Worker.

Overview

BeaconAuth supports a split deployment:

  • Cloudflare Pages for the React UI.
  • Cloudflare Worker (crates/beacon-worker) for the API.

The two deployments share the same project name (name) in both wrangler.jsonc and wrangler.workers.jsonc (CI enforces this).

Wrangler configs

  • wrangler.jsonc: Cloudflare Pages config (UI build output at dist/).
  • wrangler.workers.jsonc: Cloudflare Worker config (wasm build output).

CI workflows

  • .github/workflows/deploy-cloudflare-pages.yml deploys the UI.
  • .github/workflows/deploy-cloudflare-worker.yml deploys the API worker and applies migrations.

Required secrets (Pages)

  • CLOUDFLARE_API_TOKEN
  • CLOUDFLARE_ACCOUNT_ID

Optional:

  • SENTRY_AUTH_TOKEN

Required secrets (Worker)

  • CLOUDFLARE_API_TOKEN
  • CLOUDFLARE_ACCOUNT_ID
  • TURSO_PLATFORM_API_TOKEN
  • TURSO_ORG_SLUG
  • TURSO_DB_NAME

Optional:

  • TURSO_GROUP (defaults to default)
  • CLOUDFLARE_WORKER_BASE_URL (defaults to https://<name>.pages.dev)
  • CLOUDFLARE_WORKER_LIBSQL_URL (override libSQL URL instead of Turso API)
  • CLOUDFLARE_WORKER_LIBSQL_AUTH_TOKEN
  • CLOUDFLARE_MIGRATIONS_API_TOKEN (used for /v1/admin/migrations/up)
  • OAuth provider secrets (see below)

Optional Worker secrets for OAuth

  • CLOUDFLARE_WORKER_GITHUB_CLIENT_ID
  • CLOUDFLARE_WORKER_GITHUB_CLIENT_SECRET
  • CLOUDFLARE_WORKER_GOOGLE_CLIENT_ID
  • CLOUDFLARE_WORKER_GOOGLE_CLIENT_SECRET
  • CLOUDFLARE_WORKER_MICROSOFT_CLIENT_ID
  • CLOUDFLARE_WORKER_MICROSOFT_CLIENT_SECRET
  • CLOUDFLARE_WORKER_MICROSOFT_TENANT

Single-origin routing (optional)

If you want the UI and API to share a single origin, this repository already supports it via the Nitro server entry.

  • The server entry lives in src/server.ts.
  • Nitro generates the Cloudflare Pages worker bundle (_worker.js) automatically during build. No manual Pages worker entry file is required.
  • Ensure the Pages project has a service binding named BACKEND pointing to your API worker (see wrangler.jsonc).

By default, the server entry proxies requests whose path starts with /api/, /v1/, or /.well-known/ to env.BACKEND and serves the UI for everything else.

Notes

  • The Worker deployment uses libSQL/Turso (set LIBSQL_URL and LIBSQL_AUTH_TOKEN).
  • Migrations are applied via the Worker endpoint POST /v1/admin/migrations/up in CI.

On this page

OverviewWrangler configsCI workflowsRequired secrets (Pages)Required secrets (Worker)Optional Worker secrets for OAuthSingle-origin routing (optional)Notes