DEV Community: Dhruv Malaviya

My Monitoring Missed the Breach. My Credit Card Caught It.

Dhruv Malaviya — Mon, 14 Sep 2026 06:06:19 +0000

A leaked key spun up instances in a region my dashboards didn't watch; the invoice screamed first. Now I treat spend as a security sensor — per-minute resolution, a prepaid fuse, and a nightly audit on Krova Cloud.

The leak was a CI variable I'd forgotten existed, wired to a cloud API key with far too much confidence. Over one weekend, someone's script used it to spin up instances in a region I'd never deployed to.

My dashboards stayed green — they were watching the resources I knew about. Nobody's monitoring watches a region they forgot exists. The first thing that screamed was my credit card statement, Monday morning, looking like a typo.

Spend is the only metric that can't lie by omission
CPU, latency, error rates — they measure what you chose to point them at. Money aggregates everything, including what you never thought to watch. An attacker can stay quiet to avoid your alerts. They cannot consume resources without touching your bill. Every leaked key, runaway loop and forgotten box has one shared property: it costs money per minute it exists.

The invoice isn't accounting. It's the widest-coverage security sensor you own — and the most ignored. The catch is resolution and caps: a monthly invoice is a smoke detector that mails you a letter after the fire. I needed the signal during the fire, and a ceiling on the fire's size.

The setup on Krova
Three properties make spend usable as a control on Krova Cloud:

Per-minute resolution. Metered by the minute, no rounding up. High-resolution billing = high-resolution signal; a loop shows up within the hour, not at month-end.
A literal fuse. Billing is prepaid credit, and when a space's balance hits zero its Cubes are automatically powered off — no data loss. A leaked key physically cannot spend past the credit I chose in advance. Dollar-capped blast radius.
Hourly cost on every Cube. Each Cube reports its own costPerHour, so the audit is arithmetic, not estimation.

The nightly audit — expected list vs. actual list, plus burn rate:

#!/bin/bash
# spend-audit.sh — reality vs. budget, every night
set -euo pipefail
krova context use prod

# what's actually running, and what it burns
krova list --json | jq -r '.[]
  | select(.state=="running")
  | "\(.name)\t\(.resources.vcpu)vcpu\t$\(.costPerHour)/h"'

# total burn rate vs. plan
krova list --json | jq '[.[]
  | select(.state=="running") | .costPerHour] | add // 0'

0 2 * * *   spend-audit.sh | diff - expected.txt && true || alert "reality ≠ budget"
0 * * * *   burn-rate-check.sh   # alert if hourly spend exceeds plan + 20%

A stranger's box can't hide when the whole estate fits in one jq. And for in-guest anomalies, the complement is event-driven: Krova's webhooks include resource.alert.cpu/memory/disk — spend catches the economic anomaly, those catch the hot process. Tripwire plus camera.

Sizing the fuse
Prepaid means choosing your ceiling on purpose:

Sandbox space gets exactly one experiment's worth of credit. If it melts down, the fuse trips before the surprise does.
Prod gets normal load plus headroom — sized like a breaker: above normal, below pain. Misjudge it and the fuse is also an availability incident, so this is a staffing decision, not a slider.

The honest part

The bill says something is wrong, not what. Sensor first, forensics second: when spend twitches, the running-list and logs find the limb.
Cheap attacks hide under the noise. A patient $0.02/hour adversary sits inside your variance. Spend-catching nails the realistic failures — leaks, loops, zombies — not a careful human. For that you still need walls: no public IP by default, own kernel per Cube, default-deny inbound. The bill is a layer, not the castle.
Ops still yours. The audit tells you a box exists; patching, backups and drills remain your job, same as any self-hosted estate.

The cheapest SOC tool you already own
We file the invoice under "finance" instead of "security," then get surprised by it. Move it. Read it daily, alert on its rate of change, cap what it can reach.

My monitoring is good now. But the sensor I'd least want to lose is the one my accountant installed by accident.

I Gave My AI Assistant the Keys to My Cloud. Here's Why I'm Not Worried.

Dhruv Malaviya — Fri, 11 Sep 2026 11:44:52 +0000

My AI client can provision real servers now — over Krova Cloud's MCP server. The reason I sleep: scoped keys, a sandbox space, unreachable boxes, and a legible bill. Setup, guardrails, and the threat model inside.

I typed a sentence into my AI client: "stand up a 2-CPU box with Docker for the staging API, call it staging-api." It provisioned a real server, verified the boot, and reported back — SSH ready, no public ports exposed. Ten seconds of magic, then the feeling you're supposed to have: what did I just hand an LLM the ability to do?

The answer is the whole point of this post. Spoiler: it's not "trust the model." It's architecture.

The setup
Krova Cloud ships an MCP server, so Claude/Cursor/any MCP client can drive the API in plain English. Config is the standard shape:

{
  "mcpServers": {
    "krova": {
      "command": "npx",
      "args": ["-y", "@krovacloud/mcp"],
      "env": {
        "KROVA_API_KEY": "kro_sandbox_...",
        "KROVA_SPACE_ID": "space_..."
      }
    }
  }
}

Two gotchas the docs call out, both worth knowing before you debug ghosts:

The space ID is the step everyone misses. The key authenticates you but doesn't say which space; without KROVA_SPACE_ID the server starts happily and then every call fails with "No spaceId provided." It's in your dashboard URL.
Verify it's actually connected. Ask it to list your Cubes. Real Cubes with status and hourly cost = connected. A vague essay about what Krova is = the model answering from memory; check the MCP status panel, don't rephrase.

The guardrails (the reason I sleep)

