The hosted service keeps the run log, comments on pull requests and sends notifications on every plan. On Free it runs the same free rules the CLI bundles; the rest of the corpus and tier-2 live-schema context (--db, stored connections) need Startup or above. It authenticates with a team token; the token is shown once, at creation.
Sign in with GitHub — the OAuth request carries no scopes beyond public identity.- Create a token: the first-run wizard at
/app/onboardingwalks you through it, or open Team → Tokens (/app/team/tokens) any time. It starts withblv_. - Add it to the repository as the
BOLVRK_TOKENsecret (Settings → Secrets and variables → Actions). - Invite teammates from Team → Members — invite links are valid for 7 days.
- Optional, Startup and above: add a stored connection under Connections and pass its id as
connection-idfor live-schema checks in CI.
A stored connection exists for one reason: the GitHub Action runs on a runner that usually cannot reach your database, so the service opens the connection on its behalf. It is used only during a check (and a 15-minute reachability probe), inside a READ ONLY transaction with a statement timeout, to read catalog metadata from pg_catalog and the pg_stat views: table and column names, column types, row-count estimates, indexes with their usage counters, foreign keys, per-table write and scan counters, server version. Never a row of data, never a SELECT on your tables, never a write. The connection string is sealed-box encrypted at rest with a key held only by the running API, opened for the duration of a check, never logged, and shown only in masked form afterwards. Point it at a read-only replica or shadow database with the catalog-only role from the setup guide (/app/onboarding/role). If you would rather keep credentials on your side, the CLI with --db … --remote introspects locally and sends only the same metadata — see the --remote and --db page.
Protected databases
A protected database is the production database a connection stands in for. Register one by name under Connections, then assign each stored connection to it — several shadow or replica connections can point at the same database. The name is all the service holds; nothing is read from a connection string. Plans allow 1 on Startup, 5 on Team and unlimited on Scale. Deleting a database leaves its connections in place, unassigned.
Insights look back over the run log for a window set by the plan: 30 days on Startup, a year on Team, unlimited on Scale. It is a window, never a deletion — the run log itself is kept in full on every plan.