> ## Documentation Index
> Fetch the complete documentation index at: https://docs.textql.com/llms.txt
> Use this file to discover all available pages before exploring further.
# Network Integration Options
> How TextQL connects to your data sources — choose the model that fits your network and compliance requirements.
TextQL supports three connectivity models. All three share the same security foundations — they differ only in where the infrastructure runs and how your data sources are reached.
Regardless of which option you choose, each thread in TextQL is backed by a single-tenant [sandcastle](https://textql.com/blog/sandcastles) — an isolated execution environment that does not persist data and only has access to what you configure.
## Comparison at a Glance
| Option | Managed by | Traffic path | IP allowlist | Data residency | Best for |
| ---------------------------------- | ---------- | --------------------------------- | --------------------- | ----------------------- | --------------------------------------------- |
| **1. Managed Cloud** | TextQL | Public internet (TLS) | Yes (`54.69.138.147`) | AWS us-west-2 only | Teams that can allowlist a static IP |
| **2. Single-Tenant + PrivateLink** | TextQL | AWS backbone (no public internet) | No | Flexible | Private networking or compliance requirements |
| **3. Self-Hosted** | You | Stays within your network | No | Fully controlled by you | Air-gapped or strict data residency |
## Option 1: Managed Cloud (Standard)
TextQL runs on shared infrastructure in AWS us-west-2, logically separated by organization. Your databases and warehouses are reached over the public internet via a fixed egress IP that you allowlist on your firewall or security groups.
**Egress IP to allowlist:**
```
54.69.138.147
```
All traffic is TLS 1.2+ enforced. Connector credentials (passwords, service account keys, connection strings) are encrypted at rest using AES-256-GCM.
**Region availability:** Standard runs in AWS us-west-2 only. If you have US East or EU data residency requirements, use Option 2 or Option 3.
**When it fits:** Teams that can allowlist a static IP, have no data residency constraints outside us-west-2, and don't require traffic to stay off the public internet.
***
## Option 2: Managed Single-Tenant with AWS PrivateLink
TextQL provisions a dedicated environment (separate compute, separate database) for your organization. Connectivity to your data sources is established via AWS PrivateLink — queries from TextQL's compute engine to your data sources travel over the AWS backbone and never traverse the public internet.
### How the connection is established
Because TextQL's compute initiates connections *to* your data sources, your team is the **service provider** and TextQL is the **service consumer** in PrivateLink terms. You either:
* Authorize TextQL's AWS account on your managed warehouse's PrivateLink connector (Snowflake, Databricks, etc.), or
* Expose a VPC Endpoint Service in front of a self-managed database.
The self-managed database path requires a one-time step to authorize TextQL's AWS account as a PrivateLink consumer.
In this model, the static IP allowlist from Option 1 is not required, and no traffic is exposed to the public internet at any hop.
### VPC peering as an alternative
VPC peering is supported as an alternative for organizations that already operate peered networks at scale. We recommend PrivateLink unless you have an existing peering-based architecture you need to fit into.
**When it fits:** Organizations that require private networking, dedicated infrastructure, and/or have compliance requirements around traffic egress or non-us-west-2 data residency.
***
## Option 3: Self-Hosted (Within Your Walls)
TextQL is fully deployable on your own infrastructure using Kubernetes (Helm chart), tested and supported on EKS.
Your team controls:
* **Where the application runs** — your VPC, your data center, or your cloud account
* **How secrets are managed** — AWS Secrets Manager, GCP Secret Manager, Azure Key Vault, or sealed secrets via GitOps
* **Network routing** — all outbound connections from TextQL's compute engine to your databases stay entirely within your network; no traffic leaves your perimeter
**When it fits:** Organizations with strict data residency requirements, air-gapped environments, or a policy that prohibits third-party cloud access to internal systems. Note that self-hosting requires your team to manage and maintain Kubernetes and carries a higher operational cost than the managed options.
See [VPC / Self-Hosted Deployments](/core/how-it-works/faq#vpc--self-hosted-deployments) in the FAQ for common setup issues, and the [Kubernetes README](https://github.com/textql/textql) for full deployment instructions.
***
## Security Baseline Across All Options
| Control | Detail |
| -------------- | --------------------------------------------------------------------------------------- |
| In-transit | All traffic is TLS 1.2+ enforced |
| At-rest | AES-256-GCM for connector credentials and organization secrets |
| Authentication | OIDC/SSO, API keys, session tokens |
| Authorization | Per-object RBAC (owner / editor / viewer); all queries org-scoped at the database layer |
| Audit logging | Every action logged with actor, resource, IP address, auth method, and timestamp |
For the full security overview, see the [Security Whitepaper](/core/admin/compliance/security).