Connect your sources

Point Regixo at your real databases and SaaS. It reads the connection string from an environment variable you name — your secret never touches regixo.yml. This page covers every connector that’s actually built, the exact strings, and how to reach a locked-down database.

How connecting works

Each source is one entry in regixo.yml. The entry holds the name of the env var that carries the secret (connectionRef), never the secret itself. At scan time Regixo resolves the value from your environment. Two ways to add a source:

• Auto-detected — if a known env var is set, regixo start offers to add it for you (see Auto-detect).
• By hand — regixo add <type>, a wizard on a terminal or flag-driven when scripted.

SQL databases

One connector serves four drivers. Each reads a standard connection string from an env var:

Set the env var, then add the source (this example is Postgres):

$ export DATABASE_URL='postgres://readonly:••••@db.internal:5432/app'
$ regixo add postgres --ref DATABASE_URL --label "App DB" --region eu-central-1

✓ added source app-db (postgres) — reads from $DATABASE_URL
  Regixo stores only the variable NAME — your secret never touches regixo.yml.
  Scan it in now? [Y/n]

The resulting regixo.yml entry:

version: 1
sources:
  - id: app-db
    kind: sql
    driver: postgres
    label: Application database
    connectionRef: DATABASE_URL     # the env-var NAME, never the secret
    region: eu-central-1            # feeds the "transfers outside the EU" suggestion
    role: controller

Snowflake

Snowflake is reached over the SQL REST API — there's no TCP driver — and it's metadata-only: Regixo reads information_schema for tables, columns and types, never row values. One env var carries the whole connection, with the token as its only secret:

$ export SNOWFLAKE_URL='snowflake://ab12345/ANALYTICS?warehouse=WH_XS&role=REGIXO_RO&token=••••'
$ regixo add snowflake --ref SNOWFLAKE_URL

