How to Install Tailscale on Ubuntu 24.04 VPS: Mesh VPN with MagicDNS, ACLs, Subnet Router, Exit Node, Taildrop & SSH

Building a private network across your VPS fleet, home lab, and laptops used to mean wrestling with OpenVPN server configs, static WireGuard peer lists, NAT traversal workarounds, and router port forwarding on every site you touch. Tailscale replaces all of that with a zero-config mesh VPN built on WireGuard, coordinated by a hosted control plane, and authenticated through identity providers you already use. This tutorial walks you through installing Tailscale on an Ubuntu 24.04 VPS, authenticating with an auth key, enabling MagicDNS, advertising a subnet router and exit node, sending files with Taildrop, turning on Tailscale SSH, and locking the entire tailnet down with ACLs.

Skip the manual install? Our CloudCore Starter VPS ships with Ubuntu 24.04 and the kernel WireGuard module ready to go. Launch a CloudCore Starter VPS for EUR 7.99/month and be on your tailnet in under two minutes.

Table of Contents

What is Tailscale?

Tailscale is a mesh VPN built on top of the WireGuard protocol that creates a flat, encrypted network (called a tailnet) between every device you add to it. Unlike hub-and-spoke VPNs where all traffic flows through a central concentrator, Tailscale establishes direct peer-to-peer WireGuard tunnels between nodes whenever the network allows it, falling back to encrypted DERP relays only when NAT traversal fails.

The control plane handles key exchange, authentication through your existing identity provider (Google, Microsoft, GitHub, Okta, Apple, or any OIDC source), MagicDNS hostname distribution, and policy delivery. The data plane is pure WireGuard, the same kernel-module VPN protocol that has shipped with Linux since version 5.6. You never write an interface config by hand, never open an inbound firewall port, and never distribute a shared secret. Each node authenticates once through a browser-based login flow or a pre-issued auth key, and is then addressable by a stable 100.x.y.z tailnet IP and a MagicDNS hostname.

Tailscale's feature surface has grown well beyond a raw mesh VPN. Subnet routers let a single node bridge a private CIDR into the tailnet, which means you can reach a printer, a NAS, a router admin panel, or an entire cloud VPC through one exit point. Exit nodes push all of a peer's internet traffic through the VPS, giving you a commercial-VPN-style exit without paying a commercial VPN. Taildrop sends files between devices without an intermediate server. Tailscale SSH replaces OpenSSH key management with tailnet identity and ACLs. Funnel exposes a local service to the public internet on a *.ts.net hostname without opening any ports. And Tailscale Lock lets a tailnet owner sign off on every new node joining the network for an extra layer of supply-chain defense.

The full documentation lives at tailscale.com/kb/ and is worth bookmarking as a reference while you work through this guide.

Why Run Tailscale on a VPS?

Running Tailscale on a public VPS rather than only on laptops and home devices unlocks a stack of patterns that are otherwise painful:

• A stable, always-on relay that other peers can reach even when your laptop is closed. It can serve as a subnet router for a cloud VPC or as an exit node in a jurisdiction of your choice.
• Zero exposed inbound ports. Your VPS can sit behind UFW that blocks every port except 22 to the world, and Tailscale peers can still reach SSH, HTTP, databases, and admin panels through the tailnet interface.
• Private service hosting. Run Grafana, Prometheus, a staging website, a development Postgres, or an internal wiki listening only on 100.x.y.z and reachable only to tailnet members. The public internet sees nothing.
• Cross-provider bridging. A Tailscale subnet router on a Contabo VPS can let an OVH VPS reach a Hetzner VPS's private VLAN without any VPC peering, transit gateway, or provider-specific networking glue.
• Bastion replacement. Skip the separate bastion host. Tailscale SSH plus ACLs gives you identity-based access control to every node with full audit trail, and no keypair to rotate.
• GDPR-friendly egress. A VPS in the EU advertised as an exit node keeps end-user browsing inside the EU data perimeter, which is useful for both personal privacy and for teams shipping behind region-locked services.
• A predictable, flat monthly cost. Where commercial mesh VPN pricing can escalate per seat, a single CloudCore VPS carries the whole role for EUR 7.99 to EUR 29.99+ depending on how much subnet and exit-node bandwidth you plan to move.

CloudCore plan sizing

Tailscale vs WireGuard vs NetBird vs Headscale

