> ## Documentation Index
> Fetch the complete documentation index at: https://docs.traversal.com/llms.txt
> Use this file to discover all available pages before exploring further.

# Traversal Connector

> The Traversal Connector is a lightweight service deployed in your environment that enables the Traversal platform to securely access your private data sources and internal systems — without requiring any inbound network access to your environment.

## Architecture

The Traversal Connector operates on a pull-based, outbound-only connection model. Rather than the Traversal platform connecting inbound to your environment, the Traversal Connector initiates a persistent, bidirectional, encrypted tunnel to the Edge Controller in Traversal's SaaS control plane or in your [Traversal BYOC deployment](/architecture/byoc). The Traversal platform sends requests over this tunnel, and the Traversal Connector executes them against your internal services and returns the responses over the same tunnel.

This design means:

* No inbound firewall rules are required — the Traversal Connector only makes outbound connections
* Your network perimeter is preserved — no services are exposed or listening for external traffic
* You retain full control — the Traversal Connector runs in your environment, under your operational purview

| Component              | Runs in                                                                      | Role                                                                                                             |
| :--------------------- | :--------------------------------------------------------------------------- | :--------------------------------------------------------------------------------------------------------------- |
| Your internal services | Your environment                                                             | <ul><li>Data sources and APIs queried by the Traversal Connector over your private network</li></ul>             |
| Traversal Connector    | Your environment                                                             | <ul><li>Initiates the outbound tunnel</li><li>Executes HTTP requests against your internal services</li></ul>    |
| Edge Controller        | Traversal's SaaS control plane or your [BYOC](/architecture/byoc) deployment | <ul><li>Receives the tunnel connection</li><li>Dispatches requests on behalf of the Traversal platform</li></ul> |

The data flow is:

```
Traversal Platform → Edge Controller → (mTLS tunnel) → Traversal Connector → (HTTPS) → Your Internal Services
```

Responses return along the same path. The tunnel is always initiated outbound by the Traversal Connector.

## Security

### Encryption

The Traversal Connector establishes a dedicated, private tunnel to the Edge Controller, encrypted end-to-end with mTLS. This tunnel can optionally be established through a PrivateLink service endpoint, ensuring traffic never traverses the public internet. The Traversal Connector authenticates itself to the controller using a client certificate, and verifies the controller's identity using a trusted CA certificate.

### No inbound network access

The Traversal Connector initiates all connections outbound. It does not listen on any ports for external traffic, and does not require any inbound firewall rules or publicly reachable endpoints.

The only listening port is an internal health-check endpoint used by your container orchestrator to monitor the service's readiness.

### No data persistence

The Traversal Connector does not store, cache, or log any request or response data. It is a stateless, transient forwarding service — data flows through it and is not retained.

### Forward proxy support

For environments that require all outbound traffic to route through a corporate proxy, the Traversal Connector supports connecting to the Edge Controller through an HTTP CONNECT proxy.

## Telemetry

The only external connection the Traversal Connector makes — beyond the tunnel to the Edge Controller — is to `telemetry.<deployment_name>.traversal.com` to report its own operational telemetry (metrics, traces, and logs) using OpenTelemetry (OTLP).

No customer data is included in the telemetry. Only operational metrics such as tunnel connectivity status, request latency, and error rates are reported.