Your servers (VPS)

A VPS is a virtual server of your own, with a plan's processors, memory and disk, and its own IPv4 and IPv6 addresses. Your servers are on the account page under Compute (see your account page).

Who sees them. Only the organization's owners and admins see its servers. Members and billing members don't.

After you order

Each VPS subscription is one server, named "Server 1", "Server 2" and so on. It shows being set up while we prepare it; its buttons and addresses appear once it is ready, and your organization's owners and admins get an email saying so, with its addresses. To rename it, click Rename next to its name. The new name is only for you.

Signing in. If we built your server from one of our images, it comes with the SSH public keys you gave us. Sign in over SSH to its IPv4 address as the user we tell you, for example ssh debian@192.0.2.10. There is no password, so keep your key safe. To add keys, add them to ~/.ssh/authorized_keys on the server. Lost your key? Ask us: we can restore a backup or rebuild the server, but rebuilding wipes it.

Changing plan

When your server's plan changes (ask us for another plan), the server is set to the new plan's processors and memory, which it takes when it next starts, so restart it (Shut down, then Start) after changing.

Moving to a larger plan also grows its disk. The new space shows up at the end of the disk: grow the partition and file system to use it, for example growpart /dev/sda 1 and resize2fs /dev/sda1 (many cloud images do this by themselves at boot). Moving to a smaller plan never shrinks the disk.

Starting and stopping

Once the server is ready, these buttons appear (if your plan includes power controls):

Button	What happens
Start	Turns the server on.
Shut down	Asks the server's system to shut down cleanly. If it hasn't stopped after three minutes, it is turned off.
Reboot	Asks the system to restart.
Stop	Turns the server off at once, like pulling the plug. Unsaved work is lost.
Reset	Restarts it at once, without shutting down first. Containers don't have this.

Stop and Reset ask you to confirm first. Actions are a few seconds apart. Each one is recorded in your organization's activity.

If your plan includes status and usage, the server also shows its uptime and its CPU, memory, disk and network use.

Suspended servers. If a subscription is suspended, its server is shut down and can't be started until the subscription is active again. Over an unpaid invoice it goes in steps, each mailed to you: first the server loses its network but keeps running, then it is shut down, and later, depending on the provider, it is removed with everything on it. The server's card says which. Paying the invoice brings its network back at once (start it again if it was shut down); a removed server can't be brought back by paying, so pay before then. See Billing and tax.

Console

Every plan includes the console. Console next to the server's buttons opens its text console in the page: what you'd see on a serial cable plugged into it. Use it to sign in when the network is down, or to watch the server boot.

Click into the console and type. Ctrl+Shift+C and Ctrl+Shift+V copy and paste; other Ctrl keys go to the server.
If it stays blank, press Enter. A VM shows its first serial port (ttyS0): most cloud images run a login there. If yours doesn't, turn it on with systemctl enable --now serial-getty@ttyS0.
Every VM is given that serial port. If your server had none, it gets one the next time it is stopped and started: shut it down and start it from the account page (a reboot inside the server is not enough).
Sign in with a password: the console has no SSH keys. Set one first with passwd over SSH.
Close console closes it. A console closes by itself after eight hours, or if you stop being an owner or admin of the organization. At most three can be open on a server at once.

Opening the console is recorded in your organization's activity.

Backups

If your plan includes backups, the server's Backups tab lists them, newest first.

Back up now takes a backup while the server keeps running. We keep your newest few (the number is shown); taking another removes the oldest beyond that.
Restore puts a backup back over the server. Shut the server down first. Everything on it now is replaced by the backup and lost. Start it again once the restore has finished.
Delete removes a backup for good. Backups marked kept were kept by us and can't be deleted here.

You can take or restore a backup once every ten minutes. A backup taken while the server is running is like pulling the plug at that moment: databases recover from it, but for a clean copy, shut the server down first or stop the database.

Graphs

If your plan includes usage graphs, the server's Graphs tab shows its CPU, memory, network and disk use over the last hour, day, week, month or year (pick one above the graphs). Each point is the average over a short step: a minute for an hour, half an hour for a day, a day for a year. Hover over a graph (or tab to it) to read the values at a time; Show as a table lists them all. CPU is a share of all the server's vCPUs, so 100% means every one was busy. A gap means the server was stopped.

