# Network access

Control which outbound destinations queries may reach, using the network access capability and its allow and deny patterns.

Network access controls which external destinations an instance may reach **from inside a query**.

The functions it governs are the [HTTP functions](/docs/reference/query-language/functions/database-functions/http.md) that call an API, fetch a document, or post to a webhook as part of a statement.

> [!IMPORTANT]
> This is outbound access. It has nothing to do with who can reach the instance. For inbound connectivity, see [Private connectivity](/docs/manage/instances/private-connectivity.md) and its `public`, `private`, and `dual` access modes.

The capability is **denied by default**. Until you allow something, `http::get` and its siblings fail rather than reach the network.

That default matters. An instance with unrestricted outbound access lets a query author send data anywhere. Keep the allowed set to the shortest list that makes the application work.

> [!NOTE]
> Configurable network access requires SurrealDB `>=2.1.8, <2.2.0`, `>=2.2.6, <2.3.0`, or `>=2.3.6`. On an earlier release, [upgrade the instance](/docs/manage/instances/versions-and-upgrades.md) before you configure the rules.

## Configuring the rules

Network access is one of the [instance capabilities](/docs/manage/instances/configure.md#capabilities), so it lives with the rest of them.

1. Open the instance in [SurrealDB Studio](https://app.surrealdb.com).
2. Go to **Instance settings → Capabilities**.
3. Find **Network access** in the granular configuration list.
4. Choose its default: **Allowed by default** or **Denied by default**.
5. Add the exceptions. Under a denied default, list the domains, IP addresses, and ranges to permit. Under an allowed default, list what to block.
6. Save the change to apply it to the instance.

![The Capabilities tab of instance settings in SurrealDB Studio, with Network access set to Denied in the granular configuration list, alongside the Scripting, Guest Access, RPC methods, HTTP endpoints, Functions, and Arbitrary queries controls.](~/assets/img/surrealdb/manage/instance-capabilities.webp)

At the same specificity, a deny rule prevails over an allow rule. A host you have denied therefore stays unreachable even when a broader allow rule would otherwise cover it. That is how you permit the public endpoints of an API while keeping an internal hostname on the same domain out of reach.

## Choosing the patterns

Prefer named destinations over ranges. `api.stripe.com` documents its own intent. A wide CIDR block does not, and it grants reachability to whatever moves into that block later.

Review the list when the application changes. Rules outlive the feature that needed them, and an allowance nobody remembers adding is the one worth removing.

You can export both the default and the exception lists as JSON from the same tab, which is how you keep staging and production consistent. `surrealctl instance capabilities` reads and writes the same configuration from a terminal. See [surrealctl instances](/docs/manage/surrealctl/instances.md).

## Additional resources

[Watch on YouTube](https://www.youtube.com/watch?v=EUp5PxbzvV4?si=ezt6HhQuhhqHu9tU)

- **[Capabilities](/docs/learn/security/authorization/capabilities.md):** the full capability model and every flag it covers.
- **[Configure an instance](/docs/manage/instances/configure.md#capabilities):** the other capabilities on the same tab.
- **[HTTP functions](/docs/reference/query-language/functions/database-functions/http.md):** the functions this capability governs.