Sandbox space, its own key. Keys are scoped to a single space and carry your permissions there. The assistant lives in a space that holds nothing precious — per the docs' own advice, "use a separate space for anything experimental, so the key cannot reach production Cubes at all." Prod is managed by me, slowly, with my own hands.
Approval prompts stay on. The tool surface includes delete_cube, restore_cube, delete_domain — an agent that can create can also remove. I read what a call will do before allowing it. The prompt is a feature, not friction.
Machines with no address. Every Cube the assistant can create is a Firecracker microVM with no public IP by default — private NAT'd network, default-deny inbound. A rogue box is isolated and unreachable, not a fresh attack surface.
An enumerable, cheap blast radius. One nightly audit answers "what is it running right now?":

krova context use sandbox        # contexts = kubectl-style profiles per space
krova list --json \
  | jq -r '.[] | select(.state=="running") | "\(.name)\t\(.createdAt)"'
# forgotten box? one word:
krova cubes delete staging-api-2

Billing is by the minute, so worst case is a forgotten box costing the price of a coffee — visible in one list, deleted in one word.

The wrong question
We keep asking "can we trust the model?" No. Not fully, not ever. Models misread; prompts inject; docs lie.

The right question: what's the worst thing this key can do? Mine can spin up isolated microVMs with no public address, in a sandbox space, billed by the minute, visible in one sentence. I haven't made the AI careful. I've made carelessness survivable.

The AI doesn't make the infrastructure safe. The infrastructure makes AI access safe.

The honest part

Prompt injection is real. A malicious page my assistant reads could instruct it to provision nonsense or delete things in its space. The layers absorb it: scoped key, sandbox space, approvals, unreachable boxes. Four imperfect layers multiplying into something sleepable.
The key is a credential. It acts as you in that space. Config file, never a repo; one key per machine; revoke the ones you're not using — deletion takes effect immediately.
It won't do ops for you. The assistant provisions; backups, patching and restore drills are still mine. Isolation is the platform's job, operations remain the owner's.

The tool didn't change. The blast radius did.
The same assistant that's terrifying with AdministratorAccess and a production VPS is harmless with a scoped key and disposable, unreachable boxes. Give it a library card, not a master key.

Docker Is Fine. The Host Was the Problem.

Dhruv Malaviya — Mon, 07 Sep 2026 04:07:53 +0000

My containers were renting rooms in a stranger's house — shared kernel, shared VPS. The fix wasn't abandoning Docker: it was running it inside a Firecracker microVM on Krova Cloud with its own kernel. Setup, compose, and honest trade-offs inside.

The moment came during a routine docker ps on the shared "container hosting" VPS where my side projects lived. The list was longer than I expected — other tenants' containers humming next to mine. Then the second thought: they're all running on the same kernel as me.

Containers were never the border. As packaging, Docker is gorgeous — same compose file from laptop to server. The problem was the landlord: my reproducible containers renting rooms in a house full of strangers, sharing the foundation. Namespaces partition the view, not the physics; a kernel bug in the box next to yours is, in the strictest sense, your bug now.

The industry's answer is real but heavy (gVisor, Kata, runtime classes, profile reviews). I didn't need a fleet. I needed a smaller house.

Docker inside a microVM
On Krova Cloud a Cube is a Firecracker microVM — own kernel, no public IP — and images ship with Docker Engine preinstalled, so the stack just moves:

krova images    # shows the slugs; pick the Docker-preinstalled variant

krova cubes create home-1 \
  --image ubuntu-24.04-docker \
  --ssh-key "$(cat ~/.ssh/id_ed25519.pub)" \
  --vcpu 2 --ram 4 --disk 40

The compose file is untouched:

# compose.yaml — identical to my laptop
services:
  web:
    build: ./web
    ports: ["8080:8080"]
    depends_on: [db]
  db:
    image: postgres:16
    volumes: ["pgdata:/var/lib/postgresql/data"]
volumes:
  pgdata:

Ship it and attach the domain (traffic enters via managed TLS ingress — the Cube itself has no public address):

krova ssh home-1 -- 'git clone git@github.com:me/stack.git && cd stack && docker compose up -d'
krova domains add home-1 --domain app.example.com --port 8080

Verify what actually changed

$ krova ssh home-1 -- docker ps --format '{{.Names}}'
stack-web-1
stack-db-1          # the list I expect. nothing else.

$ krova ssh home-1 -- uname -r
6.8.0               # a kernel nobody else is renting

$ krova ssh home-1 -- ip -brief addr
eth0  UP  10.0.x.x/24   # private NAT'd network; no public IP to scan

Three properties did the work:

The sharing didn't disappear — the strangers did. My containers still share a kernel; now it's mine. A neighbor's kernel bug can't reach me because there is no neighbor.
No public IP. Default-deny inbound; only ports I explicitly open are reachable (and those can be IP-allowlisted). I open none.
Boringly cheap. Sized exactly to my stack — 2 vCPU / 4 GB / 40 GB runs about $10/mo, billed by the minute. I kept all of Docker's convenience and moved the one thing that was never Docker's job: the boundary.

The honest part, precisely

Inside the Cube, my containers share my kernel with each other. If one of my containers gets popped, the others are in reach. Acceptable, because they're all mine — the blast radius is my estate, not a stranger's. The boundary moved to the right place, not a perfect place.
Running other people's code? User uploads, plugins, AI agents — that's a different threat and the wrong shape; you want a microVM per workload there, not per host. Different post, different tool.
Operational stuff stays yours. Backups of the named volume, image updates, compose hygiene — a private kernel doesn't do ops for you.

Whose kernel?
"Containers vs VMs" was never the question. It's whose kernel. Packaging and isolation got mashed together for a decade, and we defended the mash-up with config reviews instead of asking that out loud.

Keep the packaging. Change the landlord.

A Customer Asked Who Else Was on Their Server. I Didn't Have a Good Answer.

Dhruv Malaviya — Fri, 04 Sep 2026 16:55:27 +0000

