Beacon Platform Docs

Local Development

1 min read

Setup guide for running the Beacon Platform locally with remote or local bindings.

Use —remote to enable Workers AI and shared D1:

./scripts/dev-local.sh

Or:

cd apps/pulse-ingest && pnpm dev --remote
cd apps/pulse-public && pnpm dev --remote

Sources: beacon-platform/docs/local-development.md

Local vs remote modes

  • —remote: uses remote D1, R2, AI, Queues (recommended).
  • —local: uses local D1/R2; AI not supported; each worker has its own D1.

Sources: beacon-platform/docs/local-development.md

Migrations

With —remote, apply once:

cd apps/pulse-ingest
npx wrangler d1 execute beacon-pulse-db --remote --file ../../packages/db/migrations/<migration>.sql

With —local, apply per worker:

cd apps/pulse-ingest
npx wrangler d1 execute beacon-pulse-db --local --file ../../packages/db/migrations/<migration>.sql
 
cd apps/pulse-public
npx wrangler d1 execute beacon-pulse-db --local --file ../../packages/db/migrations/<migration>.sql

If your local preview database is behind the current schema, admin and source endpoints can fail in ways that look like app bugs, for example no such column errors from /pulse/sources.json or /admin/sources. When that happens, bring both local D1 databases up to date before debugging the UI.

Sources: beacon-platform/docs/local-development.md

Mocking Workers AI (optional)

If running local mode, create a mock AI binding and inject it when env.AI is missing.

Sources: beacon-platform/docs/local-development.md

Graph View

Backlinks