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 — an isolated execution environment that does not persist data and only has access to what you configure.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.
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:
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.
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
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 |