A security questionnaire exposed that my tenants shared a kernel. Now each tenant runs in a dedicated Firecracker microVM on Krova Cloud — here's the signup-time provisioning, the sleep policy, and the honest cost math.

The question came from a customer, buried in a security questionnaire: "Describe the tenant isolation of your production environment."

My honest answer was "we use containers" — which, the more I thought about it, was a description of packaging, not isolation. Every customer's workload shared one kernel. Namespaces drew polite lines; a kernel bug doesn't respect politeness. The threat model that kept me up wasn't strangers on the internet. It was my own tenants, one kernel apart.

Now each tenant's workload runs in its own Cube on Krova Cloud — a Firecracker microVM with its own kernel. Here's the actual setup.

Provisioning at signup

The signup flow shells out to a script. Idempotency key included, so a retried webhook can't create two Cubes for one tenant:

# provision-tenant.sh <tenant-slug>
set -euo pipefail
TENANT="$1"

krova cubes create "tenant-$TENANT" \
  --image ubuntu-24.04 \
  --ssh-key "$(cat ~/.ssh/tenant_deploy.pub)" \
  --vcpu 1 --ram 2 --disk 20 \
  --idempotency-key "signup-$TENANT"

# tenant gets their own subdomain over managed TLS ingress
krova domains add "tenant-$TENANT" \
  --domain "$TENANT.app.example.com" --port 8080

Same thing from the API when the orchestrator does it directly:

curl -X POST https://krova.cloud/api/v1/spaces/$SPACE/cubes \
  -H "X-API-KEY: $KROVA_KEY" \
  -H "Idempotency-Key: signup-$TENANT" \
  -d '{
    "name": "tenant-acme",
    "image": "ubuntu-24.04",
    "resources": { "vcpu": 1, "ramGb": 2, "diskGb": 20 },
    "sshPublicKey": "ssh-ed25519 AAAA..."
  }'

Then verify what the tenant actually got — this is the part I print into the security questionnaire
answer:

$ krova ssh tenant-acme -- ip -brief addr
eth0  UP  10.0.x.x/24        # private NAT'd network. no public address.

$ krova ssh tenant-acme -- ss -tlnp
# only the tenant's own app listens; nothing reachable from the internet

The API agrees: publicIpv4 stays null until you explicitly map a port. Default-deny is the default.

The three properties that matter

Own kernel per tenant. One customer's kernel bug can't reach another customer. Hardware-enforced, not configured-correctly-on-a-good-day.
No overselling. Per the docs, RAM and disk are reserved 1:1 — "your resources" finally means your resources. The noisy neighbor didn't get quieter; he moved out.
No public IP. Tenants' boxes aren't scannable addresses. Traffic enters via managed TLS ingress on their subdomain; only ports I explicitly open are reachable, and I open none.

Keeping the bill survivable
One Cube per tenant is one bill per tenant, so the economics get engineering:

# nightly: tenants inactive 7+ days go to sleep — stopped Cubes bill disk only
krova list --json | jq -r '.[] | select(.state=="running") | .name' \
  | grep '^tenant-' | while read -r cube; do
      is_active "$cube" || krova cubes power-off "$cube"
    done

# tenant logs in next morning → auth layer wakes them:
krova cubes wake tenant-acme   # back in seconds, disk intact

Micro sizes for light tenants, sleep for idle ones, right-size when usage says so. Rough math: 30 tenants on $5–10 Cubes is $150–300/mo — priced into plans as a trust line-item, because that's exactly what it is. Insurance you can quote in a sales call.

The honest part

Isolation is a boundary, not authorization. A wrong WHERE tenant_id = ... in my own app still leaks data between tenants. The microVM stops machines from touching; it doesn't stop my bugs. App-level tenant checks stay and get tested.
You write some orchestration. Provision, sleep, wake, deprovision-on-churn, snapshot before migrations — maybe a hundred lines plus cron. Real cost; still smaller than the cluster I didn't adopt.
Draw the line where the question gets asked. Ten thousand free-tier users don't each get a VM. I started with tenants handling serious data — the ones filling out questionnaires. That's where the risk and the trust live.

Tenancy is billing. Isolation is physics.
"Multi-tenant" drifted into meaning "shares everything." It doesn't have to: bill tenants together, run them apart. When a customer asks who else is on their machine, there's only one answer that ends the conversation happily: nobody.

I Deleted Production at 6 PM on a Friday. Here's Why It Was Fine.

Dhruv Malaviya — Wed, 02 Sep 2026 11:16:41 +0000

A cleanup script, an empty variable, and my side project's files gone at 6:04 PM. The fix wasn't skill — it was blast radius, snapshots, and restore drills on Krova Cloud.

The command was a cleanup script. The variable was empty. The path resolved somewhere it absolutely should not have, and by 6:04 PM my side project's app config and two weeks of uploads were gone.

Friday. Six PM. You know the feeling.

Nobody tells you this when you're getting into infrastructure security: the most dangerous attacker in your threat model has your SSH key, good intentions, and a deadline. It's you.

The old shape made me fragile
Everything lived on one VPS: app, database, cron, the nginx config only God understood. "One machine" means one blast radius — my typo didn't take out a service, it took out the estate. Recovery was a weekend of reconstructing configs from memory like an archaeologist.

I'd spent years defending that box from strangers and got taken out by myself in four seconds.

The new shape: small boxes, snapshot-first
I can't uninstall my own hands, so I moved to small single-purpose Cubes on Krova Cloud — Firecracker microVMs, own kernel each, no public IP — and made every risky change start the same way:

# before the scary thing
krova snapshots create web-1 --name pre-migration
krova snapshots list web-1

# the scary thing goes scary
krova snapshots restore web-1 snap_abc123   # disk rolls back; minutes, not weekends

