How to Set Up Kamatera VPS — Custom Configuration Guide (2026)

I want 3 vCPUs. Not 2. Not 4. Exactly 3. And 5GB of RAM, because my app needs more than 4 but 8 is wasteful. At Vultr, DigitalOcean, Linode — you cannot do this. You pick from a menu of fixed plans and round up to the next tier. Kamatera is the only provider I have used where you build a server the way you build a custom PC: pick every component individually, watch the price update in real time, and pay for exactly what you spec'd. It is genuinely fun to configure. No credit card required for the $100 free trial, phone support if you get stuck, and three US datacenters to choose from. Here is the full walkthrough.

Step 1 — Create Your Kamatera Account ($100 Free Trial)

Head to console.kamatera.com and hit Start Free Trial. Name, email, phone number for SMS verification. That is it. No credit card. I have signed up for dozens of VPS trials and Kamatera is one of the very few that genuinely does not touch your payment info upfront.

The $100 credit lasts 30 days and it is real money — not throttled or feature-gated. You can spin up a 4vCPU/8GB server, configure a load balancer, set up private networking between two boxes, and still have credit left over. I burned through about $38 during a full month of testing a production LEMP stack. The trial is generous enough to actually evaluate the platform properly.

One thing that surprised me: Kamatera has phone support. You can call a human. Vultr, DigitalOcean, Hetzner — all ticket-only. If you are setting up infrastructure for a business and need to talk through architecture decisions, this matters more than most people realize.

After login, the console is straightforward. My Cloud Servers, My Networks, Load Balancers, Managed Services, Billing. Click Create Server and the fun begins.

Step 2 — Understanding Kamatera's Custom Configuration Interface

This is where Kamatera becomes addictive. Instead of a boring dropdown of plans, you get sliders. Real, draggable sliders for every resource. It feels like configuring a custom PC on Newegg, except the PC lives in a datacenter and you pay by the hour. First-time users sometimes stare at this screen for a minute wondering where the "plans" are. There are no plans. You are the plan.

Here is what you are looking at:

• CPU Type: Choose the CPU generation and architecture. Options include Type A (Intel Xeon), Type B (Intel Xeon, higher frequency), and Type D (dedicated cores). For most workloads, Type B offers the best balance of price and performance.
• CPU Cores: A slider from 1 to 104 vCPUs. Yes, 104 — Kamatera can provision servers with over 100 CPU cores. For a web server, 1–4 vCPUs is sufficient.
• RAM: A slider in 1GB increments from 256MB to 512GB. Choose exactly how much you need.
• Storage: Choose storage type (SSD or NVMe), size, and whether to use a single disk or multiple disks.
• Operating System: A dropdown of supported OSes.
• Datacenter: Select from available locations worldwide.
• Networking: Public IP options and private network configuration.

The best part: a live price ticker on the right updates with every slider movement. Drag the RAM from 4GB to 5GB? The monthly estimate jumps by exactly $3.60. Add a vCPU? Another $4.80. You can see exactly where every dollar goes. I wish every provider did this instead of hiding the math behind opaque plan tiers.

Step 3 — Choose CPU, RAM, Storage, and Networking

So what should you actually configure? Here are the specs I would pick for different workloads, based on what I have run on Kamatera myself:

Storage type: SSD is fine for 90% of workloads. NVMe costs a bit more but the IOPS difference is significant for database-heavy apps — if you are running MariaDB with frequent writes, NVMe pays for itself in query latency. Kamatera's standard SSD already outperforms the spinning rust some budget providers still ship.

Networking is where things get interesting. Public IPv4 is included automatically. But if you are planning a multi-server setup — say, web server + database server — tick the "Internal VLAN" box during creation. This gives your servers a private 10.x.x.x network for free. Your database never needs to touch the public internet. I consider this essential for any production deployment.

Step 4 — Select OS and Region

OS selection is a dropdown with the usual suspects: Ubuntu, Debian, CentOS, AlmaLinux, Rocky Linux, and — this is notable — Windows Server 2019 and 2022 with the license baked into the hourly price. Pick Ubuntu 24.04 LTS for this guide.

