What Relium reads, what it stores, and what it never touches.

The short version

Relium is a hosted service. Your compiled dbt manifests and the review records Relium produces from them are transmitted to and stored by Relium. Your warehouse rows are not: warehouse evidence is gathered by a collector that runs in your own environment and submits aggregate metadata only.

What Relium receives

Three inputs, from three places you control.

1. Repository content, through the GitHub App

An administrator of your GitHub organisation installs the Relium GitHub App and chooses which repositories it may see. Relium reads pull request metadata and the SQL and dbt files those pull requests change, and it writes one check run and one comment per review. It can be uninstalled at any time from GitHub, which revokes that access immediately.

2. Compiled dbt manifests, through your CI

A step in your GitHub Actions workflow posts the manifest.json that dbt compile produces for the base and head commits, authenticated with a repository secret Relium issues to you. A dbt manifest describes your project's structure — model names, compiled SQL, dependencies, tests, exposures and configuration. It does not contain rows from your warehouse.

3. Aggregate warehouse metadata, through a collector you run

Warehouse evidence is optional and is available from the Starter plan. The collector runs in your environment, connects with read-only credentials that you hold and Relium never sees, and answers a bounded request for a specific set of tables. Adapters are read-only, restricted to an allowlist of tables, and bounded by timeout and cost.

What Relium stores

Relium keeps the review record: the decision, the findings and their evidence, the change plan and traced lineage, the manifests submitted for each attempt, and the audit trail of what was published to GitHub. These records are what make a review reproducible and auditable after the fact. How long they are retained is set by your plan — 7 days on Free, 90 days on Starter, and retained on Pro.

Delivery payloads sent to external systems have secrets and raw SQL redacted before they leave.

Credentials

• Your warehouse credentials stay in your environment. Relium never receives them and has no way to connect to your warehouse itself.
• The CI token Relium issues is shown to you exactly once. Only a hash of it is kept, so it cannot be recovered — if it is lost, you issue a new one, which revokes the old. Relium will never ask you to paste it back into the browser.
• GitHub access is held as a GitHub App installation, scoped to the repositories your administrator selected, and revocable from GitHub at any time.
• Payment details are never seen by Relium. Polar, our merchant of record, handles checkout and stores payment methods.

Authentication and access

Sign-in is handled by Clerk. Governance actions — anything that changes what Relium publishes on a pull request — additionally require a GitHub session, and Relium re-checks your live repository permission with GitHub on every one of them. What you can do in Relium is what you can do on the pull request; there is no separate permission model to keep in step.

Subprocessors

Relium uses the following third parties to operate the service.

Reporting a vulnerability

Relium does not yet publish an address for reporting a security issue, and this page will not print one that does not receive mail. If you have found something, please hold it privately until there is a channel to send it to rather than disclosing it publicly.

Questions this page does not answer

Some things are not settled here: a data processing agreement, a hosting region commitment, a completed vendor questionnaire. None of them exists yet, and this page would rather say so than publish a badge Relium has not earned.