Snapshots

If your plan includes snapshots, the server's Snapshots tab lists them, newest first, with how many your plan lets you keep.

Take a snapshot saves the server's disks as they are now. Give it a name (a letter, then letters, digits, - and _, up to 40) and a note if you like; without a name it is called after the time, such as snap-20261107-142500. Tick Save the running memory too to save a running server's memory as well: rolling back then resumes it running, exactly where it was. That takes longer and more space.
Roll back puts the server back as it was at that snapshot. Everything on it since is lost. Without saved memory the server is stopped afterwards: start it again.
Delete removes a snapshot. The server keeps what is on it now.

You can take or roll back a snapshot once every two minutes. A snapshot is a quick way back before an upgrade or a risky change, not a backup: it lives on the same storage as the server's disks, and many or old snapshots slow the disks down, so delete them once you are done.

If you moved to a smaller plan, you can't roll back to a snapshot taken on the bigger one (it would bring back its vCPUs and memory); ask us. After any rollback, your plan's vCPUs and memory are put on the server again.

Firewall

Every server has a firewall (Proxmox's own, in front of the server, so it works whatever runs inside). Open the server's Firewall tab to set it up:

Policies: what happens to traffic no rule matches, coming in and going out (ACCEPT, DROP or REJECT), what is logged, and whether DHCP and IPv6 neighbour discovery (NDP) are let through. The firewall itself stays on: to let everything through, set both policies to ACCEPT.
Rules, checked from the top; the first that matches decides. A rule is a direction (in or out), an action, and what it matches: a macro such as SSH, HTTP or DNS, or a protocol (tcp, udp, icmp...) with ports (22, 80,443, 8000:8100), and where from or to (an address, a network, an alias or + an IP set). Add one at the bottom, move it up or down, turn it off or on, or remove it.
Aliases name an address or network to use in rules.
IP sets group addresses and networks; use one in a rule as +name.

Two things are ours and locked:

Your addresses. The server can only send from, and be reached on, the addresses it has been given (shown at the top). This stops anyone using an address that isn't theirs. When you get a new address it is added for you.
Outgoing mail (port 25) is blocked on every server, to keep spam off our network; its rule stays at the top. Mail you send through a mail provider on port 587 or 465 is not affected. To have port 25 opened, support ticket (the Support section of your account) saying what the server sends mail for. Trying to remove the rule tells you the same.

Rules you add always go below ours. A rule that copies ours (its comment starting zappocity:) or uses our address list is refused.

Access

A server's Access tab sets how you sign in to it: its hostname, the user it makes, the SSH keys that user accepts, and a password. These are set by cloud-init when the server starts, so a change is taken on at its next start, power on or reboot from your account page. A reboot from inside the server does not pick it up. Tick Reboot now to take a change on at once.

Hostname: letters, digits and hyphens, in labels separated by dots, such as web1 or web1.example.com.
User: the user cloud-init makes, such as debian, or root.
SSH keys: public keys, one a line (at most 20). Leave it empty to remove them all.
Password: type one (12 to 128 characters), or leave it empty and we make a random one. A password we make is shown once, on the tab, with a copy button. We never keep a password or record it: if you lose it, set a new one.

The tab is there for servers that are VMs. A container's access is set inside it. A server built without a cloud-init drive says so; set its access inside it, or open a support ticket.

The metadata service (169.254.169.254)

Many of our servers take their cloud-init settings from a metadata service at 169.254.169.254, the address cloud servers use, in place of a cloud-init drive. The settings are the Access tab's (hostname, user, SSH keys, password) plus your addresses and name servers.

How cloud-init finds it. cloud-init reads the server's SMBIOS serial ds=nocloud;s=http://169.254.169.254/nocloud/ at boot. Every current cloud image does this: Ubuntu, Debian, Fedora, Rocky, Alma, openSUSE and Arch. A system installed from an ISO without cloud-init gets nothing from it.

What it serves. It answers your server only, and nothing else:

meta-data, user-data and network-config under /nocloud/, in cloud-init's NoCloud format. network-config puts your addresses (routed IPv4 ones as /32s) on your network card.
AWS-style requests (/latest/meta-data/...), for tools that expect them. These need an IMDSv2 token first, from PUT /latest/api/token. They never include your password.

To look from your server:

curl -s http://169.254.169.254/nocloud/meta-data
curl -s http://169.254.169.254/nocloud/network-config
cloud-init query ds        # NoCloud, seeded from the address

TOKEN=$(curl -s -X PUT http://169.254.169.254/latest/api/token -H "X-aws-ec2-metadata-token-ttl-seconds: 60")
curl -s -H "X-aws-ec2-metadata-token: $TOKEN" http://169.254.169.254/latest/meta-data/

Your password. The password's hash is handed out once, on the first boot after it is set, and never again. A program on your server can't read it later. If a password didn't take (say the first boot crashed), set it again on the Access tab.

When a change arrives. An Access change reaches the service within a minute. A reboot sooner than that may start with the old settings, so reboot once more. cloud-init treats a changed server as a new one, so its SSH host keys change, as they do with a drive.

Keep the address reachable. If your firewall inside the server blocks outgoing connections, allow TCP port 80 to 169.254.169.254.

Rescue and reinstall

A server's Rescue tab has two parts: booting from a rescue image, and reinstalling. Both are for servers that are VMs. Each is offered when your plan includes it, and either can be used once every few seconds.

Rescue boots the server from one of the images we offer, such as a rescue system or an installer, with your disks still attached. Use it to repair a server that no longer boots, or to reset a password from outside it.

Pick the image and choose Boot from it. The server is started, or rebooted if it is running.
Open the Console to work in the image.
The server keeps booting from the image, across reboots, until you choose End rescue. That takes the image out and boots the server from its own disk again.
Images marked (installer) install a system of your own over the console, such as one with an encrypted disk. See Encrypting your server's disk.

Reinstall erases the server and installs it again from one of our images:

Erased: its disks and snapshots. Backups stay.
Kept: its addresses and the SSH keys it had.

You type the server's name to confirm. The server shows as being set up until it's ready, which usually takes a few minutes. To sign in with a password afterwards, set one on the Access tab.

Hatch

When you can't reach a server any other way, Hatch is our emergency shell. Over SSH, with a key on your account, it gives you the server's console, power, rescue and reinstall.

Network

Each server's card has tabs: Network (its addresses), Reverse DNS (their names, with how many are set) and, if your plan includes them, Graphs, Backups, Snapshots and Firewall. Under Network, How to set the network up shows ready-made netplan, ifupdown, NetworkManager and FreeBSD setups for your addresses.

IPv4

An address is either on-link or routed:

On-link addresses are on our network. Each is shown with its prefix length and gateway, for example 192.0.2.10/24, gateway 192.0.2.1. Put it on eth0 with that prefix, by hand, or take it by DHCP: the address is kept for your server and is the one DHCP hands out.
Routed addresses are marked routed: see below.

Routed IPv4 addresses

Some addresses are routed to your server rather than on its network, the way your IPv6 /64 is. Your server then also has an IPv4 mgmt (management) address, such as 10.255.0.10/24, gateway 10.255.0.1.

The management address is your server's place on our network. Set it up with its gateway as your default route, by hand or by DHCP.
Each routed address, such as 203.0.113.10, reaches your server through the management address. Put it on lo (or a dummy0 interface) as a /32, and keep only the management address on eth0. It needs no gateway of its own: what you send from it goes out the same default route.
Servers we build set the management address up for you. If your server uses our metadata service, the routed addresses are added too. Otherwise add them as in the examples below.

  ethernets:
    eth0:
      addresses:
        - 10.255.0.10/24      # management address
      routes:
        - to: default
          via: 10.255.0.1
    lo:
      addresses:
        - 203.0.113.10/32     # routed to you

How to set the network up on the Network tab shows this with your own addresses.

IPv6

Your server gets two things:

A management address in a shared network, for example 2001:db8:ffff::100/64, with its gateway (for example 2001:db8:ffff::1). Set them up by hand (or by DHCPv6, below).
A /64 of its own, for example 2001:db8:1000:1::/64, routed to your management address. Use any address in it on the server, or hand it on to containers or VMs inside your server.

On some of our networks IPv6 comes in on a second network card (eth1, often named ens19), with IPv4 on the first. The account page says so, and its netplan and ifupdown examples put the IPv6 management address and its default route on that card.

If the account page says IPv6 can be taken by DHCPv6, you can instead let the server ask for both: the management address, and your /64 as a delegated prefix (dhcp6: true in netplan; for the prefix, a DHCPv6 client that asks for prefix delegation, such as systemd-networkd with [DHCPv6] PrefixDelegationHint=::/64). The default route comes from our router's advertisements.

Reverse DNS

The server's Reverse DNS tab lists each of its addresses with its name, such as mail.example.com: what the address looks up to (its PTR record). Mail servers often check this. Name it (or Edit) on an address sets its name in place; Remove clears it; Another address of your /64 names any other address in it.

First add an A record (for IPv4) or AAAA record (for IPv6) for the name, pointing at the address. We only accept a name that already resolves to the address.
You can name your IPv4 addresses, your management address, and up to 32 addresses in your /64.
To remove a name, click Remove (or clear it and save).
If the box isn't there, reverse DNS isn't offered for your addresses yet.

Your own name servers for your /64

Instead of setting names here one by one, you can keep every name in your /64 on name servers of your own. Under Reverse DNS → Name servers for your /64, list two to eight of them (such as ns1.example.com) and save: we point your /64 at them (NS records in our reverse zone), and they answer for every address in it.

Each name server must already resolve (have an A or AAAA record).
The names set here in your /64 go when you delegate it, and new ones are refused while it is delegated: set them on your name servers.
dnso.city's name servers work too: first add your /64's zone (such as 1.0.0.0.0.0.0.1.8.b.d.0.1.0.0.2.ip6.arpa for 2001:db8:1000:1::/64; the box shows yours) to a DNS account of yours on dnso.city, then delegate to dnso.city's name servers. Only those who manage the server can add that zone. As dnso.city signs it, its DS record is put beside the delegation, so DNSSEC carries on into it. See DNS hosting.
Remove the delegation to go back to setting names here. The delegation also goes when your /64 is taken back.
Only the organization's owners and admins delegate, while the server is active.

Address registration (ARIN whois)

Your server's addresses belong to us at ARIN, the regional internet registry for North America. We may register them there as reassigned to you, so that whois shows who uses them. Under Your organizations → Address registration (ARIN whois) on the account page, choose how you appear:

Private (the default): ARIN shows "Private Customer" with only the city, state, postal code and country of your billing address.
The organization's name and billing address: shown in full.

Only owners change it; admins can see it. Changes reach ARIN within minutes, and a change of billing address is sent too. The box lists the addresses registered and their state. When an address goes back to us, its registration is removed.

Example (Ubuntu netplan)

Put this in /etc/netplan/50-zappocity.yaml, then run netplan apply:

network:
  version: 2
  ethernets:
    eth0:
      addresses:
        - 192.0.2.10/24
        - 2001:db8:ffff::100/128     # management address
      routes:
        - to: default
          via: 192.0.2.1
        - to: default
          via: 2001:db8:ffff::1
          on-link: true
    lo:
      addresses:
        - 2001:db8:1000:1::1/128     # from your /64

The management address is a /128: the gateway is reached on the link (on-link), and addresses of your /64 go on lo, since they are routed to you rather than on our network.

Example (Debian ifupdown)

The same in /etc/network/interfaces:

auto lo
iface lo inet loopback
    up ip -6 addr add 2001:db8:1000:1::1/128 dev lo

auto eth0
iface eth0 inet static
    address 192.0.2.10/24
    gateway 192.0.2.1
iface eth0 inet6 static
    address 2001:db8:ffff::100/128
    up ip -6 route add 2001:db8:ffff::1 dev eth0
    up ip -6 route add default via 2001:db8:ffff::1 dev eth0

A routed IPv4 address goes on lo the same way: up ip addr add 203.0.113.10/32 dev lo.

Example (AlmaLinux, Rocky Linux, CentOS Stream)

These use NetworkManager. Run the commands as root from the console, since the connection drops while it changes. First take the old connection off the card: nmcli connection show lists them, and nmcli connection delete NAME removes one.

nmcli connection add type ethernet ifname eth0 con-name zappocity \
  ipv4.method manual ipv4.addresses "192.0.2.10/24" ipv4.gateway 192.0.2.1 ipv4.dns 1.1.1.1 \
  ipv6.method manual ipv6.addresses 2001:db8:ffff::100/128 \
  ipv6.routes "2001:db8:ffff::1/128, ::/0 2001:db8:ffff::1" ipv6.dns 2606:4700:4700::1111
nmcli connection add type dummy ifname dummy0 con-name zappocity-routed \
  ipv4.method disabled ipv6.method manual ipv6.addresses 2001:db8:1000:1::1/128
nmcli connection up zappocity && nmcli connection up zappocity-routed

The IPv6 gateway. The management address is a /128, so the first route reaches the gateway directly on the card, and the second makes it the default route.
What is routed to you goes on a dummy0 device rather than lo: the address from your /64, and any routed IPv4 address, such as ipv4.method manual ipv4.addresses "203.0.113.10/32" in place of ipv4.method disabled.
IPv6 on its own card. Put the IPv6 parts on a second connection on eth1, with ipv4.method disabled, and use ipv6.method disabled on eth0.

Use your own addresses from the account page. The interface may be named ens18 rather than eth0; ip link shows its name.

Example (FreeBSD)

Add these lines to /etc/rc.conf, replacing the card's old ifconfig_ lines. Put nameserver 1.1.1.1 in /etc/resolv.conf. Then run service netif restart && service routing restart from the console:

ifconfig_vtnet0="inet 192.0.2.10/24"
defaultrouter="192.0.2.1"
ifconfig_vtnet0_ipv6="inet6 2001:db8:ffff::100/128"
ipv6_static_routes="zgw zdefault"
ipv6_route_zgw="2001:db8:ffff::1 -prefixlen 128 -interface vtnet0"
ipv6_route_zdefault="default 2001:db8:ffff::1"
ifconfig_lo0_alias0="inet6 2001:db8:1000:1::1/128"

The card. FreeBSD names the card vtnet0. ifconfig lists the cards.
The IPv6 gateway. The management address is a /128, so the gateway is reached through a host route on the card (zgw). That route comes before the default route. For this reason the routes are named in ipv6_static_routes rather than set with ipv6_defaultrouter.
What is routed to you goes on lo0 as aliases, numbered from 0. A routed IPv4 address is one more alias, such as ifconfig_lo0_alias1="inet 203.0.113.10/32".
IPv6 on its own card. Put the IPv6 lines on vtnet1, and add ifconfig_vtnet1="up".

Using your /64

Every address in your /64 reaches your server; the first one (2001:db8:1000:1::1 in the examples) is set up above. How to set the network up on the account page shows these with your own addresses.

More addresses, one by one. Add each as a /128, in netplan's addresses under lo (- 2001:db8:1000:1::2/128) or at once with ip -6 addr add 2001:db8:1000:1::2/128 dev lo. On FreeBSD, use ifconfig lo0 inet6 2001:db8:1000:1::2/128 alias. To keep it, add it as the next ifconfig_lo0_alias line in /etc/rc.conf.
Every address at once. A local route makes your server answer on the whole /64, so a program can listen on any address in it without adding each one:
```
ip -6 route add local 2001:db8:1000:1::/64 dev lo
```
To keep it with NetworkManager: nmcli connection modify zappocity-routed +ipv6.routes "2001:db8:1000:1::/64 type=local". With netplan, add it under lo as routes:
```
        - to: 2001:db8:1000:1::/64
          type: local
          scope: host
```
Handed on to containers or VMs. Put 2001:db8:1000:1::1/64 on their bridge (such as lxdbr0 or vmbr0) instead of 2001:db8:1000:1::1/128 on lo, and turn forwarding on:
```
echo net.ipv6.conf.all.forwarding=1 > /etc/sysctl.d/90-ipv6-forward.conf
sysctl --system
```
Each container takes its own address of the /64 with 2001:db8:1000:1::1 as its gateway. With forwarding on, your server ignores our router's advertisements, so keep its default route set by hand. Use this or the local route, not both.

To check: ip -6 route get 2606:4700:4700::1111 goes via your gateway, and ping -6 to an address of your /64 from elsewhere answers. Your /64 needs no route or gateway of its own: we route it to your management address.

Through the API

GET /api/account/orgs/{orgId}/servers lists the servers, and POST .../servers/{serverId}/power with {"action": "start"} (or shutdown, stop, reboot, reset) acts on one. Both use your signed-in session. See the account API.