For US-based deployments, you have three datacenters:

• New York (NY) — Best for US East Coast audiences. Most mature datacenter with the widest feature availability.
• Dallas (TX) — Central US. Good latency for the continental US overall. Best choice if you need balanced coverage across time zones.
• Santa Clara (CA) — US West Coast. Best for US West Coast and Pacific Rim audiences.

Pick whichever is closest to your users. Hetzner gives you one US location. Vultr gives you many but no customization. Kamatera gives you three US locations plus total resource control. That combination is rare.

Name your server something you will not regret in six months. web01-prod-nyc tells you everything at a glance. my-server-2 tells you nothing. You will thank yourself when you have five Kamatera boxes running and need to remember which one hosts what.

Step 5 — First Login via SSH

Hit Create Server and wait about 90 seconds. Kamatera is not Contabo — provisioning is fast. You will get an email with a root password. Like most providers, Kamatera defaults to password authentication. Our first order of business is replacing that with SSH keys before some bot finds your IP.

# Connect using the password from your email
# Replace 203.0.113.40 with your actual server IP
ssh root@203.0.113.40

# Accept the host fingerprint (type 'yes')
# Enter the password from the email

Immediately after login, set up key-based authentication. If you do not already have an SSH key on your local machine, generate one now:

# On your LOCAL machine, generate an SSH key:
ssh-keygen -t ed25519 -C "your-email@example.com"

# Copy the public key to the server
# (Run this on your local machine — it will prompt for the server password)
ssh-copy-id -i ~/.ssh/id_ed25519.pub root@203.0.113.40

# Verify SSH key login works (should NOT ask for password)
ssh root@203.0.113.40

Step 6 — System Update & Configuration

# Update all packages
apt update && apt upgrade -y

# Install essential tools
apt install -y curl wget git unzip htop ufw nano software-properties-common fail2ban

# Set timezone
timedatectl set-timezone America/New_York

# Set hostname
hostnamectl set-hostname web01.yourdomain.com

# Verify system info
uname -a
lsb_release -a
df -h     # Check disk usage
free -m   # Check available memory

Since you chose your exact RAM amount, you might think swap is unnecessary. It is not. Even a well-tuned 4GB server can get OOM-killed during a traffic spike or a runaway PHP process. A 2GB swap file is cheap insurance:

# Add 2GB swap file
sudo fallocate -l 2G /swapfile
sudo chmod 600 /swapfile
sudo mkswap /swapfile
sudo swapon /swapfile

# Make swap permanent
echo '/swapfile none swap sw 0 0' | sudo tee -a /etc/fstab

# Tune swappiness (lower = use RAM more aggressively before swapping)
echo 'vm.swappiness=10' | sudo tee -a /etc/sysctl.conf
sudo sysctl -p

Step 7 — Create Non-Root User

# Create a non-root user
adduser deploy

# Add to sudo group
usermod -aG sudo deploy

# Copy SSH keys to new user
mkdir -p /home/deploy/.ssh
cp /root/.ssh/authorized_keys /home/deploy/.ssh/
chown -R deploy:deploy /home/deploy/.ssh
chmod 700 /home/deploy/.ssh
chmod 600 /home/deploy/.ssh/authorized_keys

# Test new user login in a SEPARATE terminal window
ssh deploy@203.0.113.40
sudo whoami   # Should output: root

# Disable root SSH login and password authentication
sudo nano /etc/ssh/sshd_config
# Set:
# PermitRootLogin no
# PasswordAuthentication no
# PubkeyAuthentication yes

sudo systemctl restart sshd

Step 8 — Configure Firewall (UFW + Kamatera Firewall Rules)

Kamatera is one of the few mid-tier providers that gives you both a cloud-level firewall AND the ability to run UFW on the server itself. Use both. The cloud firewall filters traffic before it ever reaches your box. UFW is your second wall. Two layers, zero excuse for leaving ports exposed.

