# Static outbound IP for Edge Functions

> Outbound requests from SupaHost Edge Functions leave from your instance's own IP address, which stays the same while the instance exists. How to find it and use it in allowlists.

Source: https://supahost.app/kb/static-egress-ip · Updated 2026-11-11

Yes, in practice. Your instance is its own VM with a static external IP address, and requests your Edge Functions make to the outside world leave from that address. It stays the same for as long as the instance exists, so you can add it to a partner's allowlist. SupaHost doesn't offer it as a contractual guarantee, so keep your allowlist easy to update.

## Why this is different from serverless platforms

On many function platforms, outbound traffic leaves from a large shared pool of addresses that changes over time, so getting a fixed IP needs a paid add-on or a proxy. On SupaHost, functions run on your instance's VM, and the instance has one external address of its own. Nothing is shared with other customers.

The same address is used for other outbound traffic from the instance, such as database webhooks sent with `pg_net`.

## Find your instance's IP

Your instance hostname resolves to it. For an instance called `acme`:

```bash
dig +short acme.supahost.space
```

```text
203.0.113.42
```

(Your address will differ.) To confirm what outside services see, deploy a small function that asks an IP echo service:

```ts
// functions/whats-my-ip/index.ts
Deno.serve(async () => {
  const res = await fetch('https://api.ipify.org?format=json')
  const { ip } = await res.json()
  console.log('outbound ip:', ip)
  return Response.json({ ip })
})
```

Call it from the Functions tab's **Test a function** panel and compare the result with the `dig` output. Delete the function afterwards if you don't need it.

## Typical uses

- **Partner APIs with IP allowlists**, such as some banking, payroll or logistics APIs.
- **A database or service behind a firewall** that only accepts known source addresses.
- **Your own backend** that should only accept calls from your SupaHost functions. Pair the IP rule with a shared secret header; an IP check alone isn't authentication.

## Things to keep in mind

- **One address per instance, not per project.** All projects on the instance share it. If you need separate addresses for separate customers, they need separate instances.
- **A new instance means a new address.** If you move to another instance (for example to change region, which can't be done in place), update every allowlist.
- **Keep the allowlist editable.** Because the address isn't contractually guaranteed, store it somewhere you can change quickly, and test the partner connection after major changes to your account.
- **IPv4 vs IPv6.** If a partner asks which protocol to allow, see [IPv4 and IPv6 on SupaHost](/kb/ipv4-ipv6).
- **Inbound is the same host.** The address your app connects to for the project API is your instance's address too. Custom domains point at it with a CNAME or A record.

## Related

- [Instances](/docs/platform/instances)
- [Database webhooks and HTTP requests with pg_net](/docs/database/webhooks)
- [IPv4 and IPv6 on SupaHost](/kb/ipv4-ipv6)
- [Edge Functions on SupaHost](/docs/functions/overview)