Skip to main content
TextQL requires communication between your users’ browsers and the TextQL backend, and — depending on your deployment — between the TextQL deployment and a small set of external services. This guide explains configuring TextQL for various network environments, including proxies, firewalls, and security measures.
This page covers traffic into TextQL (browsers, proxies, firewalls) and egress from a TextQL deployment. For connectivity from TextQL to your databases and warehouses, see Network Integration Options and Database Network Configuration.

Proxy Configuration

Enterprise networks typically route traffic through proxy servers for security and monitoring purposes. TextQL supports most proxy setups, though certain configurations may interfere with streaming functionality.

Streaming Responses

TextQL streams chat and agent responses over the Connect protocol — long-lived HTTP requests whose responses arrive progressively (Content-Type: application/connect+json). Some corporate proxies buffer entire responses before forwarding them, which breaks streaming: chats appear to hang, then the full answer arrives all at once, or requests time out entirely. Embedded dashboards and data apps additionally use WebSocket connections to the TextQL host. Proxies that don’t pass WebSocket upgrades will show dashboards that never finish loading. If your organization routes TextQL traffic through a proxy, the proxy must support:
  • Streamed HTTP responses without response buffering
  • Extended connections without arbitrary timeouts (agent runs can be long-lived)
  • WebSocket connections to the TextQL host

SSL Inspection and DLP

Corporate proxies frequently perform SSL man-in-the-middle inspection to detect threats. This substitutes TextQL’s certificates with your proxy’s certificates. When traffic passes through Secure Web Gateways, SSL inspection, or DLP systems, you may encounter timeouts, degraded streaming, or failures loading dashboards. This is a frequent deployment challenge for enterprise implementations. Since TextQL already enforces TLS 1.2+ end to end, excluding these domains from SSL inspection is recommended:
  • app.textql.com
  • *.textql.com (single-tenant deployments run on a dedicated subdomain, e.g. <yourcompany>.textql.com)
  • textqlusercontent.com and *.textqlusercontent.com
Should organizational policy mandate universal SSL inspection, your proxy infrastructure must meet the streaming requirements above — in particular, disabled response buffering and WebSocket passthrough for TextQL domains.

Testing Proxy Connectivity

Connection problems can be diagnosed with curl commands from an affected user’s machine. Basic connectivity and SSL inspection test:
curl -v https://app.textql.com 2>&1 | grep -C1 issuer
Output indicates the active SSL certificate. If your proxy provider appears as the issuer instead of a public certificate authority, SSL inspection is enabled for TextQL traffic. Streaming test: Open a chat and ask any question. If no text appears for a long period and the full answer then arrives at once, your proxy is buffering streamed responses — work with your network team to disable buffering for TextQL domains.

Domain Allowlisting

Networks employing domain- or IP-based access restrictions should permit TextQL traffic using domain patterns rather than static IP addresses, which may change periodically. Allow traffic to these domains for all users:
DomainPurpose
app.textql.comApplication and API (managed cloud)
<yourcompany>.textql.comApplication and API (single-tenant deployments — replace <yourcompany> with your subdomain)
textqlusercontent.com / *.textqlusercontent.comUser content — uploaded files, chart previews, and interactive reports, served from an isolated origin
hermes.textql.comProduct analytics (managed cloud)
mercury.textql.comProduct analytics (managed cloud, EU)
docs.textql.comDocumentation
textql.comMarketing site and login links
If you use SSO, your identity provider (Okta, Entra ID, Google) must also be reachable during login.

Private Connectivity

Enterprise customers who need traffic to stay off the public internet can use private connectivity, including AWS PrivateLink and VPC peering, with a managed single-tenant deployment — queries from TextQL’s compute engine to your data sources travel over the cloud backbone and never traverse the public internet. For organizations that require everything inside their own perimeter, TextQL is fully self-hostable via Helm chart. A self-hosted deployment automatically inherits:
  • Your network security group policies
  • Your firewall regulations
  • Your DNS settings
  • VPN or private network accessibility
This architecture allows TextQL to reach internal systems accessible from within your network while respecting existing network controls. See Network Integration Options for a comparison of the three deployment models.

Self-Hosted Deployment Egress

A self-hosted TextQL deployment needs outbound access to a small set of external services. Allow egress to:
DomainPurpose
registry-1.docker.ioHelm chart (OCI) and container images
console.textql.comTextQL Console — managed LLM gateway, licensing, and deployment telemetry
api.anthropic.com / api.openai.comOnly when using direct provider API keys instead of the Console gateway
hermes.textql.com or mercury.textql.comOnly when product analytics is enabled — most VPC and single-tenant deployments leave it disabled
Depending on which integrations you enable, additional egress may be required (e.g. slack.com for the Slack integration, your email provider for notifications, and your cloud provider’s storage and secrets endpoints).
LLM inference can be routed through the TextQL Console gateway, directly to a model provider with your own API keys, or through your cloud provider (e.g. AWS Bedrock) — see Inference Options for the tradeoffs.

Encryption

TextQL implements encryption for data moving through networks and stored in systems.

In Transit

  • TLS 1.2 minimum for all TextQL service connections
  • TLS for third-party AI provider communications

At Rest

  • AES-256-GCM encryption for connector credentials and organization secrets
  • Encrypted storage for persistent data
For the full picture, see the Security Whitepaper.

Troubleshooting Checklist

Diagnose connection problems systematically:
  1. Test app.textql.com (or your single-tenant hostname) connectivity from an affected machine
  2. Determine if SSL inspection is active; exclude TextQL domains if possible
  3. Confirm streamed chat responses arrive progressively, not all at once
  4. Confirm dashboards load (WebSocket passthrough)
  5. Confirm your firewall permits the TextQL domains listed above
  6. Review proxy system logs for errors
  7. Test from an external network (e.g. a mobile hotspot) to differentiate environmental issues
Most connection challenges involve proxy buffering of streaming responses. Collaborate with network administrators to disable buffering for TextQL domains or implement proper streaming support.

Enterprise Network Support

Contact support@textql.com for deployment assistance and dedicated support.