Kamatera Console Firewall Rules

In the Kamatera console, go to your server's Firewall tab and whitelist only what you need:

• Protocol: TCP, Port: 22, Source: Any
• Protocol: TCP, Port: 80, Source: Any
• Protocol: TCP, Port: 443, Source: Any
• Protocol: ICMP, Source: Any (for ping/monitoring)

Outbound is open by default. Leave it that way unless you have a specific compliance requirement saying otherwise.

UFW (OS-Level Firewall)

# Set default policies
sudo ufw default deny incoming
sudo ufw default allow outgoing

# Allow SSH (CRITICAL — do this before enabling UFW)
sudo ufw allow 22/tcp

# Allow web traffic
sudo ufw allow 80/tcp
sudo ufw allow 443/tcp

# Rate-limit SSH to prevent brute force
sudo ufw limit 22/tcp

# Enable UFW
sudo ufw enable

# Verify rules
sudo ufw status verbose

# Configure and enable fail2ban for additional SSH protection
sudo cp /etc/fail2ban/jail.conf /etc/fail2ban/jail.local
sudo nano /etc/fail2ban/jail.local

# Under [sshd] section, set:
# enabled = true
# maxretry = 3
# bantime = 48h
# findtime = 10m

sudo systemctl enable fail2ban
sudo systemctl start fail2ban
sudo fail2ban-client status sshd

Step 9 — Install Nginx

# Install Nginx
sudo apt install nginx -y

# Enable and start
sudo systemctl enable nginx
sudo systemctl start nginx

# Confirm it's running
sudo systemctl status nginx

# Create web root
sudo mkdir -p /var/www/yourdomain.com/html
sudo chown -R deploy:www-data /var/www/yourdomain.com
sudo chmod -R 755 /var/www/yourdomain.com

echo '<h1>Kamatera VPS is working!</h1>' | sudo tee /var/www/yourdomain.com/html/index.html

# Create Nginx server block
sudo nano /etc/nginx/sites-available/yourdomain.com

Drop in this server block — adjust the domain and PHP socket path to match your setup:

server {
    listen 80;
    listen [::]:80;

    server_name yourdomain.com www.yourdomain.com;
    root /var/www/yourdomain.com/html;
    index index.html index.php;

    # Security headers
    add_header X-Frame-Options "SAMEORIGIN" always;
    add_header X-XSS-Protection "1; mode=block" always;
    add_header X-Content-Type-Options "nosniff" always;

    location / {
        try_files $uri $uri/ =404;
    }

    location ~ \.php$ {
        include snippets/fastcgi-php.conf;
        fastcgi_pass unix:/run/php/php8.3-fpm.sock;
    }

    location ~ /\.ht {
        deny all;
    }
}

# Enable the site
sudo ln -s /etc/nginx/sites-available/yourdomain.com /etc/nginx/sites-enabled/
sudo rm /etc/nginx/sites-enabled/default

# Test syntax
sudo nginx -t

# Reload Nginx
sudo systemctl reload nginx

Step 10 — Domain & DNS

Kamatera does not host DNS for you, but that is standard for most providers outside of Vultr and Linode. Point your domain at your registrar or Cloudflare:

# Check DNS propagation
dig yourdomain.com +short

# If not propagated yet, test with a direct IP request:
curl -H "Host: yourdomain.com" http://203.0.113.40

# Full propagation typically takes 5-30 minutes with a 300s TTL

Step 11 — SSL with Certbot

# Install Certbot
sudo apt install certbot python3-certbot-nginx -y

# Obtain SSL certificate
sudo certbot --nginx -d yourdomain.com -d www.yourdomain.com

# Certbot prompts:
# 1. Email address
# 2. Agree to Terms of Service
# 3. HTTP to HTTPS redirect (choose option 2)

# Test automatic renewal
sudo certbot renew --dry-run

# Check certificate details
sudo certbot certificates

# Verify HTTPS is working
curl -I https://yourdomain.com

Step 12 — Kamatera Features (Load Balancers, Private Networks, Managed Services)

