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’s egress guard that RFC1918 / link-local addresses are legitimate for this connector. Cloud-metadata endpoints (169.254.169.254, etc.) stay hard-blocked regardless — those are never the right destination.
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 list — the range is region-specific and updated when we add a region.
We don’t publish the egress IPs on the marketing site for two reasons: they change as we add regions, and the canonical source-of-truth list lives in the customer’s contract with us.
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 executor allow-list (which only emits SELECT for SQL connectors and a fixed set of read-only stages for MongoDB) is the actual write defence; 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 never logs credentials. Connection strings, passwords, and API keys are encrypted at rest with AES-256-GCM and decrypted only at query time — they never appear in logs, audits, or the prompts sent to the LLM.
See Security & Data Handling for the full picture.