Connect Pro grades your migrations and queries against your real database, read-only and on demand. When that database isn't reachable from the internet (on-prem, a private VPC, a locked-down subnet) the bridge closes the gap: a tiny agent you run inside your own network computes derived statistics and pushes them outbound. SIXTA never dials in.
The bridge opens one short read-only session against your database, computes derived statistics, and pushes them to https://connect.sixta.ai over HTTPS. There is no inbound port, no tunnel, and no remote control channel: it listens on nothing and accepts no commands from anywhere, including from SIXTA. It pushes once on start and then on a cadence the server suggests (about every 10 minutes), and nothing more. Your database credentials never leave the process.
Engine and version, whether the endpoint accepts writes, replication lag, and per table: size, row estimate, index and constraint metadata, and average read and write rates. Object names and numbers, computed inside the bridge.
No rows. No column values. No query text. No usernames, hostnames, or credentials. The only statements the bridge can run are a fixed allowlist of catalog queries, pinned by its test suite to match the server-side collector, so nothing it runs is influenced by input.
Run npx @sixta/bridge --dry-run to print the exact payload that would be sent, with no network call and no token, before you deploy anything.
In the portal, add a connection and choose the self-managed (agent) option to get a connection token. Create a read-only database user, then run the bridge anywhere inside your network that can reach both the database and the internet:
SIXTA_BRIDGE_TOKEN=sk_sixta_bridge_... \ SIXTA_BRIDGE_DB_URL=postgres://sixta_bridge:...@db.internal:5432/app \ npx @sixta/bridge
Requires Node.js 20 or newer. It logs one line per push (sizes and table count, never secrets) and runs cleanly under systemd or Docker. The token is revocable in the portal at any time; revoking it stops ingestion immediately.
The bridge needs catalog visibility only. On PostgreSQL that is pg_monitor plus CONNECT; on MySQL, REPLICATION CLIENT and SELECT, TRIGGER on the app schema, plus an optional performance_schema read for table activity rates. PROCESS is deliberately not required, so the account cannot read other sessions' SQL. Every session it opens is read-only and time-bounded on top of the grant. The repo README has the exact grants and every configuration option.
The bridge is one plain JavaScript file with no build step, so you can read every statement it will ever run before you deploy it. The source is public on GitHub and ships verbatim on npm as @sixta/bridge. This is the same data-handling promise as Connect Pro's direct connection, enforced by the same snapshot schema and size caps on the server.