Restore replaces the Cube's disk with the snapshot. A mistake now eats one small machine with one job; worst case I delete the Cube and redeploy. Note even the delete dialog defaults to "preserve a backup before deleting" — the platform assumes you'll hurt yourself eventually and pads the floor.

Backups that outlive the Cube
Snapshots are a seatbelt, not a vault. For the database Cube I keep Backups — they store the disk and the config (vCPU/RAM/disk/image/region/mappings) and survive deleting the Cube they came from. The workflow that saved my weekend:

Redeploy the Backup into a fresh Cube. The original stays untouched — which makes this perfect for drills and staging copies.
Verify what actually came back, because a green status is not your data:

ssh -p <port> ubuntu@<drill-cube-host>
systemctl is-active myapp          # enabled units come back on their own
curl -s http://127.0.0.1:8080/     # the app answers
ls -la /srv/uploads                # the files are actually there

Tear the drill Cube down when done. One gotcha worth knowing: redeploying alongside a live original gives you a Cube with all the data and none of the domains (mapping conflicts are skipped, not stolen). Exactly right for a drill, exactly wrong if you expected a failover.

The monthly drill
Untested recovery is folklore. Mine runs while everything is calm:

#!/bin/bash
# restore-drill.sh — first Tuesday of the month
set -euo pipefail

# 1. redeploy latest Backup of db-1 into a fresh Cube (dashboard/API)
# 2. verify from outside my normal tooling
ssh -p "$DRILL_PORT" ubuntu@"$DRILL_HOST" '
  systemctl is-active postgresql
  pg_dump app_db | gzip | wc -c    # sane, non-zero size
'
# 3. drill over
krova cubes delete "$DRILL_CUBE"

If the drill ever fails, it fails on a Tuesday, on purpose, with coffee — not at 6 PM on a Friday with adrenaline.

The honest part
Krova's own docs say it plainly, and I love them for it: "Backups are not a backup strategy on their own." Everything above lives on the same platform as the Cube. It covers bad deploys, deleted files, eager deletes — not the platform-shaped hole. So the database also dumps nightly to object storage I control, and the .cube download link (presigned, 15 minutes) gets treated like a credential, because it is one — anyone holding it holds your whole disk.

And small machines don't make you careful. I still typo. The point was never to become perfect. The point was to stop needing to be.

Design for the person with the key
Audit your worst incidents and you'll see the pattern: the expensive ones usually start with a person who had legitimate access and a bad moment. Small blast radii, snapshot-first habits, backups that outlive the machine, drills on a schedule. That's the whole architecture.

You'll deal with that person someday. I know because I've met them. It was me, on a Friday, at 6 PM.

My Server Sleeps at Night. That Turned Out to Be a Security Feature.

Dhruv Malaviya — Tue, 01 Sep 2026 04:03:41 +0000

I gave my side project a sleep schedule on Krova Cloud to save money — power off at 1 AM, wake at 7. The surprise side effect: zero attack surface while asleep. Here's the setup, the cron, and the trade-offs.

At 3 a.m., my production server is off. Not down — off. On purpose.

It started as a money thing. The project has human hours: traffic ~8:00 to midnight, dead until morning. The old VPS ran 24/7 and I paid for eight idle hours every night. Also, 3 a.m. on a VPS is when the botnet zoo shows up — brute-force loops, scanner sweeps, auth-log horror anthologies.

Then it clicked: this project has a sleep schedule. Servers are allowed to have sleep schedules.

