Configuration

Rilbo runs well with zero configuration. When you need more, configuration lives in a local file plus RILBO_* environment overrides — never in a cloud dashboard.

Authentication modes

Auth is free configuration, not a paid feature. Three modes ([auth] mode in the config file, or RILBO_AUTH_MODE):

Mode	Behaviour
`single_user` (default)	No login screen. Refuses to bind beyond localhost unless explicitly overridden — safe by default.
`password`	Login with email + password, sessions, CSRF protection. The setup wizard switches this on when you set a password.
`token_only`	No interactive login; every request authenticates with an API token. Good for headless/agent-only installs.

TOTP two-factor auth (RFC 6238, works with any authenticator app) can be enrolled in Settings → Security on any plan. Multi-user installs — seats, roles, member management — are a Team feature; the auth modes themselves work everywhere. What each role can actually do, and where the trust boundary sits, is in security & access.

Behind a reverse proxy

Terminating TLS at nginx/Caddy means the leg Rilbo itself serves is plain HTTP, so it cannot tell that the browser used TLS. Two settings tell it:

Setting	Why
`RILBO_BASE_URL=https://your.host`	The public origin. Decides the `Secure` flag on session cookies, and is what generated links and the same-origin check are built from.
`RILBO_TRUSTED_PROXY=1`	Makes login throttling per-client rather than per-proxy, and lets the proxy's `X-Forwarded-Proto` back up the `Secure` decision.

Set both. Without the first, sessions are issued without Secure; without the second, one attacker's failed logins throttle every user behind the proxy.

The same decision gates Strict-Transport-Security, controlled by RILBO_HSTS_MAX_AGE (default 86400 — one day). It is short on purpose: a browser that records the pin refuses plain http to the host until it expires, and the only early withdrawal is to serve RILBO_HSTS_MAX_AGE=0 over https. Raise it to 31536000 once you have seen the deployment answering over https.

Backups & data lifecycle

Your workspace is one SQLite file. Rilbo takes automatic backups, and the CLI makes the manual paths easy:

rilbo backup                  # timestamped snapshot + checksum
rilbo restore backup.db.zst   # put one back
rilbo export                  # portable compressed JSON (secrets omitted)
rilbo import json export.zst  # native import (also in Admin → Import)
rilbo doctor                  # health checks; --fix-auth for lockouts

Importers for Linear (JSON export) and GitHub Issues are built into the CLI: rilbo import linear-json … / rilbo import github-issues ….

Notifications

In-app notifications, email (direct SMTP) and Web Push are free; Telegram, Slack and generic webhooks are Pro. Per-channel controls include mutes (per issue, project, team or event type), quiet hours, and hourly/daily digests.

Operational endpoints

/healthz — liveness, version and schema for probes.
/metrics — Prometheus exposition: request counts, DB size, issue/user totals, notification queue depth.
SSE at /api/v1/events — the same live-update stream the UI uses.

Scraping `/metrics`

/metrics publishes business volume — database size, issue, project and active user counts, notification queue depth — so it is open only while Rilbo is confidently not reachable from off-host: a loopback bind with RILBO_TRUSTED_PROXY off. That is the default, and local scraping needs no configuration.

On any other deployment — a non-loopback bind, or a loopback bind you have declared to be behind a reverse proxy — the endpoint requires a credential and answers an unauthenticated scrape with 401 and WWW-Authenticate: Bearer. Two ways forward:

Option	What it does
Give the scraper a token	Create an API token (read scope is enough) and have Prometheus send `Authorization: Bearer …`. Recommended — the endpoint stays closed to everyone else.
`RILBO_METRICS_PUBLIC=1` (or `metrics_public = true` under `[server]`)	Serves `/metrics` unauthenticated anyway, for a deployment exposed only to a trusted network.

If a scrape that used to work starts returning 401 after an upgrade, this is why; the server also says so in its startup log, naming both options. RILBO_ALLOW_INSECURE=1 opens the endpoint too, but it is the blanket opt-out and additionally permits an unauthenticated single_user UI beyond localhost — prefer RILBO_METRICS_PUBLIC if metrics are all you meant to expose.