Networking

Your server has one public IPv4 address and one IPv6 block, both configured for you at first boot. Both are on the Network tab, and the IPv4 address is also on Overview.

Secure the server itself, from the first boot

Assume every port your server listens on is reachable from the internet, on IPv4 and IPv6 alike, from the second it boots.

Configure the server's own firewall with nftables, ufw or firewalld, before you start a service rather than after. That is the layer you control end to end, and the only one you should depend on.

Firewall rules in the portal

The Network tab has a Firewall rules card. Rules you add there describe direction, action, protocol, ports and source or destination, and they are applied outside the machine rather than inside it.

Treat it as a second layer. The firewall running on the server is the one you can see the state of, test, and reason about, so configure that one first and keep it correct on its own terms. Anything you add in the portal sits in front of it, not instead of it.

IPv4

One address per server. There is no way to order a second one.

The address stays with the server through reboots, plan changes and even a reinstall. It is released back to the pool when you delete the server, and an address you released is preferred for your next one, so a delete-and-reorder often lands on the same address.

IPv6

Each server gets a /112 block, which is 65,536 addresses. The portal shows you the block, ending in :0/112:

2001:0db8:1234:5678::64:0/112

The address actually configured on the interface is the first one in the block, ending in :1. That is the one to put in an AAAA record and the one to connect to:

ssh root@2001:0db8:1234:5678::64:1

The whole block is routed to your server, so any further addresses you need, one per container or one per virtual host, you add to the interface yourself. Nothing has to be allocated on our side first.

A reinstall changes the block

The IPv4 address survives a reinstall; the IPv6 block does not. Anything pinned to the old address, AAAA records included, has to be updated after a reinstall. Plan changes and reboots leave it alone.

Reverse DNS

You cannot set the PTR record yourself

The Reverse DNS field on the Network tab reports success when you save it, but the PTR record for your address is not changed. Until that is fixed, do not rely on it, and check what your address actually resolves to before you assume:

dig +short -x <your-ip>

If you need a specific PTR record, for a mail server for example, contact support and we will set it.

Traffic

Traffic is not metered, not capped and not billed. There is no allowance to run out of, and nothing on your invoice depends on how much you transfer. What you pay is the plan, see Billing.

What's next

• Managing your server for the console when the network is what broke
• Troubleshooting if the server is not answering