The token is a Programmatic Access Token by default; for an OAuth token add &token_type=OAUTH. A read-only role with USAGE on the database and warehouse is enough. As with every source, regixo.yml stores only the variable name — the token lives in your environment, never in the file (Hard Rule #6).

BigQuery

BigQuery is a metadata-only REST source: Regixo lists datasets and tables and reads each table's schema (nested RECORD fields are flattened), never row values. The env var holds a bigquery:// URL with your project id and one of two credentials:

$ export BIGQUERY_URL="bigquery://my-project?token=$(gcloud auth print-access-token)"
$ regixo add bigquery --ref BIGQUERY_URL

A short-lived OAuth token (token=) is easiest for a one-off scan; a service-account key file (key_file=) is durable, so it suits a scheduled regixo watch. A key-file path is not a secret, so it may sit in the URL — the token is, so it stays in the env var only, never in regixo.yml.

Stripe

Stripe is metadata-only: Regixo pings /v1/balance to check the key works, then maps a curated object schema (customer, charge, invoice, payment_method, subscription) so the classifier can flag fields like email and card_last4. It never fetches customer objects. Use a test-mode key.

$ export STRIPE_API_KEY='sk_test_••••'
$ regixo add stripe --ref STRIPE_API_KEY

Stripe is added with role: processor by default — it processes on your behalf.

dbt (lineage)

dbt isn’t a data source — it’s a lineage provider. Point Regixo at your compiled manifest.json and the warehouse source its models map onto, and Regixo adds the model-to-model ref graph as lineage. It reads no warehouse rows.

$ regixo add dbt --from target/manifest.json --target app-db

Describe a source by hand (CSV)

Can’t reach a system, or want to document one Regixo can’t connect to yet? Describe its schema in a CSV — no live system, no secret. This is the “never a dead end” path.

dataset,column,type,nullable
legacy_crm.contacts,email,varchar,false
legacy_crm.contacts,full_name,varchar,true
legacy_crm.orders,amount,decimal,false

$ regixo add manual --from schema.csv

Bring your own connector (any SaaS or internal API)

Don’t see your tool in the list? For any SaaS, or your organisation’s own internal API, you can stand up a connector with a coding agent. Unlike the CSV above it’s live:

• Re-scanned by regixo start / watch.
• Checkable with regixo test.
• Flags drift when the schema moves.

Open your agent (e.g. Claude Code) in the project and say “add <your tool> to Regixo”; it reads the playbook and wires it up:

$ regixo connectors --skill

The playbook’s core is an interview: a private/internal API has no public docs the model knows, so the agent asks you how it authenticates and what its objects/fields are (or reads an internal OpenAPI spec / a sample response) — then authors the connector. Everything runs out-of-process: Regixo never imports or runs the authored code inside itself. How it works:

A generator script (script) — works for any source

The agent writes a small script in regixo-connectors/ that prints your schema (the same CSV/JSON as above). Regixo runs it as a subprocess each scan and ingests only the printed schema — never row values. Name the token env var after the tool (HUBSPOT_TOKEN), not a generic name.

say

“Write a Regixo connector for our orders API and register it.”

Copy

🔑Your agent fills in everything except the token — you put that in .env yourself.

Show the commandHide the commandShow the sentenceHide the sentence

run

$ regixo connectors new orders-api     # scaffold regixo-connectors/orders-api.mjs
$ regixo add script --generator regixo-connectors/orders-api.mjs --id orders-api --ref ORDERS_API_TOKEN

regixo add — the flags

On a terminal, regixo add with no type opens a picker (Databases · SaaS · Import from a file). Headless, pass the type and flags. It writes config only — the headless path never scans; run regixo start after.

Remove a source

Two built-in ways, depending on whether you want to drop one source or wipe everything. Both are Regixo’s own commands. Neither touches your database — the scan only ever read metadata — and neither deletes your secret.

Remove one source

regixo sources remove <id> is the exact undo of an add: it drops the source from regixo.yml and clears its datasets, personal-data flags and lineage from the map, so the map stays honest. Because that erases mapped data, it asks first — confirm with --yes:

$ regixo sources remove myfintech1 --yes

✓ removed source "myfintech1"
  cleared its datasets from the map
  the map refreshes on the next regixo start

Without --yes it prints what would happen and stops — a scanned source warns that its mapped tables + personal-data flags will be erased; a never-scanned source says it’s safe (nothing is mapped yet).

• Don’t know the id? regixo sources lists them (it works before any scan too).
• Removing your last source is fine — the next regixo start simply offers to connect one again, like a fresh folder.
• To undo a removal, re-add the source and run regixo start; nothing about your database changed.

Start over — wipe everything

To remove every source, the whole map and the draft record in one motion, delete the local folder Regixo wrote in this project:

$ rm -rf .regixo

.regixo/ holds the catalog (index.db), the drafts, and the auto-generated regixo.yml. Deleting it is a clean slate: the next regixo start is a brand-new first run.

Your .env sits outside .regixo/, so it survives — delete it by hand if you want the connection string gone. Same for a regixo.yml you keep at the project root yourself: that one is outside .regixo/ too, so remove it separately.

Auto-detect

On a first run with no regixo.yml, regixo start looks for these env vars and offers to add what it finds: DATABASE_URL, MYSQL_URL, REDSHIFT_URL, SQLSERVER_URL, STRIPE_API_KEY. It also reads the variable names (never the values) from a local .env, so a source shows up even if the value is only exported at runtime. File sources (CSV, dbt) are never auto-detected — add those by hand.

How secrets are resolved

At scan time Regixo resolves each source’s connectionRef in order:

1. The env var named exactly by connectionRef (e.g. DATABASE_URL).
2. REGIXO_SECRET_<REF> as a fallback.
3. Otherwise a SECRET_UNRESOLVED error naming the variable to set.

When a database can’t be reached

A partial scan is fine — an unreachable source is marked and coverage stays honest (“4 of 6 reachable”). To bring the rest in, there are three real routes:

• Bring the key — set up your own VPN or SSH tunnel, then give Regixo a connection string that reaches through it in the normal DATABASE_URL. There is no --tunnel flag — Regixo just needs a reachable host.
• Bring Regixo inside — run regixo start on a machine inside the network and merge the maps.
• Describe it — import a CSV of the schema.

Verify & troubleshoot

Dry-run every connection (checks credentials + reachability, no scan):

$ regixo test

✓ app-db — connected
✗ stripe — Stripe rejected the API key (401) → fix: regixo doctor
1/2 source(s) failed

Turn any problem into a fix:

$ regixo doctor

It resolves each env var and actually probes the connection (the same probe as regixo test, so they never disagree), then prints a specific fix.

Full list: Errors & fixes.