Load Balancers

Kamatera has managed load balancers, and they are good. HTTP, HTTPS, TCP — with session persistence and configurable health checks. I used one to distribute traffic across two 2vCPU/4GB web servers and the setup took about 10 minutes from the console. The cost is separate from your server billing, but for production HA setups, it is a fraction of what AWS charges for an ALB.

Create one at My Cloud → Load Balancers → Create Load Balancer. Add your servers as backend targets and point the health check at / or a dedicated /health endpoint.

Private Networks (VLANs)

I mentioned the VLAN earlier. It deserves more attention. The Internal VLAN gives your servers a private 10.x.x.x network — completely isolated from the public internet, zero additional cost. Your web server talks to your database over a private link that nobody outside Kamatera's datacenter can even see:

# After enabling a private VLAN on both servers in Kamatera console,
# verify the private network interface:
ip addr show

# You should see an interface like eth1 with a 10.x.x.x address
# Configure MariaDB to only listen on the private interface:
sudo nano /etc/mysql/mariadb.conf.d/50-server.cnf
# Set: bind-address = 10.0.0.2  (your private IP)

sudo systemctl restart mariadb

Managed Services

If self-managing databases and Kubernetes is not your idea of a good time, Kamatera offers fully managed versions of MySQL, PostgreSQL, Redis, and even managed K8s. Billed separately. Not cheap. But for small teams that want enterprise infrastructure without hiring a dedicated DevOps person, the managed services are worth a conversation with their sales team.

Setting Up PHP-FPM and MariaDB

Since you specced your server with exact resources for a LEMP stack, let's install the rest of it. MariaDB first, then PHP-FPM:

# Install MariaDB
sudo apt install mariadb-server mariadb-client -y
sudo systemctl enable mariadb
sudo systemctl start mariadb
sudo mysql_secure_installation

# Create a database and user
sudo mariadb
CREATE DATABASE myapp_db CHARACTER SET utf8mb4 COLLATE utf8mb4_unicode_ci;
CREATE USER 'myapp_user'@'localhost' IDENTIFIED BY 'StrongPassword123!';
GRANT ALL PRIVILEGES ON myapp_db.* TO 'myapp_user'@'localhost';
FLUSH PRIVILEGES;
EXIT;

# Install PHP 8.3
sudo add-apt-repository ppa:ondrej/php -y
sudo apt update
sudo apt install php8.3-fpm php8.3-mysql php8.3-curl php8.3-gd \
  php8.3-mbstring php8.3-xml php8.3-zip php8.3-intl -y

sudo systemctl enable php8.3-fpm
sudo systemctl start php8.3-fpm

# Verify PHP-FPM socket exists
ls /run/php/php8.3-fpm.sock

Step 13 — Scaling Up/Down (Unique to Kamatera)

This is where the custom-build philosophy really pays off. Need more RAM because your traffic doubled? Drag the slider up. Need to drop back down after a seasonal spike? Drag it back. Kamatera treats resource allocation as fluid, not fixed — because their hypervisor was designed for it from day one.

Hot Scaling (No Reboot Required)

CPU and RAM can often be bumped up without a reboot. In the console, go to Power & Resize and move the sliders. If the hypervisor can handle a live migration, you will see "Resize Without Reboot" — your app never goes down. I have scaled from 2vCPU to 4vCPU mid-traffic-spike without dropping a single request. That is hard to do on Vultr or DO, which require a power cycle for any resize.

Cold Scaling (Reboot Required)

Disk resizes and certain large jumps require a full stop-start. Kamatera shuts down the server, moves it to appropriate hardware, and brings it back up. Expect 2–5 minutes of downtime. Not ideal, but far better than the "contact support and wait 6 hours" approach at Contabo.

# After a disk resize, extend the filesystem to use new space:

# Check current disk info
lsblk
df -h

# If you added disk space, extend the partition and filesystem:
# (Replace /dev/vda1 with your actual partition)
sudo growpart /dev/vda 1
sudo resize2fs /dev/vda1

