SrvYard IP addresses for allow-listing

SrvYard manages your servers from its own machines, so every connection to your server, to your provider's API and to your own webhook endpoints comes from a short, fixed list of addresses. If nothing on your side restricts who may connect, you never need this page. If you limit SSH to chosen addresses, restrict an API key by address, or run a firewall in front of an endpoint SrvYard calls, you must allow these addresses or SrvYard will show your server as disconnected.

You will leave with the list, a clear picture of what each kind of traffic needs, the steps to allow the addresses in your server's firewall and in your provider's, and a way to test that it worked.

The addresses#

SrvYard connects from one of these addresses. Which one is not fixed, so allow all of them.

The IPv6 entry is a whole /64 range, not a single address. Allow the entire prefix exactly as written, because SrvYard may use any address inside it.

The same list is published as JSON at https://<your SrvYard address>/api/public/ips (use the address you sign in at; no sign-in is needed to read it), which is handy if you keep firewall rules in a script. It returns each location and a flat addresses list you can loop over.

What the addresses are used for#

• SSH to your servers. Provisioning, deployments, certificates, backups, the scheduler, firewall changes and the regular connection check all run over SSH from SrvYard's background workers to the address and SSH port set for each server. The port is per server, so allow the port shown in the server's settings, not always 22.
• Cloud provider APIs. When you create, list, reboot, snapshot or delete a server at DigitalOcean, Hetzner, Akamai (Linode), Vultr, Amazon EC2 or Lightsail, or on your own Proxmox cluster, SrvYard calls that provider's API. If you restricted the API key by address, allow the list there.
• Source control hosts. Checking a connection and reading repositories and branches goes through the GitHub, GitLab (including a self-hosted one) or Bitbucket API. The git clone during a deployment runs on your server, not from SrvYard.
• Outgoing webhooks and notification channels. Webhook deliveries to your own endpoints and messages to Slack, Discord and Telegram channels are sent by the app. Webhook deliveries carry the user agent SrvYard-Webhooks/1 and must be reachable over HTTPS.
• Storage buckets. SrvYard talks to your S3-compatible bucket to test it and to check that a backup arrived. The upload itself is sent straight from your server, so a bucket restricted by address needs your server's address too.

Two things you might expect are not on this list. Let's Encrypt validates a certificate by requesting a file from your server over port 80 from its own addresses, so keep port 80 open rather than allowing SrvYard. DNS lookups SrvYard makes to check records are ordinary queries, with nothing to allow.

1. Know what SrvYard opens by default#

On a server SrvYard provisions, the server's firewall (UFW) denies all incoming traffic except SSH, HTTP and HTTPS, and SSH is open to the whole internet. The SSH rule on the Firewall tab is locked for a reason: SrvYard keeps the SSH port allowed from anywhere on every change, so it can never lock itself out.

SrvYard does not install fail2ban and does not restrict SSH by address. Password logins are switched off after provisioning, so SrvYard and your own saved keys are the only ways in.

At the cloud provider, SrvYard creates a firewall only on Amazon: a security group named srvyard-servers that opens ports 22, 80 and 443 to every address, and the same three ports on Lightsail. For Hetzner, DigitalOcean, Vultr and Akamai (Linode) SrvYard creates no provider firewall, so any you see there is one you added.

2. Allow the addresses in your provider's firewall#

If you decide to limit SSH to specific addresses, do it in your cloud provider's firewall, where traffic is dropped before it reaches the machine. The steps are the same idea everywhere: open the firewall or security group attached to the server, edit the inbound rule for TCP on your SSH port, and list your own address plus every SrvYard address.

1. Open the provider's firewall page: Cloud Firewalls at DigitalOcean, Firewalls in a Hetzner project, Firewall in the Vultr and Akamai (Linode) consoles, or the Security Groups page of Amazon EC2.
2. Edit the inbound rule for TCP on the SSH port (22 unless you changed it).
3. Add 82.29.184.14/32 and 204.168.220.80/32 for IPv4, and 2a01:4f9:c015:5702::/64 for IPv6. Add your own office or VPN address too, so you can still log in.
4. Save, then follow Test the connection.

The exact wording of the form differs by provider, so match it to the idea above and not to a button name from this page.