The setup
The project now lives on a Cube on Krova Cloud — a Firecracker microVM with its own kernel and no public IP (private NAT'd network, managed TLS ingress, only explicitly opened ports reachable). The sleep schedule is the dumbest automation I own:

# crontab -e — on a host OTHER than web-1 (CI cron / small always-on box)
0 1 * * *   krova cubes power-off web-1   # lights out: compute billing stops, disk preserved
0 7 * * *   krova cubes wake web-1 && sleep 15 && curl -sf https://app.example.com/healthz || curl -sS -X POST "$ALERT_URL" -d 'text=web-1 failed to wake'

Those are real CLI verbs (@krovacloud/cli), not pseudocode. Semantics per the docs:

running → billed per minute for compute + disk
stopped → billed for disk storage only
data survives both directions; wake starts the Cube from its saved disk

So sleeping 8 hours a day removes ~a third of compute time from the bill, and the stopped hours cost pocket change. On my 2 vCPU / 4 GB / 40 GB Cube that's the difference between "hosting" and "rounding error." (krova pricing prints the per-resource hourly rates if you want to do your own math.)

The surprise: the 3 a.m. noise died
First week I checked the logs out of habit. Nothing. No brute force, no scanners. Of course:

no SSH daemon listening
no web server process
nothing in memory, no kernel of mine executing
nothing to scan, because there's no public address anyway

You cannot exploit a process that isn't running. The nighttime attack surface isn't small; it's zero. Awake, the Cube still isn't a scannable box — no public IP, default-deny inbound — so the daytime surface stays tiny too.

Verify the states yourself:

krova get web-1 --json | jq -r .state   # "stopped" at 1:05 AM
krova cubes wake web-1
krova ssh web-1 -- uptime               # back in seconds, disk intact

What sleep forced on my architecture (all good things)

All state on disk. In-memory state dies at 1 a.m., so sessions in Redis-on-disk or DB rows, not globals. Sleep cured my lazy state management.
Boot must be boring. Everything starts via systemd units; if wake + boot doesn't produce a working app with zero human input, that's a bug I fix in daylight.
Health check = first request. I curl the domain after wake in the same cron pipeline; if boot ever fails, I know before users do.

0 7 * * *   krova cubes wake web-1 && sleep 15 && curl -sf https://app.example.com/healthz || curl -sS -X POST "$ALERT_URL" -d 'text=web-1 failed to wake'

Where the schedule lives, and the two ways it dies

A commenter caught that v1 of this post never said where the crontab runs. Outside the Cube, as above — a powered-off host can't wake itself, and the 7 AM alert branch can't fire from inside a stopped Cube. But that creates the mirror failure: if that host dies, the Cube never sleeps, everything looks healthy, and the bill silently goes back to 24/7. So each failure gets a checker that is alive when it fires:

Asleep when it should be awake → the Cube is off, it can't report itself. Only an external check notices (the 7 AM healthz + alert above).
Awake when it should be asleep → the Cube is on, so something inside can talk:

# inside web-1 — this one MAY live on the Cube, it only needs to fire while awake
0 2 * * *   awake-during-sleep-window.sh   # alerts if the Cube finds itself running at 2 AM

Any time — the interval watcher. Both bullets above are point samples; the bill is an interval. A stray wake at 3 AM slips between them and looks healthy by 7. The right observable turned out to be the state log Krova already emits: register a webhook for cube.running / cube.stopped (HMAC-signed, timestamped) and you get every transition:

POST /spaces/$SPACE/webhooks
{ "url": "https://watcher.example.com/krova",
  "events": ["cube.running", "cube.stopped"] }

Alert on any cube.running outside the 7 AM window the second it happens; sum the running→stopped intervals nightly — ~960 compute-minutes expected, more is the alarm. The bill is the ground truth; the samples were approximations.

Three checkers now: two point samples for the cheap obvious failures, one event stream for the interval. And the schedule itself lives outside anything it controls.

Objections, fairly handled

Wake isn't instant. First morning request waits a few seconds for boot. Correct choice for side projects / internal tools / staging with quiet hours. Wrong choice for 24/7 global SaaS — don't sleep those.
Sleep ≠ security while awake. It shrinks the window; it doesn't replace the walls. The daytime Cube still needs its real properties: no public IP, own kernel, explicit ports only. Krova gives you those; sleep is just schedule math on top.
Timezones. If your users are global, your "quiet hours" may not exist. Look at actual traffic before copying my cron.

The reframe

We treat "always on" like a moral quality. For a lot of workloads it's just an expensive, attackable assumption. I added sleep to save money; the quietest security upgrade I've ever shipped was the side effect.

Give it a bed with no address. Let it sleep.

Does anyone else run real workloads on a sleep schedule? Or does powering off "production" at night terrify you? Which camp are you in, and what do your quiet hours look like? Comments open.

A Stranger's Pull Request Almost Stole My Cloud Credentials. So Every CI Job Gets a Fresh microVM Now.

Dhruv Malaviya — Sat, 29 Aug 2026 08:48:58 +0000

My self-hosted CI runner was the least trusted machine I owned. Now every job runs in a disposable Firecracker microVM on Krova Cloud — here's the setup, the scripts, and the trade-offs.

Earlier this year a boring dependency-bump PR came in to one of my open-source projects. One hunk touched the CI config, just slightly. I almost merged it with one eye on the diff.

Then I actually read it: one extra step on every build. And my self-hosted runner — a cheap VPS I'd set up to save CI minutes — ran jobs from forks. It also had cloud credentials sitting in a config file some past version of me had left there "for convenience."

A malicious PR wouldn't have needed to escape anything. It could have curled my environment to a pastebin and the runner would have obliged.

The real lesson wasn't about that PR. It's that a self-hosted runner is a machine that executes strangers' code, and then keeps living. My cheapest machine was my most dangerous one.

Why I didn't just containerize the runner

containers are the standard answer, and they're not nothing. But on a runner they're a screen door where you need a wall:

shared kernel with the host
mounted caches that outlive the job (a poisoned cache hands itself to the next build)
often a Docker socket
a filesystem that persists between builds
I didn't want politeness. I wanted a boundary. So now every CI job gets a fresh Firecracker microVM — own kernel, own rootfs — and the machine dies when the job ends.

The per-job lifecycle

On Krova Cloud each microVM is a Cube. Provisioning is one command and boots in under a second:

npm i -g @krovacloud/cli

krova cubes create ci-job-812 --cpu 2 --ram 4 --disk 40 --image ubuntu-24.04
# ✓ Cube provisioned  ·  booted in 0.9s

The wrapper my pipeline calls per job:

#!/bin/bash
set -euo pipefail

CUBE="ci-job-$BUILD_ID"

# fresh box per job — nothing carries over, ever
krova cubes create "$CUBE" --cpu 2 --ram 4 --disk 40 --image ubuntu-24.04

# secrets injected at runtime as short-lived, scoped tokens.
# never in the image, never on disk after teardown
krova ssh "$CUBE" "DEPLOY_TOKEN=$DEPLOY_TOKEN ./run-build.sh"

# teardown is the security feature
krova cubes delete "$CUBE"

When the orchestrator does it directly (retries included — note the idempotency key so a retried request doesn't double-provision):

curl -X POST https://krova.cloud/api/v1/spaces/$SPACE/cubes \
  -H "X-API-KEY: $KROVA_KEY" \
  -H "Idempotency-Key: $(uuidgen)" \
  -d '{
    "name": "ci-job-812",
    "image": "ubuntu-24.04",
    "resources": { "vcpu": 2, "ramGb": 4, "diskGb": 40 }
  }'

What the runner looks like from inside

This is the part that changed my threat model. The job's machine has no public IP — it lives on a private NAT'd network:

root@ci-job-812:~# ip -brief addr
lo               UNKNOWN        127.0.0.1/8
eth0             UP             10.0.x.x/24   # private. that's it.

root@ci-job-812:~# ss -tlnp
# nothing listening that you didn't start.
# no SSH on the internet, no scannable surface.

Inbound is default-deny; only ports you explicitly open are reachable, and those can be IP-allowlisted. A CI box opens none.

So the three properties that matter:

Nothing persists. No poisoned cache, no leftover cron, no creds on disk for the next build.
The boundary is real. Own kernel per Cube (Firecracker — same tech behind AWS Lambda). A kernel bug popped in a build lands in a box that's seconds from deletion.
No address to attack. The runner isn't a scannable VPS with port 22 on the internet.

Cost: billed by the minute, so a 12-minute job on a 2 vCPU / 4 GB Cube is a few cents. Ephemeral only works when teardown is cheap — that's the whole reason this architecture is affordable.

What this doesn't fix (read this part)

Isolation ≠ safety. If you hand a job a long-lived production credential, a fresh VM just means the credential gets stolen from a brand-new machine. So on top of the VM:

short-lived, scoped tokens per job — injected at runtime, gone at teardown
no shared volumes between jobs
egress restricted where it matters

Krova gives you the blast radius. Secret hygiene is still your job, on any platform. Anyone selling "secure CI" as a checkbox is selling something.

The reframe

That PR moved CI from "infrastructure" to "supply chain" in my head. The code your pipeline runs is code you didn't write; the machine that runs it should be disposable, bounded, and unreachable.

Give every job its own box. Kill the box when it's done.

Has a PR ever targeted your CI instead of your code? And if you run ephemeral runners — microVMs, containers, or bare-metal chaos — what does your teardown look like? Genuinely comparing notes, comments open.

I Gave an AI Agent Root Access. Nothing Broke.

Dhruv Malaviya — Tue, 25 Aug 2026 12:35:43 +0000

How I sandbox LLM agents in disposable Firecracker microVMs on Krova Cloud — no public IP, one-command lifecycle, and why containers weren't a real boundary.

Why containers weren't enough
The standard advice — "run the agent in a Docker container, drop privileges" — fails in one specific way: containers share a kernel. Every container on that host is one kernel bug away from its neighbors. That's exactly why Firecracker exists. AWS built it to run other people's code at scale because namespaces weren't a real boundary.

So the agent gets a microVM. Own kernel, own rootfs, own everything.

The setup
On Krova Cloud each microVM is called a Cube. Whole provisioning is one command:

npm i -g @krovacloud/cli

krova cubes create agent-1 --cpu 2 --ram 4 --disk 40 --image ubuntu-24.04
# ✓ Cube provisioned  ·  booted in 0.9s

krova ssh agent-1
root@agent-1:~#

Two things matter here:

No public IP. The Cube sits on a private NAT'd network. There's no address to scan, no port 22 on the internet, no inbound surface. Check for yourself from inside:

root@agent-1:~# ip -brief addr
lo               UNKNOWN        127.0.0.1/8
eth0             UP             10.0.x.x/24   # private. that's it.

root@agent-1:~# ss -tlnp
# only listeners *you* started — nothing is reachable from outside

Traffic only enters through ports you explicitly open, and those can be IP-allowlisted. For an agent box, I open nothing.

It's disposable. Boots in under a second, billed by the minute. So I stopped treating it as a pet: each agent session gets a fresh Cube, and when the session ends it's deleted. No leftover cron jobs, no stale credentials sitting in a long-lived environment.

The session lifecycle I actually run

set -euo pipefail

CUBE="agent-$(date +%s)"

# fresh box per session
krova cubes create "$CUBE" --cpu 2 --ram 4 --disk 40 --image ubuntu-24.04

# credentials injected at runtime as short-lived env vars,
# never baked into the image
krova ssh "$CUBE"

# session over? nothing to clean up
krova cubes delete "$CUBE"

And when I automate it from CI instead of my laptop, it's the v1 API — idempotency key included so retries don't double-provision:

curl -X POST https://krova.cloud/api/v1/spaces/$SPACE/cubes \
  -H "X-API-KEY: $KROVA_KEY" \
  -H "Idempotency-Key: $(uuidgen)" \
  -d '{
    "name": "agent-session-42",
    "image": "ubuntu-24.04",
    "resources": { "vcpu": 2, "ramGb": 4, "diskGb": 40 }
  }'

