How it works

Data flows one way: the collector inserts, the viewer selects. Nothing in the viewer can change a target, a manifest or the database.

Step 1
Fetch the manifests
The scheduled job fetches each service’s secrets.manifest.yml, which names its 1Password source and its targets.
Step 2
Pre-flight
Every service is checked against the reviewed allowlist: known fields only, platforms with a platform rule only, and identity fields pinned to the allow record. A service that fails is dropped; the rest continue.
Step 3
Probe the guard
Two credential-free probes run the pinned env-sync with an unknown and an empty platform scope and prove it refuses both. If the probe fails, the run stops with exit code 3 before any collection.
Step 4
Collect with scoped credentials
Each env-sync child gets a fresh empty HOME, the base floor, the credentials of the platforms in its scope, and ENV_SYNC_ALLOWED_PLATFORMS. The collector’s own DATABASE_URL never reaches it.
Step 5
Write one collector run
Each invocation becomes one collector run (success, partial or failed) with one drift snapshot per target, written in one transaction by the insert-only role.
Step 6
Read in the viewer
Behind the access gate, the viewer selects the latest snapshot per target, compares fingerprints on the server, flags stale targets and renders key names and states.

Exit codes

Exit 1: a collector run failed. Exit 2: a CI guard refused the inventory. Exit 3: a probe failed.

A failed target is recorded as an error snapshot with its reason, so it shows up in the viewer instead of disappearing.

env-sync-viewer is self-hosted: you run the collector and the viewer in your own infrastructure. Access to the repository is by request.