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

# Network Allowlisting

> Allow inbound connections from Overcut Cloud through your firewall or VPN using the published egress IP range.

Overcut Cloud makes outbound connections from a fixed range of public IP
addresses. If a system Overcut connects to sits behind a corporate firewall, a
VPN, or an IP allowlist, this is the range to permit:

```
20.125.192.184/29
```

<Warning>
  Allowlist the entire range, never a single address. Overcut selects a source
  address per connection, so two consecutive requests to the same endpoint can
  arrive from different IP addresses in the range. A rule built around one
  observed address fails intermittently and unpredictably.
</Warning>

## Scope

|              |                                                     |
| ------------ | --------------------------------------------------- |
| Egress range | `20.125.192.184/29`                                 |
| Addresses    | `20.125.192.184` through `20.125.192.191` (8 total) |
| Applies to   | Overcut Cloud (SaaS) only                           |
| Direction    | Outbound only, connections that Overcut initiates   |

The range covers connections Overcut Cloud opens towards your systems. It does
not apply to traffic your systems send to Overcut, which reaches Overcut over
the public internet from your own addresses.

<Note>
  **Self-hosted Overcut deployments are out of scope.** A deployment you run on
  your own infrastructure connects to your systems from your own network, using
  addresses your network team controls. This range is not involved, and
  allowlisting it does nothing for a self-hosted setup.
</Note>

## Configure the rule

Add `20.125.192.184/29` as an allowed source on the firewall, security group,
VPN policy, or application-level IP allowlist that guards the systems Overcut
needs to reach.

If your firewall does not accept CIDR notation, enter the range as
`20.125.192.184-20.125.192.191`, or enumerate all eight addresses. Any form is
fine as long as the full range is covered.

### All eight addresses are in use

This includes the first and last address in the range. Firewall administrators
often exclude the first and last address of a block out of habit, treating them
as network and broadcast addresses. That does not apply here: this is a routed
allocation, not a subnet, and both `20.125.192.184` and `20.125.192.191` carry
live traffic. Excluding either one produces failures that look random.

## Security considerations

The egress range is shared across all Overcut Cloud customers. Allowlisting it
permits traffic from Overcut's infrastructure generally, not from your
workspace specifically. An IP allowlist is a network control, not an
authentication control.

Keep these in place alongside the allowlist:

* **Application-level authentication.** Continue to require credentials,
  tokens, or mutual TLS on the systems you open up. Never treat a connection
  from this range as authenticated.
* **A narrow rule.** Scope the allowlist to the specific destination hosts and
  ports Overcut needs, rather than opening the range to your network broadly.
* **The controls you already run.** Rate limiting, logging, and monitoring on
  the exposed endpoints stay as relevant as they were before.

For how Overcut protects data in transit and at rest, see
[Privacy & Security](/docs/privacy-and-security).

## If the range changes

Overcut gives customers advance notice before the egress range changes. This
page is the source of truth: read the range here when you build or audit a
rule, rather than caching the value in a runbook where it can go stale.

## Related

* [Privacy & Security](/docs/privacy-and-security)
* [Connect to GitLab](/docs/integrations/gitlab) for a self-hosted GitLab
  instance that Overcut Cloud reaches over the public internet
* [MCP Servers](/docs/reference/mcp-servers) for remote MCP servers you host