Before you install anything, make sure you are picking the right tool. Here is how Tailscale stacks up against the three closest alternatives, each of which has its own install guide on this knowledge base.

Short version: pick Tailscale if you want the fastest path from zero to a working mesh; pick Headscale when you want the Tailscale client UX but you must own the control plane; pick NetBird if you want full self-host with a bundled dashboard and Zitadel SSO; pick raw WireGuard when you need a single point-to-point tunnel with zero external dependencies.

Prerequisites

Before starting, make sure you have:

• A VPS running Ubuntu 24.04 LTS with root or sudo access. The CloudCore Starter plan at EUR 7.99/month is the recommended entry point.
• SSH access to the server. PuTTY on Windows, or the built-in terminal on macOS or Linux, both work.
• A Tailscale account. Sign up with a Google, Microsoft, GitHub, Apple, or Okta identity at login.tailscale.com. The free Personal plan covers up to 100 devices and three users.
• The WireGuard kernel module (already present on Ubuntu 24.04 by default, no action needed).
• An auth key from the admin console if you plan to automate enrollment. Generate one at login.tailscale.com/admin/settings/keys.

ssh root@your-server-ip

Step 1: Update System Packages

Start with a clean system. Refresh the package index, apply any pending security updates, and reboot if the kernel changes so WireGuard's in-kernel data path picks up the latest build.

sudo apt update && sudo apt upgrade -y

Expected output (abbreviated):

Hit:1 http://archive.ubuntu.com/ubuntu noble InRelease
Reading package lists... Done
Building dependency tree... Done
0 upgraded, 0 newly installed, 0 to remove and 0 not upgraded.

If the kernel was updated, reboot before continuing:

sudo reboot

Reconnect via SSH once the VPS is back online, usually within a minute.

Confirm that IP forwarding packages are present (they ship with Ubuntu 24.04 already, but it is cheap insurance):

sudo apt install -y iptables iproute2 curl

Step 2: Install Tailscale

Tailscale publishes an official installer that takes care of everything: adding their apt repository signing key, adding the apt source, installing the tailscale and tailscaled packages, and enabling the systemd service.

Run the installer:

curl -fsSL https://tailscale.com/install.sh | sh

Expected output:

Installing Tailscale for ubuntu noble, using method apt
+ curl -fsSL https://pkgs.tailscale.com/stable/ubuntu/noble.noarmor.gpg
+ sudo tee /usr/share/keyrings/tailscale-archive-keyring.gpg
+ sudo curl -fsSL -o /etc/apt/sources.list.d/tailscale.list https://pkgs.tailscale.com/stable/ubuntu/noble.tailscale-keyring.list
+ sudo apt-get update
+ sudo apt-get install -y tailscale
...
Installation complete! Log in to start using Tailscale by running:
    sudo tailscale up

Under the hood the script runs the equivalent of:

curl -fsSL https://pkgs.tailscale.com/stable/ubuntu/noble.noarmor.gpg \
  | sudo tee /usr/share/keyrings/tailscale-archive-keyring.gpg > /dev/null
curl -fsSL https://pkgs.tailscale.com/stable/ubuntu/noble.tailscale-keyring.list \
  | sudo tee /etc/apt/sources.list.d/tailscale.list
sudo apt update
sudo apt install -y tailscale

Verify that tailscaled is running:

sudo systemctl status tailscaled

Expected output:

● tailscaled.service - Tailscale node agent
     Loaded: loaded (/usr/lib/systemd/system/tailscaled.service; enabled; preset: enabled)
     Active: active (running) since Thu 2026-04-16 10:00:00 UTC; 10s ago
   Main PID: 1234 (tailscaled)

Check the CLI version:

tailscale version

Expected output:

1.80.0
  tailscale commit: 1234567890abcdef
  other commit: fedcba0987654321
  go version: go1.23.1

Tailscale is installed but not yet authenticated — the tunnel is down until you run tailscale up.

Step 3: Bring Up the Tunnel with an Auth Key

There are two ways to authenticate the node: interactive browser login (good for laptops and one-off VPSes) or auth key (good for any automation, immutable images, and Terraform/Ansible pipelines). On a headless VPS, auth keys are almost always the better choice.

Generate an auth key

In the Tailscale admin console, open Settings → Keys at login.tailscale.com/admin/settings/keys and click Generate auth key. Pick these options:

