Skip to content

Dashboard UI

Pulse no longer runs the dashboard as a separate service. pulse-server serves the built dashboard UI from / and exposes the API and auth routes from the same origin.

Use one browser origin for everything:

  • / -> Pulse dashboard UI
  • /api/auth/* -> Better Auth session routes
  • /dashboard/api/* -> dashboard control-plane routes
  • /v1/* -> ingest and query APIs
  • /health -> service health

Example:

https://pulse.example.com/

This is the default and recommended deployment model because it avoids most cookie and CORS issues.

For a managed local install:

Terminal window
pulse setup --local
pulse up

Then open:

http://localhost:3000/

Set BETTER_AUTH_URL to the public origin of your Pulse server:

Terminal window
export BETTER_AUTH_URL='https://pulse.example.com'

Optional:

Terminal window
export FRONTEND_URL='https://pulse.example.com'

FRONTEND_URL is only needed when you intentionally run the frontend on a different origin during frontend development.

Run the server container directly. It already includes the built dashboard assets:

Terminal window
docker run --rm -p 3000:3000 \
-e BETTER_AUTH_SECRET="$(openssl rand -hex 32)" \
-e ENCRYPTION_KEY="$(openssl rand -hex 32)" \
-e BETTER_AUTH_URL='http://localhost:3000' \
ghcr.io/ek-labs-llc/pulse-server:<tag>

Then open:

http://localhost:3000/

Optional split-origin frontend development

Section titled “Optional split-origin frontend development”

For normal product deployments, do not split the frontend and API.

If you are actively developing the frontend separately, set:

Terminal window
export BETTER_AUTH_URL='https://api.example.com'
export FRONTEND_URL='https://app.example.com'

In that development-only setup:

  • the server still owns auth and API routes
  • the standalone frontend points API requests back to the server
  • production should return to the same-origin model

By default, pulse-server serves built dashboard assets from its bundled install paths.

Advanced override:

Terminal window
export DASHBOARD_DIST_DIR='/path/to/dashboard/dist'

This is mainly useful for development or custom packaging flows.