Roll it out across teams & environments

Getting from one engineer's laptop to an org-wide, always-current catalog is mostly about committing config and scheduling a re-scan — Regixo is a command you run, not a daemon you host. This page covers the unattended refresh, the CI recipe, keeping a hosted record fed, and how to handle multiple repos and environments. It ends with an honest account of what multi-entity does and doesn't do yet.

One laptop to org-wide

The move from a personal run to a repeatable org run is three commits:

1. Commit regixo.yml. With sources (by env-var name), intent, DORA scope and PII policy in the file, any machine — a colleague's or a CI runner — scans the same estate. Secrets stay in the environment.
2. Make it run headless. Off a TTY, in CI, or with --yes, every command runs non-interactively: it takes answers from flags, env and regixo.yml and never prompts. A committed config plus --yes is a fully unattended refresh.
3. Seed the shared standards. Commit a house glossary and PII policy once, then bring them in on each machine with regixo catalog import regixo-catalog.json (merge-only — it never downgrades a confirmed answer).

Schedule the refresh

regixo watch is a one-shot re-scan you schedule — from cron or CI — not a hosted daemon that sits running. Each run re-scans, updates the map, appends the change-log, and flags any signed activity whose core fields moved for re-sign. Two flags make it CI-native:

--ci

Prints the change summary as markdown to stdout (pipe it into $GITHUB_STEP_SUMMARY) and signals a core-field change with exit code 3 — plain watch keeps the historic 0/1, so existing scripts are unaffected.

--webhook <url>

POSTs the change report to a URL. The egress is announced first and carries names and change kinds only — never row values.

$ regixo watch --ci >> "$GITHUB_STEP_SUMMARY"

A ready-made GitHub Actions workflow ships in the repo at examples/github-actions/regixo-watch.yml — copy it, set your source secrets as Actions secrets, and a scheduled run posts its summary and fails the job on a core-field change.

The re-sign side of a scheduled change is walked in Keep it current.

Keep a hosted record current

Once a compliance lead has claimed a record on the portal, a paired regixo watch keeps it fed. Set REGIXO_SYNC_TOKEN (the ingest-only machine token an admin minted) in the environment and the same scheduled run pushes the refreshed, metadata-only draft to the portal:

$ export REGIXO_SYNC_TOKEN='rgx_sync_…'
$ regixo watch --ci

The push goes to POST /api/v1/sync authenticated by the token. It carries metadata only, and the token can only ingest — never unlock, sign or export. The record's “what changed” feed updates so the compliance team sees the estate moved without anyone re-forwarding a draft.

Multiple repos, environments & networks

Real estates aren't one flat database. Three patterns:

• Multi-repo / multi-service — give each repo its own committed regixo.yml scoped to the sources that team owns. Each produces its own map; you decide whether to run them as separate records or merge the maps.
• Prod vs staging — keep them as distinct sources (distinct ids and connectionRefs). Scanning staging is a safe way to preview a schema change before it reaches production and trips a re-sign.
• Inside-network map-merge — when a database can't be reached from where you'd normally run, run regixo start on a machine inside that network and merge the maps. It's the same “bring Regixo inside” route the coverage meter points to in Architect your catalog.

Honest limits: multi-entity is not built yet