How to set up a Kamatera VPS safely in 2026

A Kamatera server boots in about a minute, and a freshly booted server with password login enabled starts getting brute-forced within the hour. This walks through creating one and closing it down properly, with the decisions that cannot be undone flagged before you reach them.

You need an account, a terminal, and an SSH key pair. If you have never made one: ssh-keygen -t ed25519 -C "you@example.com" writes a private key to ~/.ssh/id_ed25519 and the public half to ~/.ssh/id_ed25519.pub. The public half is the part you paste into Kamatera. The private half never leaves your machine.

Before you click Create: the two choices you cannot take back

Most of the build screen is reversible. Two parts are not, and both are easy to click past.

1. The billing cycle. Hourly bills by the minute and stops when the server is terminated. Monthly is slightly cheaper per hour and charges you for the whole month even if you delete the server on the 3rd. There is no switch in the console afterwards — changing it means building a new server and migrating. For anything you are testing, pick hourly. You can always rebuild on monthly once the thing is clearly staying.
2. The primary disk size. You can grow a boot volume later. You can never shrink one. A 20 GB boot disk plus a separate data volume you can detach is almost always better than a 200 GB boot disk you are stuck paying $0.05 per GB for. Storage is cheap; permanent storage decisions are not.

One more worth deciding early: the data centre. Pick the one nearest your users, not nearest you. Kamatera has 18 to choose from and the latency difference between a good pick and a lazy one is larger than any CPU upgrade you can buy. Moving later means rebuilding the server in the new zone and migrating the data, so this is a cheap decision now and an expensive one in six months.

The CPU type is the other choice people get wrong in a way that is annoying rather than permanent. The $4 price is Type A — Availability, which is shared budget capacity, and a production web server on it will have afternoons where it is inexplicably slow because of somebody else's workload. Type B — General Purpose is the sensible default for anything a user is waiting on. This one is changeable later, as a resize and a reboot, which is why it does not sit in the list above — but picking it right the first time saves you diagnosing a performance problem that is really a purchasing decision.

Creating the server

From the Kamatera console, Create New Server walks through six panels. The ones that need thought:

1. Zone. The location list, with availability shown per zone. If a specific CPU type is greyed out, it is sold out in that zone — pick another rather than downgrading the CPU.
2. Image. Ubuntu 24.04 LTS is the safe default for most stacks: five years of security updates and the widest package coverage. The application images (Docker, WordPress, Plesk) save a few minutes and cost you knowing exactly what is installed. For a server you intend to keep, start from the plain OS.
3. Server specs. CPU type first, then cores, then RAM, then disk. Type B — General Purpose for anything serving real traffic; Type A — Availability is fine for a scratch box. Our Kamatera review explains what the four CPU classes actually mean.
4. Networking. Leave the public network attached. If you plan a private tier later, add the internal network now — attaching one afterwards is possible but means a reboot.
5. Access. Choose SSH Key rather than password, and paste the contents of your .pub file. This is the single highest-value click on the page: the server then has no password to guess, from its first second of existence.
6. Billing cycle and quantity. As above. Hourly unless you are certain.

Click Create and the machine is up in roughly a minute. The console shows its public IPv4 address on the server detail page.

The first ten minutes on the box

Connect with ssh root@your.server.ip. If you injected a key, it lets you straight in. Then, in order:

1. Update everything. apt update && apt upgrade -y. A fresh image is as current as the day it was built, which is rarely today.
2. Make a user that is not root. adduser deploy, then usermod -aG sudo deploy, then copy your key across with rsync --archive --chown=deploy:deploy ~/.ssh /home/deploy. Log out, log back in as deploy, and confirm sudo -v works before you do the next step.
3. Close the root door. In /etc/ssh/sshd_config set PermitRootLogin no and PasswordAuthentication no, then systemctl restart ssh. Keep your existing session open while you test a new one from a second terminal — if you have made a mistake, that open session is how you fix it instead of rebuilding.
4. Turn on unattended security patching. apt install unattended-upgrades -y then dpkg-reconfigure --priority=low unattended-upgrades. On an unmanaged server nobody else is applying the kernel patch; this is what stops a six-month-old vulnerability from being your problem.

Two firewalls, and why you want both

Kamatera's cloud firewall runs at the network edge, before traffic reaches the machine. UFW runs on the machine itself. Running both is not redundant: the edge firewall survives you misconfiguring the host, and the host firewall survives you misconfiguring the edge.

Start with UFW, because it is two commands: ufw allow OpenSSH, ufw allow 80,443/tcp, then ufw enable. Allow SSH first — enabling UFW with no SSH rule in place disconnects you from a machine you then have to reach through the console's emergency terminal.

Then set the edge rules, ideally restricting SSH to the addresses you actually administer from. The one thing to know is that Kamatera's firewall screen does not save as you type: the rules only take effect when you press Update Firewall at the bottom, and it is far enough down the page to miss. Our firewall walkthrough goes through IP sets and rule ordering properly.

Pointing a domain at it

The server has an IP address and nothing else. To reach it by name, add an A record at your DNS provider pointing your domain — or a subdomain — at the public IPv4 address shown on the server's detail page. Kamatera does not run DNS for you, so this happens wherever your domain is registered.

Two things that save an hour:

• Set the record before you try to issue a TLS certificate. Let's Encrypt validates by making a request to the name, so a certificate request against a name that does not resolve yet fails in a way that looks like a configuration problem and is not. Check with dig yourdomain.com from the server itself, not from your laptop, since the two may be using different resolvers.
• Drop the TTL before you move an existing domain. A record with a day-long TTL means some visitors keep reaching the old address long after you switched. Lower it to 300 seconds a day ahead, move, then raise it again.

When something does not behave

• SSH refuses your key. Nearly always permissions on the server side: chmod 700 ~/.ssh and chmod 600 ~/.ssh/authorized_keys. Run ssh -v on your side to see which key it is actually offering, since an agent with eight keys loaded can be rejected for trying too many before the right one.
• The connection times out rather than refusing. That is a firewall, not sshd. A refusal means the machine answered; a timeout means nothing did. Check the cloud firewall first, and whether you remembered to press its update button.
• You locked yourself out entirely. The console has a browser terminal that connects through the hypervisor rather than the network, so it works even with every port closed. That is the recovery path — not rebuilding.
• The server is slower than expected. Check which CPU type you actually provisioned. Type A is shared budget capacity and will contend under load; moving to Type B is a resize, not a rebuild.

Before you walk away

Two habits worth forming on day one. Take a snapshot once the box is configured and before you install your application — restoring to "clean but hardened" is far better than starting over. And if this server was only ever a test, terminate it rather than powering it off: Kamatera's own documentation is clear that a powered-off server keeps accruing charges, because the disk and the public IP are still held for you.

If you are working through the 30-day trial, our trial guide covers what fits under the $100 allowance and how to close it out cleanly. For something to actually run on the box, self-hosting n8n is a good first project.