Live demo

The live demo is a Try the live demo button that opens the real dashboard, signed in to a sample organization, for anyone. railhook.io uses it; a self-hosted install has it only if you turn it on.

What a visitor gets

The demo is one organization, Acme Inc., with one project, Acme Shop:

• four endpoints with subscriptions, one of which fails now and then, so there are retried deliveries and a Failed Messages entry;
• a Stripe source and a GitHub source, with verified incoming events forwarded to their destinations;
• about a day and a half of traffic, so the dashboard and analytics always show the last 24 hours.

A visitor can open and read every screen, and change nothing.

Why it is off by default

The demo hands a session to anyone who asks. On a deployment for your own team that is an anonymous way in with no purpose, so with DEMO_ENABLED=false (the default):

• no demo organization is created, and a leftover one is removed;
• the entry points on the landing page, on /pricing and in the Developers menu are hidden;
• the session endpoint, POST /api/v1/public/demo/session, answers 404.

Turn it on

1. Set the variable in .env in the install directory, adding the line if it is not there:

   .env

   DEMO_ENABLED=true

2. Recreate the containers so both the API and the dashboard read it:

   ./railhook start

   The API creates the demo organization as it starts. The dashboard reads the same variable for its entry points.

3. Open /demo on your Railhook address. It opens a session and goes to the dashboard.

On Kubernetes, set both halves in the Helm values:

values.yaml

api:
  env:
    DEMO_ENABLED: "true"
ui:
  publicDemo: true

What keeps it read-only

A demo session is an access token for the demo organization with the Viewer role, and nothing more:

• The server refuses every change, not only the dashboard. Any method other than GET, HEAD or OPTIONS gets 403 on every endpoint (API keys, members, settings, billing, replay, sending events, portal sessions, connected apps, the visitor’s own profile). Exports are refused too, although they are reads. The only exceptions change nothing in the demo: signing out, opening a new demo session, and the public site’s contact form and webhook tester.
• It cannot be extended. There is no refresh token. It lasts DEMO_SESSION_TTL_MINUTES (30 by default), then the visitor returns to the landing page and can open a new one.
• It works only on the API. A demo token is not accepted anywhere outside /api/.
• Opening one is limited: ten sessions a minute per address, behind the registration CAPTCHA if configured (CAPTCHA_SECRET_KEY and CAPTCHA_SITE_KEY).
• Nothing is ever delivered. Every URL is on a reserved .example host, every delivery and forward is already finished, and the demo’s sources refuse incoming webhooks. The worker never has demo work to send.

Keeping it current

The API rewrites the demo’s history every DEMO_REFRESH_INTERVAL_MINUTES (60 by default), so it always ends at the present. The organization, endpoints and sources are created once; only events, deliveries and incoming events are replaced.

The platform admin overview does not count the demo’s organization, account or traffic, and its Failed Messages do not raise the webhook_dlq_depth alert.

Turning it off

Set DEMO_ENABLED=false and run ./railhook start. No new session can be opened and the entry points disappear; an open session lasts until it expires but finds the demo empty.

On start the API removes the demo: organization, account, project, endpoints, sources and all history. It deletes only rows with the demo’s own ids, which no other organization can have, and logs one line saying what it removed. Later starts do nothing. Turning the demo back on recreates it from scratch.

All three variables are in the configuration reference, the session endpoint in the API reference.