---
title: "IP addresses"
description: "The addresses our cloud workers connect from, for allowlisting inbound access to a database."
url: "https://saved.sh/docs/reference/ip-addresses"
---

If your database is behind a default-deny firewall, a **cloud backup** needs an inbound rule
permitting our workers to reach it. The addresses they connect from are published as a plain
text file:

```
https://saved.sh/ips.txt
```

One CIDR per line, `#` for comments, so it drops straight into tooling:

```bash
curl -s https://saved.sh/ips.txt | grep -v '^#'
```

<Callout type="warn" title="No addresses are published yet">
  Cloud backups do not currently leave from a fixed address, so the file is deliberately
  empty rather than listing something that would stop being true. Until it is populated, use
  a local worker for anything behind a firewall.
</Callout>

## You probably do not need this [#you-probably-do-not-need-this]

For most setups the honest answer to "which addresses do I allowlist" is **none**.

A [local worker](/docs/backups/local) runs on your side of the firewall and dials out. Nothing
reaches in, so there is no inbound rule, no allowlist to maintain, and no list of ours that
can drift out of date and break your backups.

| Backup kind | Where it runs                        | Inbound rule needed              |
| ----------- | ------------------------------------ | -------------------------------- |
| **Local**   | A worker you run, next to the source | **None**                         |
| **Cloud**   | Our infrastructure                   | Yes, if the source is firewalled |

Reach for the allowlist when running a worker yourself is not practical. Prefer the worker
when it is.

## What the file covers [#what-the-file-covers]

The addresses are **egress only**: they are what we connect *from* when a cloud backup reads
your source. They are not the addresses of our API, and you do not need them for outbound
rules. Traffic from your side to us is ordinary HTTPS to our API hostname.

Nothing about artifact delivery appears here either. A backup writes to object storage over
HTTPS, so if you use your own bucket, the relevant access rules are the ones on that bucket.

## When it changes [#when-it-changes]

Published addresses end up load-bearing in someone else's firewall, so the file carries a
`Last updated` date in its header and changes are announced before they take effect.

<Callout title="Stub">
  The notice period is not decided yet. Once it is, it belongs here and in the header of
  `ips.txt`, stated as a commitment rather than an intention.
</Callout>

## Ports [#ports]

A cloud backup connects on whatever port the source uses. The common ones:

| Source                | Default port |
| --------------------- | ------------ |
| PostgreSQL            | 5432         |
| MySQL                 | 3306         |
| Redis                 | 6379         |
| S3-compatible storage | 443          |
| Web                   | 443          |

Allow only the port the source actually listens on. If you have moved it off the default,
allow that instead.