• Reusable: off (unless you are baking the key into an image)
• Ephemeral: off (keep the node registered across reboots)
• Pre-approved: on if your tailnet has device approval enabled
• Tags: add tag:server or tag:prod — you will reference these in ACLs later
• Expiration: 90 days is the default

Bring up the tunnel

On the VPS, run:

sudo tailscale up \
  --authkey="tskey-auth-xxxxxxxxxxxxxxxxxxxxxxxxxxxx" \
  --hostname="web-vps-01" \
  --advertise-tags="tag:server"

Expected output (nothing on success, prompt returns immediately). Verify status:

tailscale status

Expected output:

100.101.102.103  web-vps-01           [email protected] linux   -
100.120.130.140  laptop               [email protected] macOS   active; direct 192.0.2.5:41641, tx 12340 rx 45670
100.200.210.220  phone                [email protected] iOS     idle

The first column is the tailnet IP, assigned from the 100.64.0.0/10 CGNAT range reserved for Tailscale. The VPS is now reachable from every other peer on your tailnet at 100.101.102.103 without any firewall changes.

Useful flags when you first bring the node up

• --ssh enables Tailscale SSH on this node (see Step 8).
• --advertise-routes=10.0.0.0/24 makes this node a subnet router (see Step 5).
• --advertise-exit-node advertises the node as an exit option (see Step 6).
• --accept-dns=true (default) applies the tailnet's DNS settings including MagicDNS.
• --accept-routes is required if you want this node to use other subnet routers. VPSes acting only as servers usually leave it off.

sudo tailscale up \
  --authkey="tskey-auth-xxxxxxxxxxxxxxxxxxxxxxxxxxxx" \
  --hostname="web-vps-01" \
  --advertise-tags="tag:server" \
  --ssh \
  --advertise-routes="10.0.0.0/24" \
  --advertise-exit-node

Step 4: Enable MagicDNS

MagicDNS is Tailscale's automatic DNS feature: it gives every node a short hostname (web-vps-01, laptop, phone) and an FQDN (web-vps-01.tailXXXXX.ts.net), and resolves both to the correct tailnet IP without any /etc/hosts edits.

Turn on MagicDNS in the admin console

Verify MagicDNS from the VPS

From the Ubuntu VPS, resolve your laptop by short name:

tailscale ip laptop

Expected output:

100.120.130.140

Or ping another tailnet peer by short hostname:

ping -c 2 laptop

Expected output:

PING laptop.tailXXXXX.ts.net (100.120.130.140) 56(84) bytes of data.
64 bytes from laptop: icmp_seq=1 ttl=64 time=12.3 ms
64 bytes from laptop: icmp_seq=2 ttl=64 time=11.9 ms

From this point on you can ssh user@web-vps-01 from any tailnet peer, point Grafana at http://prometheus-vps:9090, or curl http://internal-api without maintaining DNS records or hosts files anywhere.

Step 5: Advertise a Subnet Router

A subnet router lets a single Tailscale node bridge a non-Tailscale network into the tailnet. The classic use case on a VPS is exposing the provider's private VLAN (for example the 10.0.0.0/24 that Contabo attaches to VPSes in the same data center) so other tailnet peers can reach databases or internal services that are not worth installing Tailscale on.

Enable IP forwarding on the VPS

The kernel has to forward packets for this to work. Enable forwarding persistently:

echo 'net.ipv4.ip_forward = 1' | sudo tee -a /etc/sysctl.d/99-tailscale.conf
echo 'net.ipv6.conf.all.forwarding = 1' | sudo tee -a /etc/sysctl.d/99-tailscale.conf
sudo sysctl -p /etc/sysctl.d/99-tailscale.conf

Expected output:

net.ipv4.ip_forward = 1
net.ipv6.conf.all.forwarding = 1

Advertise the route

Re-run tailscale up with --advertise-routes, preserving any flags you already set:

sudo tailscale up \
  --hostname="web-vps-01" \
  --advertise-tags="tag:server" \
  --ssh \
  --advertise-routes="10.0.0.0/24"

If the VPS is reachable on a second private subnet too, list them comma-separated: --advertise-routes="10.0.0.0/24,192.168.50.0/24".

Approve the route in the admin console

