CodeRabbit Reverse Tunnel

Connect CodeRabbit to private-network services without opening inbound network access. Carries Git platform traffic and internal MCP servers over a single outbound connection.

The CodeRabbit Reverse Tunnel is a private-network connectivity option for organizations that cannot expose internal services to the public internet. A CodeRabbit-provided Connector runs inside your network, dials out to CodeRabbit over WebSocket Secure (WSS), and carries CodeRabbit-initiated traffic through that existing outbound session. One connector can serve several destinations, such as your Git platform, internal MCP servers, or both.

Intended use

The CodeRabbit Reverse Tunnel is intended for organizations with the constraints defined below:

• Your self-managed Git instance or internal MCP server runs in a private subnet, private cloud account, or on-premises network.
• Your services cannot receive inbound connections from CodeRabbit or the public internet.
• Your security policy does not allow inbound firewall exceptions, vendor IP allowlisting on the Git platform side, or external PrivateLink peering.

Use this option when CodeRabbit must reach a service that has no public endpoint, no inbound firewall exceptions, no vendor IP allowlisting, and no PrivateLink or peering path.

For services that CodeRabbit can already reach directly, use the standard GitHub Enterprise Server guide, self-managed GitLab guide, or MCP servers guide. At the moment there is no self-service interface; reverse tunnel setup is handled by CodeRabbit Sales or Support.

Components

The CodeRabbit Reverse Tunnel has four components:

1. Reverse Tunnel Gateway — A CodeRabbit-managed edge service that accepts Connector sessions and exposes tenant-scoped HTTPS routes for CodeRabbit services to call into.

2. Reverse Tunnel Connector — A lightweight, CodeRabbit-provided container that runs inside your network and establishes a long-lived outbound connection (WSS over HTTPS) to the Reverse Tunnel Gateway. CodeRabbit then sends runtime requests — clone, read pull requests, post review comments — over this pre-established tunnel. The Connector dials out from your network; no inbound ports are opened.

3. Route key — A unique, opaque routing identifier issued by CodeRabbit for each destination. CodeRabbit uses the route key to direct runtime traffic to the correct Connector session, so your private address is never exposed in the URL path. Each route is provisioned for a specific purpose, either Git platform traffic or MCP traffic, and the gateway enforces that purpose.

4. Connector token — A bearer token issued by CodeRabbit for your tenant. Multiple Connector replicas can share the same token.

Architecture

CodeRabbit Reverse Tunnel architecture

The CodeRabbit Reverse Tunnel uses two connectivity paths between the customer network and the CodeRabbit cloud. The paths below describe Git platform traffic, which is what the diagram shows. MCP traffic uses the inbound path only, because an MCP server does not send webhooks. Described from the customer’s perspective:

Direction	Purpose	Network path
Inbound (CodeRabbit → Git platform)	Clone repositories over HTTPS, read pull requests, fetch files and commits, create reviews, post comments, and update checks or commit statuses	CodeRabbit services call the Reverse Tunnel Gateway, which forwards the request into your network over the long-lived WSS session opened by the Reverse Tunnel Connector. The Connector then makes an internal call to your Git platform.
Outbound (Git platform → CodeRabbit)	Deliver webhook events such as pull request opened, synchronized, reviewed, or commented	Your Git platform sends standard HTTPS webhooks outbound through the customer NAT gateway to the CodeRabbit webhook receiver.

The tunnel carries only CodeRabbit-initiated inbound traffic. Outbound webhooks continue to flow through your existing customer NAT and use the webhook secret or token configured for that platform.

PR review flow through the Tunnel

End-to-end view of how a single pull request moves through the CodeRabbit Reverse Tunnel.

Pull request review flow over CodeRabbit Reverse Tunnel

• Developer opens a pull request inside your private Git platform.
• Your Git platform sends a webhook to CodeRabbit outbound through your customer NAT.
• CodeRabbit reads the pull request through the tunnel. The Reverse Tunnel Gateway routes the request over the existing WSS session; the Reverse Tunnel Connector forwards it to your Git platform and streams the response back.
• CodeRabbit runs the review and writes the feedback.
• CodeRabbit posts the comments back through the same tunnel, and the review appears on the pull request.

High availability

Run at least two connector replicas for production.

All replicas for the same tenant normally run the same connector configuration, which means the same gateway URL and the same set of routes, each with its own connector token, route key, target base URL, and origin TLS policy. By default, the gateway tracks the live connector sessions for the route and uses an active session for each new request. Round-robin routing is also supported with REVERSE_TUNNEL_DIRECT_CONNECTOR_ROUTING=true.

Important behavior:

• New requests can use another live connector after a connector disconnects.
• In-flight requests are not transparently moved to another connector.
• The connector reconnects automatically with exponential backoff after a lost WSS session.

Capacity and limitations

The tunnel streams request and response bodies with backpressure, so it supports large HTTPS clone/fetch traffic. Capacity is still bounded by your connector replicas, network egress, and the capacity of each destination origin.

Area	Behavior
Concurrency	The gateway enforces a per-connector concurrent stream limit. CodeRabbit provides the active limit during onboarding. Add connector replicas to increase available concurrency.
Buffering	The connector does not provide durable buffering while offline. If a connector is down, new runtime calls to that destination fail until another connector is available.
Protocol	HTTPS only, for every destination.
Platform support	Available for GitHub Enterprise Server and self-managed GitLab. GitLab reverse-tunnel setup requires contacting CodeRabbit Support (existing customers) or CodeRabbit Sales (new customers). For information about support for Azure DevOps and other Git platforms please contact CodeRabbit Sales team.

FAQ

Does CodeRabbit need inbound access to our network?

No. The connector opens an outbound WSS session to CodeRabbit. CodeRabbit-initiated traffic rides over that existing session to your services.

Can we run multiple connector pods?

Yes. Multiple connector replicas can serve the same route key. Default routing uses an active live session for each new request, and round-robin routing is also supported with REVERSE_TUNNEL_DIRECT_CONNECTOR_ROUTING=true. Give each live replica a unique REVERSE_TUNNEL_CONNECTOR_ID.

Can we restrict outbound destinations?

Yes. The connector needs outbound HTTPS to the CodeRabbit gateway and HTTPS reachability to each destination origin you configure as a route. Your Git platform also needs outbound HTTPS to the CodeRabbit webhook receiver.

What happens if the tunnel drops during a review?

The connector reconnects automatically. In-flight requests fail and are retried only when CodeRabbit can safely retry the operation.

Can this forward other internal services?

Only services CodeRabbit provisions a route for. The tunnel carries CodeRabbit-initiated HTTPS traffic to the destinations configured as routes, currently Git platforms and MCP servers. It is not a general-purpose private-network proxy, and a route provisioned for one purpose cannot be used for another.

What’s next

Connector configuration

Configure one connector to serve several routes, including internal MCP servers.

GitHub Enterprise Server setup

Create the OAuth App, GitHub App, webhook secret, and permissions used by the GHES integration.

Self-managed GitLab setup

Review the standard self-managed GitLab requirements used with reverse-tunnel onboarding.