Klairr connects to your database from its hosted control plane. This page is the canonical reference for how that connection is made — the egress posture, the supported connection methods, and the TLS requirements that apply to every database connector.
Linked from every connector setup guide. If a step in a guide says “see Network Access”, this is the page.
Connection methods
Each database connector supports one or more of the following:
Public endpoint (default)
The simplest setup. Your database has a routable public hostname; Klairr dials it directly. Choose this when:
- Your database is hosted by a cloud provider that exposes a public endpoint (Atlas, RDS, Cloud SQL, Snowflake, BigQuery, etc.).
- You’re comfortable allowlisting Klairr’s egress IPs at your firewall — see below.
- TLS is enabled on the database (required).
Private network (VPC peering, VPN, PrivateLink)
For databases that are only reachable through a private network. Available on every self-hostable connector (PostgreSQL, MySQL, MongoDB, Redshift, Databricks, ClickHouse) via the “Host is on a private network” option in the setup form.
Setting the option to “Yes” tells Klairr that private-network addresses are legitimate for this connector. Klairr’s hosted control plane prevents any customer-supplied connector host from reaching Klairr-internal infrastructure.
You’re responsible for the private route itself. Klairr supports:
- VPC peering — your cloud account is peered with Klairr’s egress VPC.
- VPN tunnel — Klairr egresses through a VPN you’ve configured (contact support for the supported endpoints).
- PrivateLink (AWS) / Private Service Connect (GCP) / Private Link (Azure) — managed private endpoints. Available on selected plans; contact support to provision.
If you don’t have a private route configured yet, leave the option as “No” and use a public endpoint.
SSH tunnel (planned)
For databases that have neither a public endpoint nor a private peering. Roadmap — not yet available. Contact support if you need it.
TLS requirements
Every connector requires TLS by default:
- TLS 1.2 or higher — TLS 1.0 and 1.1 are rejected.
- Certificates are validated. Self-signed certs require an explicit “Verify-full” → “Require” downgrade in the connector setup form, scoped to that one connector.
- Klairr verifies certs against the system root store; cert pinning is not supported.
If your database doesn’t speak TLS, fix that before connecting — most managed services have it on by default.
Egress IPs (allowlist)
If your firewall, security group, or database network policy restricts inbound by IP, you’ll need to allowlist Klairr’s egress range. Contact support for the current allowlist for your tenant.
Read-only credentials
Klairr’s connect-time probe verifies that the database credentials you supply cannot perform writes. The probe runs once at setup, attempts a no-op write inside a rolled-back transaction (or the equivalent for non-relational stores), and brands the credentials as read-only when the write is rejected.
If your role has write access — common in dev environments and managed databases that conflate read and write grants — you can set “Allow writable role” to “Yes” in the setup form. Klairr’s query executor enforces read-only semantics regardless of the underlying database role; the connect-time probe is belt-and-braces. The acknowledgement is recorded on the connector for audit.
What Klairr never does
- Klairr never opens an inbound port on your network.
- Klairr never copies your data to its own storage. Queries run against your database; result rows are streamed back, used to compose an answer, and persisted only as part of the question’s audit trail.
- Klairr does not log credentials. Connection strings, passwords, and API keys are encrypted at rest and decrypted only at query time — they do not appear in logs, audits, or the prompts sent to the AI model.
See Security & Data Handling for the full picture.