Kubernetes VPS: a real k3s cluster on three small nodes.
First month $1, then the normal monthly price. One per customer.
You get a KVM instance with full root, your own kernel, nested virtualisation and NVMe RAID10 storage, in Amsterdam or New York. Three S-4s and you have a k3s learning cluster, with Traefik and local storage already in it. One S-4 on its own is a homelab in the cloud. Talos? Boots from a custom ISO, no problem. Out of the box the nodes talk over their public IPs, which we mention early on purpose, and further down we show how to put WireGuard or Tailscale in between.
Transparent pricing
Plans and prices
| Plan | vCPU | Memory | NVMe | Traffic | Monthly | 1 year | |
|---|---|---|---|---|---|---|---|
| Standard | |||||||
| S-2Standard | 1vCPU | 2 GBMemory | 30 GBNVMe RAID10 | UnlimitedTraffic | $7.99/moFirst month $1 | $7.19/mo on 1 year | Start for $1 |
| S-4Standard | 2vCPU | 4 GBMemory | 60 GBNVMe RAID10 | UnlimitedTraffic | $13.99/moFirst month $1 | $12.59/mo on 1 year | Start for $1 |
| S-8Standard | 3vCPU | 8 GBMemory | 120 GBNVMe RAID10 | UnlimitedTraffic | $24.99/moFirst month $1 | $22.49/mo on 1 year | Start for $1 |
| S-16Standard | 4vCPU | 16 GBMemory | 240 GBNVMe RAID10 | UnlimitedTraffic | $44.99/moFirst month $1 | $40.49/mo on 1 year | Start for $1 |
| S-32Standard | 8vCPU | 32 GBMemory | 480 GBNVMe RAID10 | UnlimitedTraffic | $84.99/moFirst month $1 | $76.49/mo on 1 year | Start for $1 |
| S-64Standard | 16vCPU | 64 GBMemory | 720 GBNVMe RAID10 | UnlimitedTraffic | $159.99/moFirst month $1 | $143.99/mo on 1 year | Start for $1 |
| Dedicated CPU | |||||||
| D-4Dedicated | 1vCPU | 4 GBMemory | 45 GBNVMe RAID10 | UnlimitedTraffic | $37.00/moFirst month $1 | $31.45/mo on 1 year | Start for $1 |
| D-8Dedicated | 4vCPU | 8 GBMemory | 90 GBNVMe RAID10 | UnlimitedTraffic | $69.00/moFirst month $1 | $58.65/mo on 1 year | Start for $1 |
| D-16Dedicated | 4vCPU | 16 GBMemory | 160 GBNVMe RAID10 | UnlimitedTraffic | $118.00/moFirst month $1 | $100.30/mo on 1 year | Start for $1 |
| D-32Dedicated | 6vCPU | 32 GBMemory | 220 GBNVMe RAID10 | UnlimitedTraffic | $215.00/mo | $182.75/mo on 1 year | Deploy D-32 |
| D-64Dedicated | 10vCPU | 64 GBMemory | 400 GBNVMe RAID10 | UnlimitedTraffic | $377.00/mo | $320.45/mo on 1 year | Deploy D-64 |
| High Memory | |||||||
| H-64High Memory | 8vCPU | 64 GBMemory | 480 GBNVMe RAID10 | UnlimitedTraffic | $249.00/mo | $211.65/mo on 1 year | Deploy H-64 |
| H-128High Memory | 16vCPU | 128 GBMemory | 960 GBNVMe RAID10 | UnlimitedTraffic | $459.00/mo | $390.15/mo on 1 year | Deploy H-128 |
| H-192High Memory | 24vCPU | 192 GBMemory | 1.4 TBNVMe RAID10 | UnlimitedTraffic | $669.00/mo | $568.65/mo on 1 year | Deploy H-192 |
Three ways to run containers across VPS nodes.
Ask us and most days we say k3s. Swarm is the simpler tool, Talos the stricter one. All three sit on the same KVM base with your own kernel underneath, so the choice comes down to how much ceremony you want. Not to what the server can do. It can do all three.
k3s: full Kubernetes in one binary
k3s is certified Kubernetes in a single binary, with containerd, flannel, CoreDNS, Traefik and a local-path storage provisioner built in. One curl command installs it. It runs on an S-4. And what you learn on it transfers to any other Kubernetes.
Docker Swarm: two nodes, one afternoon
If you already write docker compose files, Swarm turns two S-4s into a cluster with docker swarm init and docker stack deploy. No etcd, no CRDs, no operators. The right stop if Kubernetes is more than the workload needs.
Talos: an immutable node OS
Talos Linux has no shell and no SSH; you manage it through talosctl and its API. Upload the Talos ISO through custom ISO, boot the node, apply a machine config, and bootstrap the cluster.
Single node: a homelab in the cloud
One S-4 running k3s gives you a full API server, ingress and storage for a handful of personal apps. Unlimited traffic, a public IP, done.
Which plan for which cluster.
Kubernetes takes its slice of every node first. Your pods get whatever is left over. So size for the overhead plus the workload, not the workload alone.
| Setup | Plan | Why |
|---|---|---|
| Single-node k3s homelab | 1 x S-4 | 4 GB leaves room for a few apps once the control plane has eaten |
| Learning cluster, meaning 1 server and 2 agents | 3 x S-4 | Real scheduling across nodes, at the lowest total price |
| Docker Swarm for compose stacks | 2 x S-4 | Manager plus worker, and Swarm's own overhead stays small |
| Cluster running real services | 3 x S-8 | 8 GB per node ends the memory pressure that 4 GB nodes run into |
| A control plane that must not wobble | D-8 servers | Pinned cores and DDR5 ECC, because etcd feels latency |
The learning cluster we recommend is three S-4s (2 vCPU, 4 GB, 60 GB NVMe each) at €11.99 a month ($13.99) per node. That is the smallest setup where pods actually move between nodes, a node can be drained, and an ingress on one node routes to a pod on another. One server plus two agents is the simplest layout. Three servers with embedded etcd also works on S-4, but etcd on every node takes memory and disk I/O.
Four gigabytes is workable. Not generous. The k3s server, containerd, Traefik, CoreDNS and metrics-server all take their share before your first application pod starts. Once the cluster runs something with a database in it, move the nodes to S-8 (3 vCPU, 8 GB, 120 GB) at €21.99 a month ($24.99). The 120 GB disk matters as much as the RAM, because images and local-path volumes live on the node, and 60 GB on S-4 is the first thing you run out of.
Want the control plane on a dedicated core? D-8 (4 vCPU, 8 GB, 90 GB) at €64.00 a month ($69.00) pins four EPYC Genoa cores and uses DDR5 ECC memory. etcd is sensitive to latency, and a shared vCPU can show up as leader elections under load, which is a strange thing to debug at first. S-2 (1 vCPU, 2 GB, 30 GB) at €6.99 a month ($7.99) is too small for a k3s node with anything running on it. Use it as a bastion instead. Resizing adds RAM and vCPU in place with one short reboot, so start on S-4 and grow only the nodes that need it.
Setting up a three-node k3s cluster on BuyVPS.
Step 1: order three nodes and lock the firewall
Order three S-4s in the same region with Ubuntu 24.04, or start with one on the $1 trial month and add the other two later. Before k3s goes on, allow SSH, the API server and the ingress ports, and everything else only from the other two nodes.
Step 2: install the k3s server with the WireGuard backend
The install script is published by the project at k3s.io. Because the nodes reach each other over public IPs, tell flannel to use its WireGuard backend so pod traffic between nodes is encrypted.
Step 3: join the two agents with the token
On node 2 and node 3 run the same installer in agent mode, with K3S_URL pointing at node 1 on port 6443 and the node token from /var/lib/rancher/k3s/server/node-token on the server.
Step 4: kubectl from your laptop
Now copy the kubeconfig to your workstation. It still points at the local address, so swap that for the server's IP. Then list the nodes and wait until all three show Ready. Usually that's well under a minute.
Then a first deployment, exposed through the Traefik ingress that k3s ships with.
Step 5: ingress and storage are already there
k3s ships Traefik as the ingress controller and the local-path provisioner as the default StorageClass. So a Deployment with a Service, an Ingress and a PersistentVolumeClaim works right out of the box, no extra installs.
A local-path volume is nothing more than a directory on the node's NVMe disk. Which means a pod that uses one is pinned to the node where that volume was created. For learning, fine. When a volume has to travel with the pod, look at Longhorn.
Step 6: Docker Swarm instead, on two nodes
First open 2377/tcp, 7946/tcp and udp, and 4789/udp between the nodes.
WireGuard or Tailscale between the nodes.
There is no private VLAN between VPS nodes, so node-to-node traffic crosses the public network. Two ways to encrypt it, and we'd use one of them.
flannel's WireGuard backend
The --flannel-backend=wireguard-native flag in step 2 makes k3s set up WireGuard tunnels between nodes for pod-to-pod traffic. No external service, keys managed by k3s. It covers pod traffic only; the API server and kubelet ports still sit on the public IPs, so the firewall rules from step 1 stay.
Tailscale as the node network
Install Tailscale on all three nodes, then start k3s with --node-ip set to the Tailscale address and --flannel-iface=tailscale0. Every node port, the API server included, is then reachable only inside the tailnet, and so is kubectl from your laptop. The more locked-down layout, at the cost of depending on Tailscale's coordination service.
Pitfalls we see, and how to avoid them.
etcd on a small disk
Run three servers with embedded etcd and every write lands on the disk of all three nodes. The database keeps growing too, because it carries the cluster's history. On the 60 GB of an S-4 that gets tight once images and local-path volumes pile up next to the etcd data. So snapshot etcd to another host on a schedule. And move the servers to S-8 before the disk becomes the incident, because it will.
The API server open to the world
Port 6443 answers on the public IP by default. It requires a client certificate, true, but that's no reason to have it reachable from everywhere. Restrict 6443 in ufw to your own IP and the other nodes, or put the control plane behind Tailscale. Same for 10250, the kubelet port.
Memory pressure on 4 GB nodes
Pods without memory requests and limits are scheduled as if they were free, and one Java app can push a 4 GB node into eviction storms. Set requests and limits on everything, watch kubectl top nodes, and resize the busy node to S-8 in place.
Nodes across two regions
One cluster spanning Amsterdam and New York sounds like resilience. It is not. etcd wants its members close together, and with 75 to 90 ms between the regions every write waits on the far side, leadership flaps, and the rest of the cluster queues up behind it. We've seen it. Run one cluster per region and keep the two apart.
Pick the region closest to your users.
All nodes in one region, and that region close to whoever hits the ingress. From Amsterdam we measure 9.0 ms to London and 8.5 ms to Frankfurt; from New York, Boston is 5 to 8 ms and Toronto 10 to 15 ms. See VPS Amsterdam, VPS New York and KVM VPS.
Questions about running Kubernetes on a VPS.
How many nodes do I need for a k3s learning cluster?
Three. One server and two agents, each on its own S-4, and from there on scheduling, draining and cross-node networking start behaving the way they do in a real cluster. A single S-4 runs k3s just fine, and for a homelab that's plenty. But drain a node when there is no other node to take the pods, and you learn very little about what happens between them.
Is there a private network between my VPS nodes?
No. Nodes talk over their public IPv4 or IPv6 addresses. Use the WireGuard backend in flannel, or Tailscale, to encrypt the node traffic. And firewall the API server and kubelet ports so only the nodes and your own IP get in.
Does k3s include an ingress controller and storage?
Yes. Traefik comes installed as the ingress controller and the local-path provisioner is the default StorageClass, so Ingress objects and PersistentVolumeClaims work right after install. One catch. Local-path volumes stay on the node where they were created.
Can I run Talos Linux?
Yes. Upload the Talos ISO through the custom ISO option, boot the VPS from it in the VNC console, then push a machine configuration with talosctl and bootstrap from your workstation. What catches people out, every time, is the total absence of SSH. There is no shell to log in to. Everything, a reboot included, goes through the Talos API.
Is 4 GB per node enough?
For learning, and for a handful of small apps, yes. The catch is that the control plane eats first. kubelet, the API server and etcd take their memory before a single one of your pods starts. So put requests and limits on your workloads from day one, not after the first eviction, which is when most people think of it. And if a node keeps evicting pods anyway, resize it in place to S-8. RAM and vCPU change with one short reboot, and the IP stays where it was.
Can I put nodes in both Amsterdam and New York?
Not in one cluster. The regions are 75 to 90 ms apart, and that is too slow for etcd. Cross-node pod traffic turns sluggish as well. Run one cluster per region instead.
Deploy a measured VPS
From $6.79/mo on a 2-year term. KVM on AMD EPYC, NVMe RAID10, ECC memory. No setup fee, cancel monthly.
30-day performance guarantee. Not satisfied? Full refund, no admin fee. How it works