# Verify the new space is available
df -h

Infrastructure Monitoring

# Set up basic monitoring with cron
sudo nano /usr/local/bin/health-check.sh

#!/bin/bash
# Basic health check for Kamatera server
DISK_USAGE=$(df / | tail -1 | awk '{print $5}' | tr -d '%')
MEM_FREE=$(free -m | awk '/^Mem:/{print $4}')

echo "$(date): Disk: ${DISK_USAGE}% | Free RAM: ${MEM_FREE}MB"

if [ "$DISK_USAGE" -gt 85 ]; then
    echo "WARNING: Disk at ${DISK_USAGE}%"
fi

for service in nginx php8.3-fpm mariadb; do
    if ! systemctl is-active --quiet $service; then
        echo "CRITICAL: $service is down. Restarting..."
        sudo systemctl restart $service
    fi
done

# Make executable and schedule
sudo chmod +x /usr/local/bin/health-check.sh

# Run every 5 minutes
(crontab -l 2>/dev/null; echo "*/5 * * * * /usr/local/bin/health-check.sh >> /var/log/health-check.log 2>&1") | crontab -

# Install unattended security upgrades
sudo apt install unattended-upgrades -y
sudo dpkg-reconfigure -plow unattended-upgrades

Frequently Asked Questions

How does Kamatera billing work exactly?

Kamatera bills per hour for each component separately: CPU (per vCPU/hour), RAM (per GB/hour), storage (per GB/month), and bandwidth (per GB over the included amount). A 2vCPU/4GB server in New York costs approximately $0.026/hour = $19/month. The hourly model means you only pay for the exact time servers run — ideal for dev/test environments that you spin up and tear down frequently.

Can I try Kamatera without a credit card?

Yes. Kamatera's free trial genuinely does not require a credit card at signup — unusual in the VPS industry. You get $100 credit that lasts 30 days. After the trial, you need a payment method to continue. The trial is sufficient to run a 4vCPU/8GB server for the full 30 days, or a 2vCPU/4GB server for about 2 months at current rates.

What makes Kamatera's configuration different from other providers?

Instead of choosing from preset plans (1vCPU/1GB, 2vCPU/4GB, etc.), Kamatera lets you pick exact values: 1–104 vCPUs, any GB of RAM, any GB of storage. This means you can create a 3vCPU/7GB server if that's exactly what you need — no paying for resources you don't use. The real-time pricing calculator shows your exact hourly and monthly cost as you adjust each slider.

Does Kamatera support Windows VPS?

Yes. Windows Server 2019 and 2022 are available as OS options. The Windows license fee is included in the hourly rate for the server (adds approximately $15–20/mo to the effective cost depending on configuration). Useful for .NET applications, SQL Server, or RDP-based remote desktop workloads. See our best Windows VPS guide for a comparison of Windows VPS options.

How reliable is Kamatera's uptime?

Kamatera offers a 99.95% SLA backed by enterprise hardware (Intel Xeon Gold processors). In our monitoring, they have delivered consistent uptime with rare maintenance windows announced in advance. Their New York and Dallas DCs are the most mature; Santa Clara is newer but equally reliable. The 99.95% SLA equates to a maximum of ~4.4 hours downtime per year.

What makes Kamatera different from other VPS providers?

Kamatera's unique selling point is fully custom server configurations. Instead of fixed plans, you choose exact CPU cores (1–104), RAM (256MB–512GB), and storage independently. This means you can build a 1-core/8GB RAM server for memory-heavy apps, or a 4-core/2GB server for CPU-bound tasks. No other major VPS provider offers this level of granularity at the same price point.

Does Kamatera charge for server snapshots?

Yes. Kamatera charges $0.05/GB/month for stored snapshots. A 20GB server snapshot costs approximately $1/mo. Snapshots are incremental after the first one, so subsequent snapshots are smaller and cheaper. For cost-effective backups, combine Kamatera snapshots (for disaster recovery) with rsync-based file backups to external storage (for granular file recovery).