Advertised routes are pending until an admin approves them. In the admin console, open Machines, click the VPS row, then under Subnet routes enable the CIDR you advertised. This is a deliberate safety step so an attacker who compromises a node cannot automatically expose new networks.

Verify that the route is live:

tailscale status --peers=false

Expected output includes:

100.101.102.103  web-vps-01  [email protected] linux   offers exit node; routes=10.0.0.0/24

From another tailnet peer, you can now hit 10.0.0.5 directly and packets are routed via the VPS over WireGuard.

Step 6: Advertise the VPS as an Exit Node

An exit node sends all of a peer's internet-bound traffic out through the VPS, much like a commercial VPN endpoint. This is useful for travelling laptops in restrictive networks, for putting all personal devices behind a single EU IP, or for giving a team a consistent outbound IP for third-party allowlists.

Advertise exit-node status

IP forwarding is already on from Step 5. Re-run tailscale up with --advertise-exit-node added:

sudo tailscale up \
  --hostname="web-vps-01" \
  --advertise-tags="tag:server" \
  --ssh \
  --advertise-routes="10.0.0.0/24" \
  --advertise-exit-node

Approve and use the exit node

In the admin console, open the VPS and enable Use as exit node. On any client (laptop, phone, another VPS), select the exit node either in the Tailscale app or by CLI:

sudo tailscale up --exit-node=web-vps-01 --exit-node-allow-lan-access

--exit-node-allow-lan-access keeps your local LAN (printer, router admin, other home devices) reachable while internet traffic goes through the VPS.

Verify the public IP from the client's point of view:

curl https://ifconfig.me

The response should be the VPS's public IPv4 — confirming your traffic is egressing through the tailnet exit node.

To stop using the exit node, re-run tailscale up without the flag:

sudo tailscale up --exit-node=

Step 7: Transfer Files with Taildrop

Taildrop is a built-in file-transfer feature that works peer-to-peer over the same WireGuard tunnels as the rest of the tailnet. No intermediate server, no exposed ports, no ngrok-style tunnels.

Send a file from a laptop to the VPS

On the sending device, run:

tailscale file cp ./backup.tar.gz web-vps-01:

The trailing colon is required — it tells the CLI you are targeting a peer, not a local path.

Receive the file on the VPS

On the VPS:

tailscale file get /root/incoming/

Expected output:

received "backup.tar.gz" from laptop (100.120.130.140)

The file now sits under /root/incoming/. Taildrop transfers are end-to-end encrypted via WireGuard and never transit a Tailscale server.

Daemonize incoming files

You can leave a long-running receiver that stores files as they arrive:

tailscale file get --loop --wait /root/taildrop-inbox/

Step 8: Enable Tailscale SSH

Tailscale SSH replaces OpenSSH key management with tailnet identity. Instead of distributing authorized_keys files, you write an ACL rule that says "users in group admin may SSH to tag:server as root", and Tailscale handles the rest. There are no SSH keys to rotate, no lost-laptop emergencies, and every session is logged to the admin console.

Turn on Tailscale SSH on the VPS

If you did not pass --ssh back in Step 3, enable it now:

sudo tailscale up --ssh

Confirm the SSH server is active

tailscale status | grep -i ssh

Expected output:

web-vps-01  100.101.102.103  tag:server  offers: ssh

Connect from another tailnet peer

From a laptop on the same tailnet:

ssh root@web-vps-01

The first connection shows a Tailscale-branded MOTD confirming tailnet auth; subsequent connections go straight to a shell. No keypair, no password.

Keep OpenSSH as a break-glass path

Leave OpenSSH running on port 22 with public-key authentication as a fallback, but restrict it to your admin IPs via UFW:

sudo ufw allow from YOUR_ADMIN_IP to any port 22 proto tcp
sudo ufw deny 22
sudo ufw enable

Once you are confident in Tailscale SSH you can stop OpenSSH entirely, but most operators keep it as insurance.

Step 9: Lock the Tailnet Down with ACLs

By default a new tailnet has an allow-everything ACL. This is fine for a single-operator personal tailnet but unacceptable for a team or for any production stack. Tailscale ACLs are written in HuJSON (JSON with comments) and applied tailnet-wide — there is no per-node config, which eliminates drift.

Edit the ACL

Open login.tailscale.com/admin/acls and replace the default policy with something like:

{
  // Define tag owners — who is allowed to mint auth keys with these tags.
  "tagOwners": {
    "tag:server": ["autogroup:admin"],
    "tag:prod":   ["autogroup:admin"],
    "tag:dev":    ["group:engineering"]
  },
  // Define groups of users for easier rule writing.
  "groups": {
    "group:engineering": ["[email protected]", "[email protected]"],
    "group:ops":         ["[email protected]"]
  },
  // ACL rules evaluated top-to-bottom; first match wins.
  "acls": [
    // Ops has full access to all servers on any port.
    {
      "action": "accept",
      "src":    ["group:ops"],
      "dst":    ["tag:server:", "tag:prod:"]
    },
    // Engineering can reach dev servers on any port, prod only on HTTPS and database.
    {
      "action": "accept",
      "src":    ["group:engineering"],
      "dst":    ["tag:dev:*"]
    },
    {
      "action": "accept",
      "src":    ["group:engineering"],
      "dst":    ["tag:prod:443", "tag:prod:5432"]
    },
    // Servers may talk to each other freely (e.g., monitoring, backups).
    {
      "action": "accept",
      "src":    ["tag:server", "tag:prod"],
      "dst":    ["tag:server:", "tag:prod:"]
    }
  ],
  // Tailscale SSH rules — who can SSH as which Unix user.
  "ssh": [
    {
      "action": "accept",
      "src":    ["autogroup:admin", "group:ops"],
      "dst":    ["tag:server", "tag:prod"],
      "users":  ["root", "ubuntu"]
    },
    {
      "action":    "check",
      "src":       ["group:engineering"],
      "dst":       ["tag:dev"],
      "users":     ["ubuntu"],
      "checkPeriod": "12h"
    }
  ]
}

The ACL above establishes tag ownership, named user groups, a least-privilege pattern where engineering only touches ports they need, free server-to-server traffic for monitoring, and differentiated SSH policies (admins pass through, engineers must re-authenticate every 12 hours).

Validate before saving

Click Preview in the admin console; Tailscale will validate the HuJSON, expand tags, and show you the effective access matrix. When it looks correct, click Save.

Test the ACL

The admin console has a Tests tab where you can assert "user X should be able to reach destination Y on port Z". Add tests for your critical paths so any future ACL edit that breaks production SSH fails loudly before it ships.

Troubleshooting

Key commands for diagnostics

# Run the full network check
tailscale netcheck
Show the full status including derp/direct
tailscale status --json | jq
Live log stream
sudo journalctl -u tailscaled -f
Show the current config
tailscale debug prefs

FAQ

Is Tailscale free to use on a VPS?

Yes. Tailscale's Personal plan is free for up to 100 devices and three users and includes MagicDNS, subnet routers, exit nodes, Tailscale SSH, Taildrop, and ACL policies. Most single-operator VPS fleets never hit that ceiling. The paid tiers add SSO providers, user groups, ACL tests, audit logs, and commercial use at scale.

How is Tailscale different from raw WireGuard?

Tailscale uses the WireGuard protocol for the data plane but adds a coordination service that handles key exchange, NAT traversal, DNS, ACL distribution, and identity. With raw WireGuard you manually generate keypairs on every peer, edit wg0.conf files, track endpoint IPs, and rotate keys by hand. Tailscale replaces all of that with a single curl install and a browser login. Our WireGuard install guide covers the manual path if you need it.

Do I need to open firewall ports for Tailscale?

No inbound ports are required. Tailscale establishes direct peer-to-peer WireGuard tunnels using UDP hole punching and falls back to encrypted DERP relays when NAT traversal fails. You can keep UFW blocking all inbound traffic and your VPS will still be reachable from anywhere on your tailnet. This is a fundamental security win over OpenVPN or static WireGuard servers that need an exposed UDP port.

What is MagicDNS?

MagicDNS is Tailscale's automatic DNS feature. It resolves short hostnames like web-vps to the tailnet IP of that machine without any manual /etc/hosts edits or DNS server. Once enabled in the admin console, you can ssh user@web-vps from any tailnet peer, point Grafana at http://prometheus-vps:9090, or use hostname-based TLS certificates inside the tailnet.

What is the difference between a subnet router and an exit node?