A session that lives 20 minutes on a 2 vCPU / 4 GB Cube costs a few cents, minute-billed. Cheaper than the coffee I drink while it runs.

The parts I still don't trust (read this)
Isolation is not the same as safety. Let me be blunt, because this is where people get hurt:

A microVM stops the agent from escaping to your other workloads. It does not stop it from wrecking its own box.
It does not stop it from using credentials you handed it. AdministratorAccess AWS keys + a bulletproof sandbox = a very secure machine making a very expensive mistake.
So the boring controls still apply, on top of the VM:

Scoped, short-lived tokens — injected at runtime, never in the image
No shared volumes with anything you care about
Egress restricted where it matters (the agent doesn't need your whole network)
The VM is the blast radius. Credential scoping is the actual control. Krova gives you the boundary — the hygiene inside it is still your job, same as any self-hosted box.

Anyone telling you "just sandbox it and you're done" is selling something.

The takeaway
I used to think agent safety was a model problem. A big chunk of it is an infrastructure problem you can solve today with 2018-era technology:

Give it a real boundary (own kernel, not namespaces)
Give it no address (no public IP)
Throw it away when you're done
That's the whole trick.

How are you sandboxing agents right now — containers, microVMs, or "vibes and hope"? And has anyone actually measured escape risk on their current setup? Would love to compare notes in the comments.

I Stopped Sharing Servers With Strangers

Dhruv Malaviya — Fri, 21 Aug 2026 16:32:27 +0000

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.

Why I Run My Postgres on a microVM Now

Dhruv Malaviya — Wed, 19 Aug 2026 05:21:55 +0000

A quick note on scope: This post walks through a simple self-hosted Postgres setup on a Krova Cloud Cube — perfect for side projects and small workloads. If you're running production with strict RPO/RTO requirements, skip to the production section. Backups are not optional.

I used to be the person who told everyone to use a managed database.

"Don't self-host Postgres," I'd say. "You're not a DBA. Let AWS handle backups and replication."

Then my managed bill started climbing. And I realized I wasn't using 90% of the features I was paying for. And I started wondering if there was a middle ground between "managed service" and "container on a shared host."

There is. It's called a microVM.

The problem with how we run databases

Databases hold the data you actually care about. Yet we routinely:

Run them on the same server as the app
Leave them in containers on shared kernels
Expose port 5432 to the internet because it's "convenient"
Pay managed service prices for single-node setups that don't need half the features
I've done all of these. Most of us have.

A database doesn't need to be reachable from the internet. It doesn't need to share a kernel with strangers. It needs isolation, stable resources, and a sane backup strategy.

What's a microVM?

A microVM is a tiny virtual machine. It boots its own kernel. It has its own userspace. It's isolated by hardware virtualization, like any real VM.

The difference is speed. Firecracker — the open-source microVM tech from AWS — can boot a VM in under a second. Fast enough that microVMs feel as lightweight as containers, but with real isolation.

container: shared kernel, fast, soft boundary microVM: own kernel, fast, real VM boundary managed DB: someone else's problem, expensive, shared infrastructure

Krova Cloud Cubes
Krova Cloud gives you Firecracker microVMs called Cubes. Each one has its own kernel and no public IP by default.

Creating a database Cube:

npm i -g @krovacloud/cli

krova cubes create db-1 \
  --cpu 2 \
  --ram 4 \
  --disk 80 \
  --image ubuntu-24.04

krova ssh db-1
root@db-1:~#

No VPC. No security groups. No public IP.

If you prefer the API:

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

Installing Postgres
Once you're SSH'd in, it's just a normal Ubuntu server:

Bash

sudo apt update
sudo apt install -y postgresql postgresql-contrib
sudo systemctl enable postgresql
sudo systemctl start postgresql

Create the user and database:

sudo -u postgres psql -c "CREATE USER app WITH PASSWORD 'your-strong-password';"
sudo -u postgres psql -c "CREATE DATABASE app_db OWNER app;"
Edit /etc/postgresql/16/main/postgresql.conf to listen on the private

interface:

conf

listen_addresses = 'localhost,10.0.0.4'

And /etc/postgresql/16/main/pg_hba.conf to allow the app:

host    app_db    app    10.0.0.0/24    scram-sha-256

Restart Postgres:

sudo systemctl restart postgresql

Done. Your database is running on a real VM with its own kernel, on a private network.

Connecting from your app
Your app runs in another Cube. You connect using the database Cube's private IP:

DATABASE_URL = "postgresql://app:your-strong-password@10.0.0.4:5432/app_db"

No public IP. No exposed port. The database only talks to your app.

For admin access, open an IP-allowlisted SSH mapping:

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

Backups
This is where self-hosting gets serious. A managed service gives you backups. A microVM gives you the tools to build your own.

For a small project, a daily pg_dump to encrypted object storage is a starting point:

bash

#!/bin/bash
set -euo pipefail
pg_dump -U postgres app_db | gzip > "/backup/app_db-$(date +%Y%m%d).sql.gz"
# encrypt and upload to your preferred storage

Cost comparison
For 2 vCPU, 4 GB RAM, 80 GB disk:

Managed Postgres->
Approximate monthly cost:$50–200+
Notes:Backups, replication, monitoring included

VPS with public IP->
Approximate monthly cost:$20–50
Notes:Shared kernel, public attack surface

Krova Cloud Cube->
Approximate monthly cost:~$10
Notes:Own kernel, no public IP, per-minute billing

markdown
Prices vary, but the gap is real. Just remember: the Cube is the cheap part. The operational work — backups, patching, monitoring, recovery — is the real cost of self-hosting, regardless of platform.

For a side project or small SaaS, the savings add up. For mission-critical workloads, budget for the operational layer too.

Side project vs. production

The simple setup in this post is perfect for:

Side projects
Small SaaS apps
Learning and experimentation
Workloads where you want full control

For production, you don't need to leave Krova — you need to add operations on top of it. WAL archiving, PITR, automated failover, and mature monitoring can all run on Cubes. Krova handles the isolation and networking. You handle the database operations.

If your team doesn't have the bandwidth for that operational work, a managed service is the right call. That's a staffing decision, not a platform limitation.

The real reason I switched
It wasn't just cost. It was isolation.

I don't want my database sharing a kernel with random workloads. I don't want port 5432 discoverable on the internet. I don't want to rely on a firewall rule I might misconfigure at 2 AM.

A microVM gives me a real boundary. Krova Cloud makes it easy.

Try it
If you want to experiment:

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

Install Postgres, create a database, and notice that nothing is publicly reachable.

Do you self-host Postgres? Use a managed service? I'd love to hear where you draw the line — and why.

Stop Hardening Your Server. Start Hiding It.

Dhruv Malaviya — Wed, 12 Aug 2026 12:39:49 +0000

I used to be proud of my server hardening skills.

SSH keys, fail2ban, UFW, SELinux, read-only root, the whole thing. I could lock down a VPS in twenty minutes and sleep soundly.

Then I checked the auth logs on a fresh server and saw thousands of brute-force attempts in 24 hours. The server had been online for maybe six hours.

I wasn't being targeted. I was just visible.

That's when I started wondering: what if the best security isn't better hardening — it's not being findable in the first place?

The public IP problem
Every VPS gives you a public IPv4 address by default. It's convenient. It's also an invitation.

Bots scan the entire internet constantly. If you have SSH on port 22 and a public IP, you're getting hit. It's not personal. It's automatic.

I had done everything "right":

Key-based SSH only
fail2ban
UFW with minimal ports
Automatic updates
Non-root user
But the attempts never stopped. Because my server had an address.

My app didn't need one. My users hit a domain. My database shouldn't be reachable from outside. Admin access was just for me. The public IP was solving almost nothing while creating a permanent target.

Hiding the server instead
I moved the project to Krova Cloud, which gives you Firecracker microVMs called Cubes. The default: no public IP.

Your Cube sits on a private network. Web traffic comes through managed ingress with automatic HTTPS. SSH is only available through an explicit port mapping locked to your IP.

Creating one:

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 VPC. 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

After 48 hours, I checked the auth logs.

text

`# Before (public VPS)
Failed password for root from 185.x.x.x
Failed password for root from 103.x.x.x
Failed password for root from 45.x.x.x
...thousands more

After (Krova Cube)

nothing`

No brute-forces. No port scans. No 2 AM anxiety about whether I left something exposed.

The server still works. Users still reach the API through the domain. HTTPS still terminates at Krova's ingress. But the machine itself doesn't exist on the public internet.

Admin access without a public IP

If you need SSH, you open a port mapping and lock it to your IP:

Bash

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

Only your IP can reach it. Everyone else sees nothing.

For web traffic, point your domain at Krova's ingress. They handle TLS and hide the origin. Your app doesn't need to know it's not directly exposed.

Bonus: real isolation
Krova Cubes are Firecracker microVMs, so each one boots its own kernel. Not shared with other tenants. Not shared with the host.

For a small side project, that's probably more isolation than necessary. But after reading one too many container escape write-ups, I prefer a real VM boundary for anything I care about.

text

VPS: public IP + shared kernel Container: maybe public IP + definitely shared kernel Cube: no public IP + own kernel

The takeaway
Hardening is good. Hiding is better.

A server without a public address can't be brute-forced. Can't be port-scanned. Can't be accidentally exposed by a bad firewall rule.

We've accepted public IPs as the default because they're familiar. But most apps don't need their machine to be reachable from the whole internet. They need a domain, TLS, and a way for the owner to admin things.

Everything else is attack surface.

Try it
If you're curious, Krova signup doesn't require a card and the first $5 top-up doubles to $10:

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 the Cube, run:

Bash

ss -tlnp
Nothing public. That's the whole point.

Am I wrong about public IPs? Is hardening still the better default? Tell me why , I genuinely want to hear the counterarguments.

Your Side Project Doesn't Need a Public IP. Here's the Proof.

Dhruv Malaviya — Mon, 10 Aug 2026 11:08:53 +0000

I used to think every server needed a public IP. It's just... how servers work, right?

Then I moved my side project , a small Node.js API with a Postgres database , to Krova Cloud. Cubes don't get public IPs by default. Within a day, I realized I'd been accepting a bunch of nonsense I didn't have to.

No more SSH brute-forces. No open ports accidentally exposed. No anxiety about whether my firewall rules were perfect.

Here's what happened.

The problem with public IPs
I ran my project on a cheap VPS for two years. It worked. But one bored afternoon I checked the auth logs:

text

Failed password for root from 185.x.x.x Failed password for root from 103.x.x.x Failed password for root from 45.x.x.x
Thousands of attempts per day. From everywhere.

I had key-based SSH. I had fail2ban. I had UFW. But the attempts never stopped because my server's address was public. That's the whole job of a public IP — be findable.

The thing is, my app didn't need to be findable. My domain was. My users hit the API through the domain. The server itself just needed to exist.

Krova Cloud: a server without a public address
Krova Cloud gives you Firecracker microVMs called Cubes. Each Cube has:

Its own kernel
No public IP
A private network
Managed ingress for web traffic
IP-allowlisted port mappings for admin access
Creating one looks like this:

Bash

`npm i -g @krovacloud/cli

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

krova ssh fileapi
root@fileapi:~#`
That's the whole setup. No VPC. No security groups. No public IP.

If you prefer APIs:

Bash

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

Node.js API running on port 3000
Postgres on the same machine
Nginx as a reverse proxy with HTTPS
On Krova, I kept the same setup but pointed my domain at Krova's managed ingress instead of a public IP. HTTPS was handled automatically. The origin stayed hidden.

For SSH, I opened a port mapping locked to my home IP:

Bash

krova ports add fileapi \ --protocol tcp \ --port 22 \ --allowed-ips 203.0.113.10/32
Only I can reach SSH. Everyone else sees the domain and the API. The server itself is invisible.

The result
After 48 hours, I checked the auth logs.

Zero SSH attempts.

Not "reduced." Not "better." Zero. Because there's no address to attack.

My API response times were the same. My users didn't notice anything. My deploy process barely changed. But the background noise of the internet trying to break in just... stopped.

What about isolation?
I mentioned Cubes are Firecracker microVMs. That means each one boots its own kernel.

For a tiny side project, that's probably overkill. But honestly? I like overkill when it comes to isolation. I've read enough container escape write-ups to prefer a real VM boundary for anything I care about.

text

VPS: public IP + shared kernel with other tenants Container: maybe public IP + definitely shared kernel Krova Cube: no public IP + own kernel
For me, that's an easy trade.

Is this for every project?
No.

If you're building a complex multi-region microservices platform, use AWS or GCP. Krova is simpler, which means it does less.

But for side projects, small SaaS apps, CI runners, databases, or anything where "give me an isolated server" is enough, this is the cleanest setup I've found.

Try it yourself
If you're curious, signup doesn't need a card and the first $5 top-up doubles to $10:

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
Once inside, run:

Bash

ss -tlnp
Nothing is listening publicly. That's the whole point.

The lesson
We accept public IPs as the default because they're familiar. But most apps don't need their server to be addressable from the entire internet. They need a domain, TLS, and a way for the owner to admin things.

Deleting the public IP didn't just reduce my attack surface. It removed the background anxiety that came with it.

Have you run anything without a public IP? Did it feel wrong at first, or immediately better? Drop a comment — I'd love to hear.