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. Answers only requests addressed to a trusted host (see below).
`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.

Trusted hosts

Because single_user needs no credential, it only answers requests addressed to a host you have vouched for: localhost and loopback addresses, the host of base_url, a concrete bind address, and anything you list in [server] allowed_hosts (or RILBO_ALLOWED_HOSTS, comma-separated). Anything else gets 403 untrusted host. The same rule covers the first-run setup page on a local install and a local /metrics.

Signed-in password and token_only deployments, API tokens, the MCP endpoint, uploads and health checks are not affected. If you run single_user and reach it by a LAN address or a local alias, add that name:

[server]
allowed_hosts = ["my-laptop.local", "192.168.1.5"]

This stops a web page that tricks your browser into addressing Rilbo under the page's own name (DNS rebinding) from acting as you. It does not protect against other programs running on the same computer — use password mode for that.

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.