A subnet router advertises a specific private CIDR (for example 10.0.0.0/24) and lets tailnet peers reach non-Tailscale devices inside that subnet — a printer, a NAS, a router admin panel, or a cloud VPC. An exit node sends all of a peer's internet-bound traffic through the node, similar to a commercial VPN. A single VPS can be both at the same time, using --advertise-routes and --advertise-exit-node together.

Should I self-host with Headscale instead?

Use Headscale when you need your own control plane for sovereignty, compliance, or because you exceeded Tailscale's free tier. Headscale is an open-source reimplementation of Tailscale's coordination server and speaks the same client protocol, so official Tailscale clients still work. The trade-off is operating identity, DNS, and key rotation yourself. If you want a fully self-hosted alternative with a bundled dashboard, NetBird is also worth a look.

Is Tailscale SSH a replacement for OpenSSH?

Tailscale SSH is an additional SSH server bound to the Tailscale interface. It authenticates using tailnet identity and ACLs instead of SSH keys, which eliminates key distribution. You can leave OpenSSH installed and running for break-glass access, or disable it entirely once Tailscale SSH is working. We recommend keeping OpenSSH locked to your admin IPs as a fallback during the first month.

How much bandwidth can a CloudCore VPS push as an exit node?

Because WireGuard lives in the kernel, the bottleneck on a VPS is almost always the network interface, not CPU. A CloudCore Starter VPS at EUR 7.99/month routinely saturates the provider's gigabit interface as an exit node. If you plan to exit heavy traffic for multiple users, the Professional tier at EUR 19.99/month gives you more bandwidth headroom and NVMe storage for log retention. Business-tier VPSes at EUR 29.99+/month are overkill for exit-node duty alone, but a good fit if you also want to run Headscale, Grafana, or a private registry on the same host.

Can I run Tailscale inside Docker or LXC?

Yes. Tailscale ships an official Docker image (tailscale/tailscale) and works inside LXC containers with net.ipv4.conf.all.src_valid_mark=1 and the TUN device passed through. For Kubernetes, the Tailscale operator automates sidecars and ingress connectors.

What happens if Tailscale's control plane goes down?

Existing tunnels stay up. The control plane is needed for key rotation, adding new nodes, and ACL changes — not for moving packets. Clients keep talking to each other over WireGuard even if login.tailscale.com is unreachable for hours. This is an explicit design goal documented by Tailscale.

Next Steps

Now that your VPS is on the tailnet, here are the highest-leverage follow-ups:

• Publish ACL tests alongside your policy — Version-control the ACL file in Git and use tailscale file check in CI so a broken rule never reaches production.
• Add more VPSes to the tailnet — Repeat Steps 1–3 on every new server. If you build Ubuntu images ahead of time, bake the Tailscale installer into cloud-init and pass the auth key at boot.
• Secure the HTTP surface — Bind Grafana, Prometheus, Portainer, and every admin panel to the Tailscale interface only (--bind=100.101.102.103:3000 or listen_address = "tailscale0"). Drop public ports entirely.
• Consider Headscale for sovereignty — If regulatory, compliance, or scale reasons push you off Tailscale SaaS, our Headscale install guide walks you through running the control plane on a Business-tier VPS.
• Or switch to NetBird for a full self-host with SSO — The NetBird install guide covers a stack with Zitadel SSO, dashboard, and policies you own end-to-end.
• Benchmark exit-node throughput — Run iperf3 from a client through the exit node and record the number for future capacity planning.
• Read the upstream docs — Bookmark tailscale.com/kb/ for deep dives on Funnel, Serve, Tailscale Lock, Mullvad exit nodes, and the Kubernetes operator.
• Pair Tailscale with an identity-forward SSH stack — If you need recorded SSH sessions or just-in-time access, pair Tailscale SSH with a session recorder like Teleport, or move to NetBird SSH which includes recording natively.

Want a VPS that is Tailscale-ready out of the box?

Our CloudCore Starter VPS runs Ubuntu 24.04 with the WireGuard kernel module enabled, UFW pre-configured, and a static IPv4 — everything you need to run curl -fsSL https://tailscale.com/install.sh | sh and join your tailnet in under two minutes.

- 2 vCPU, 4 GB RAM, 40 GB NVMe SSD

- Unmetered gigabit bandwidth

- EU or US data centers

- EUR 7.99/month — or step up to Professional at EUR 19.99/month or Business at EUR 29.99+/month for heavier exit-node and subnet-router workloads

Launch Your CloudCore VPS Now