> ## 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 Configuration

> Configure proxies, firewalls, and SSL inspection so your network can reach TextQL

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.

<Info>
  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](/core/admin/compliance/network-integration) and [Database Network Configuration](/core/datasources/databases/network-configuration).
</Info>

## 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:**

```bash theme={null}
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:

| Domain                                              | Purpose                                                                                                |
| --------------------------------------------------- | ------------------------------------------------------------------------------------------------------ |
| `app.textql.com`                                    | Application and API (managed cloud)                                                                    |
| `<yourcompany>.textql.com`                          | Application and API (single-tenant deployments — replace `<yourcompany>` with your subdomain)          |
| `textqlusercontent.com` / `*.textqlusercontent.com` | User content — uploaded files, chart previews, and interactive reports, served from an isolated origin |
| `hermes.textql.com`                                 | Product analytics (managed cloud)                                                                      |
| `mercury.textql.com`                                | Product analytics (managed cloud, EU)                                                                  |
| `docs.textql.com`                                   | Documentation                                                                                          |
| `textql.com`                                        | Marketing 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](/helm-charts/installation). 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](/core/admin/compliance/network-integration) 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:

| Domain                                      | Purpose                                                                                           |
| ------------------------------------------- | ------------------------------------------------------------------------------------------------- |
| `registry-1.docker.io`                      | Helm chart (OCI) and container images                                                             |
| `console.textql.com`                        | TextQL Console — managed LLM gateway, licensing, and deployment telemetry                         |
| `api.anthropic.com` / `api.openai.com`      | Only when using direct provider API keys instead of the Console gateway                           |
| `hermes.textql.com` or `mercury.textql.com` | Only 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).

<Note>
  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](/core/admin/compliance/inference-options) for the tradeoffs.
</Note>

## 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](/core/admin/compliance/security).

## 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](mailto:support@textql.com) for deployment assistance and dedicated support.