I Stopped Sharing Servers With Strangers

I used to not think about who else was running on my host.

Then one day it hit me: my VPS, my containers, my database — all of it was sharing a Linux kernel with workloads from people I'd never met. Their bugs, their breaches, their noisy neighbors were all one kernel vulnerability away from being my problem.

It's not paranoia. It's just architecture.

The shared kernel reality
Most cloud hosting looks like this under the hood:

┌─────────────────────────────┐
│        Host Kernel          │  ← shared by everyone
├─────────┬─────────┬─────────┤
│ Tenant  │ Tenant  │   You   │
│    A    │    B    │         │
└─────────┴─────────┴─────────┘

Containers give you process isolation. They don't give you kernel isolation. Dirty Pipe, runc escapes, privilege escalation chains — they all exploit the same truth: break the kernel, and the walls between tenants get flexible.

Most of the time, it's fine. Cloud providers are good at what they do. But "mostly fine" isn't the same as "isolated."

What I switched to
I started using Krova Cloud, which gives every workload its own Firecracker microVM called a Cube.

Each Cube boots its own kernel. Its own userspace. Its own private network. No public IP by default.

Spin one up:

Bash

npm i -g @krovacloud/cli

krova cubes create myapp \
  --cpu 2 \
  --ram 4 \
  --disk 40 \
  --image ubuntu-24.04

krova ssh myapp
root@myapp:~#

No shared kernel. No security groups. No public IP.

If you prefer the API:

Bash

curl -X POST https://krova.cloud/api/v1/spaces/$SPACE/cubes \
  -H "X-API-KEY: $KROVA_KEY" \
  -H "Idempotency-Key: $(uuidgen)" \
  -d '{
    "name": "myapp",
    "image": "ubuntu-24.04",
    "resources": { "vcpu": 2, "ramGb": 4, "diskGb": 40 },
    "sshPublicKey": "ssh-ed25519 AAAA...",
    "region": "eu-central"
  }'

What changed
The differences are subtle but real:

No more shared-kernel CVEs keeping me up at night
No more wondering if a noisy neighbor is causing latency spikes
No public IP for bots to scan and brute-force
My workload, my kernel, my rules
I also stopped thinking about firewall rules as the main line of defense. When there's no public IP, the attack surface drops dramatically.

For admin access, I open a port mapping locked to my IP:

Bash

krova ports add myapp \
  --protocol tcp \
  --port 22 \
  --allowed-ips 203.0.113.10/32

Everything else stays unreachable.

What I run on Cubes now
Side project APIs
A Postgres database
CI runners
Anything that processes user-submitted files
Experiments I don't fully trust yet
For each of these, I ask one question: does this need to share a kernel with anyone? If no, a Cube feels right.

For trusted internal microservices, I still use containers. The density and speed are worth the trade. But for anything where isolation matters, I reach for a microVM.

Cost reality
A 2 vCPU / 4 GB RAM / 40 GB disk Cube on Krova runs about $10/month. Comparable to — sometimes cheaper than — a VPS with a public IP.

The hardware isn't the expensive part. The peace of mind is.

The honest catch
Krova doesn't replace AWS, GCP, or Azure for complex multi-service platforms. It doesn't have a hundred managed services. It doesn't pretend to.

What it gives you is a clean, isolated place to run a server. For some workloads, that's exactly enough.

Try it
If you want to see what no-public-IP isolation feels like:

Bash

npm i -g @krovacloud/cli
krova signup
krova cubes create test --cpu 1 --ram 2 --disk 20 --image ubuntu-24.04
krova ssh test

Inside, run:

Bash

ss -tlnp

Nothing public. No shared kernel. Just your own small server in the cloud.

Do you think about who else is running on your host? Or is it one of those things you stopped worrying about? Let me know.