On Vultr, the API key has its own access control. SrvYard's key help says to allow SrvYard's address there, and Vultr rejects every request until you do. Add the same addresses under Access Control of the key, then reconnect the provider.

3. Allow the addresses in the server's own firewall#

The Firewall tab can allow the SrvYard addresses for a service of your own. Open the server, choose Firewall and press Add rule.

1. The SSH note. SSH is always allowed and its rule cannot be removed. This is why the server's own firewall cannot be used to limit SSH to chosen addresses: SrvYard rebuilds the whole ruleset on every change and adds the SSH rule for everyone again.
2. SrvYard IP addresses. The note lists the addresses with a copy button on each, and links to this page. Never add a deny rule for any of them.
3. Add rule. Opens the panel below.

1. Name. For example Health endpoint from SrvYard.
2. Action. Allow.
3. Port. The port of your own service, here 8080. TCP is chosen for you.
4. Source. Paste the three addresses separated by commas: 82.29.184.14, 204.168.220.80, 2a01:4f9:c015:5702::/64. IPv6 sources work once the server's firewall has IPv6 enabled, which SrvYard turns on when the machine supports it.
5. Add rule. SrvYard rebuilds the ruleset and applies it.

This is the same as these UFW commands, which you can also run by hand in a console. Note that SrvYard replaces the ruleset the next time it applies one, so keep the rule on the Firewall tab to make it permanent.

sudo ufw allow proto tcp from 82.29.184.14 to any port 8080
sudo ufw allow proto tcp from 204.168.220.80 to any port 8080
sudo ufw allow proto tcp from 2a01:4f9:c015:5702::/64 to any port 8080

4. Test the connection#

SrvYard checks every Ready or Disconnected server about every five minutes, so a fix shows up by itself. To see it straight away, open the server and press Check connection. On a healthy server the same place offers Refresh status.

1. The checklist. Includes the SSH firewall rule, the provider's firewall and the key.
2. Check connection. Tries to log in and updates the badge.

While you are still connecting a new machine, the Connect your server card shows the same addresses and a Check now button.

1. SrvYard IP addresses. Copy these into any firewall in front of the machine before you press Check now.
2. The connection check. Waits for the machine and tells you what it finds.

SrvYard also needs its own SSH key to stay on the server. It is listed as Required on the SSH keys tab and cannot be removed.

1. SrvYard's key. Never remove it from authorized_keys.
2. Add key. For your own keys. See Add SSH keys to a server and to your account.

5. Webhooks and other endpoints you protect#

If you receive SrvYard's outgoing webhooks, allow the same addresses in front of your endpoint. SrvYard sends a signed POST over HTTPS, waits 10 seconds for an answer and does not follow redirects. A firewall or a rate limiter that drops those requests shows up as failed deliveries in the delivery history. See Outgoing webhooks and delivery history.

Troubleshooting#

• The server shows Disconnected after I restricted SSH. The address list in your firewall is missing one of the addresses, or the wrong port. Allow all of the addresses above on the server's SSH port, then press Check connection.
• "Could not reach 203.0.113.10:22: ..." appears on the Connect your server card. SrvYard could not open a connection: the machine is off, the address or port is wrong, or a firewall drops the traffic. The reason after the colon comes from the network.
• "The machine answers on ... but does not accept SrvYard's key yet." The firewall is fine; the key is not on the machine. Run the command on the card as root.
• "The server rejected SrvYard's key for user ...". Same cause for a ready server. Use Authorise SrvYard's key again on the server page.
• "The server host key changed since SrvYard first connected." Not a firewall problem. The machine was rebuilt or replaced. See Fix a server that will not connect.
• It worked for a while, then failed. An address list may have changed, or fail2ban or a rate limit started blocking repeated logins. Check this page and the JSON endpoint, then your firewall logs.
• I added the addresses to the server's UFW by hand and they vanished. SrvYard rebuilds the ruleset when it applies one. Add the rule on the Firewall tab instead.

Related#

• Open and close ports with the firewall: the rules SrvYard manages on the machine.
• Connect an existing server: the first connection and the access command.
• Fix a server that will not connect: the full checklist for a disconnected server.
• Harden your servers with the firewall, SSH keys and updates: a wider checklist.
• Add a server provider and its API token: provider keys, including address restrictions.