DEV Community: Dhruv malaviya

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.

Cloud Infrastructure Security in 2025: Why I Started Treating Every App Like a Fortress

Dhruv malaviya — Sat, 11 Jul 2026 10:51:57 +0000

A practical look at container escape risks, public-IP scanning, and how Firecracker microVMs on Krova Cloud changed how I think about cloud infrastructure security.

The moment I stopped trusting my own stack
A few months ago, I got that Slack message nobody wants:

"One of our containers is acting weird. High CPU. Unknown process. Can you check?"

It turned out to be a cryptominer. Not because someone hacked our app. Not because we leaked secrets. But because another tenant on the same host had a vulnerable container, and the attacker escaped into the shared kernel.

We didn't do anything wrong. We followed the playbook: updated images, minimal privileges, read-only root filesystems. But we were still sitting on the same kernel as everyone else.

That incident made me ask a question I'd never seriously considered:

What if the real cloud security problem isn't our configuration - it's the architecture underneath?

This post is the answer I found. It's about why I started thinking of every app as its own fortress, and how platforms like Krova Cloud make that practical.

The two lies we tell ourselves about cloud security
Lie #1: "Containers are isolated enough"
Containers isolate processes. They don't isolate kernels.

Every container on a host shares the same Linux kernel. That's by design — it's why containers are fast and lightweight. But it also means a single kernel vulnerability can compromise every container on that machine.

Recent CVEs like Dirty Pipe, CVE-2022-0847, and privilege-escalation chains have shown this repeatedly. You don't need a zero-day. You need one kernel bug and one noisy neighbor.

┌─────────────────────────────────────┐
│ Host Kernel │ ← one shared kernel
├─────────────┬─────────────┬─────────┤
│ Container 1 │ Container 2 │ Your │
│ (tenant) │ (tenant) │ app │
└─────────────┴─────────────┴─────────┘
If an attacker breaks out of any container, they can potentially touch yours.

Lie #2: "A public IP is just how servers work"
The second lie is that every server needs a public IP address.

It doesn't. But VPS providers hand them out by default because it's convenient. The problem? That IP is now on the internet 24/7, being scanned, brute-forced, and probed by bots.

Within minutes of launching a typical VPS, you'll see:

SSH brute-force attempts
Port scans on every service
Automated exploit attempts
Your security model becomes: "I have a public address, and I hope my firewall rules are perfect."

Spoiler: they usually aren't.

What if isolation meant a real kernel?
This is where microVMs come in.

A microVM is a lightweight virtual machine. Unlike a container, each microVM boots its own kernel. Unlike a traditional VM, it starts in milliseconds - fast enough to spin up and tear down like a container.

The technology behind this is Firecracker, the same isolation engine AWS uses for Lambda and Fargate. It's designed for:

Strong isolation (full VM boundary)
Fast startup (sub-second boot)
Low overhead (minimal resource usage)
High density (many VMs on one host)

┌─────────────────────────────────────────────┐
│ Host Hardware │
├─────────────────┬───────────────────────────┤
│ VM 1 │ VM 2 │ Your │
│ own kernel │ own kernel │ app │
└─────────────────┴───────────────┴──────────┘
Each VM has its own kernel. A kernel bug in one can't reach another.

How Krova Cloud turns microVMs into a security model
That's the theory. Krova Cloud is the practice.

Krova Cloud calls its microVMs Cubes. Each Cube is a Firecracker microVM with a few security-first design choices that directly solve the problems I mentioned:

But the part that matters most? It's not just secure , it's usable.

Spinning up a Cube: from zero to root in seconds
Here's what provisioning looks like with the Krova CLI:

Bash

`# Install the CLI
npm i -g @krovacloud/cli

Create a Cube

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

SSH in with full root access

krova ssh web-1
root@web-1:~#`
No VPCs. No security groups. No IAM roles. No launch templates. Just a real VM, isolated by hardware virtualization, booted in under a second.

If you prefer code, the REST API is just as simple:

Bash

curl -X POST https://krova.cloud/api/v1/spaces/$SPACE/cubes \ -H "X-API-KEY: $KROVA_KEY" \ -H "Idempotency-Key: $(uuidgen)" \ -d '{ "name": "web-1", "image": "ubuntu-24.04", "resources": { "vcpu": 2, "ramGb": 4, "diskGb": 40 }, "sshPublicKey": "ssh-ed25519 AAAA...", "region": "eu-central" }'
Same result: one isolated Cube, own kernel, no public IP.

What "no public IP" actually means for security
This is the part that took me a while to fully appreciate.

When a Cube has no public IP, it literally doesn't exist on the public internet. There's no address to scan. No port to probe. No brute-force target.

Inbound traffic only reaches your Cube through Krova Cloud's managed ingress layer:

Web traffic enters through a TLS-terminated edge
Your custom domain points to that edge, not to your Cube
The Cube origin stays hidden
Non-web services use explicit port mappings with IP allowlists
text

Internet → Krova Ingress (TLS, DDoS-mitigated)
↓
Hidden origin
↓
Your Cube (private IP)
Compare that to a standard VPS:

text

Internet → Your public IP
↓
Your server (ssh, db, api all exposed)
The difference is night and day. With no public IP, the attacker can't attack what they can't find.

Mapping Krova's design to real cloud security principles
Let's translate the Cube architecture into the security fundamentals we all know:

Defense in depth A Cube isn't just one layer of isolation. It's several:

Hardware virtualization via KVM
Separate kernel per VM
Jailer sandbox around the hypervisor
No public IP
Stateful default-deny firewall
IP-allowlisted port mappings
Managed TLS ingress
That's defense in depth without you configuring any of it.

Least privilege By default, nothing is reachable. You have to explicitly open a port. And when you do, you can lock it to a specific IP range.

Bash

# Example: open SSH only from your office IP krova ports add web-1 \ --protocol tcp \ --port 22 \ --allowed-ips 203.0.113.0/24
This is least privilege applied to networking.

Attack surface reduction No public IP means no SSH brute-forcing. No open database ports scanned by Shodan. No accidental exposure because someone misconfigured a security group.

The attack surface is reduced by architecture, not by hoping humans never make mistakes.

Isolation of failure If one Cube is compromised, the blast radius is that Cube. Not the host. Not other tenants. Not your entire stack.

When microVMs make sense (and when they don't)
I'm not here to say containers are dead. They're not. But I think we overuse them for workloads that need real isolation.

MicroVMs are a great fit for:
User-submitted code (judge0-style platforms, coding interviews)
AI agents that run arbitrary shell commands
CI/CD runners that should start clean every time
Multi-tenant SaaS where each customer needs isolation
Databases and stateful services that benefit from a real kernel
Anything handling untrusted data
Containers are still fine for:
Internal microservices with trusted code
Development environments
Workloads where density and speed matter more than isolation
Teams already heavily invested in Kubernetes
The key is choosing the right isolation model for the risk.

A cloud security checklist for 2025
Whether you use Krova Cloud, AWS, Azure, or a mix, here's my current checklist:

Markdown

□ Assume shared kernels can be compromised — isolate high-risk workloads
□ Avoid public IPs unless absolutely necessary
□ Use IP allowlists for any administrative access
□ Enable MFA for all cloud consoles and SSH jump hosts
□ Rotate access keys every 90 days (or use temporary credentials)
□ Block public access on all storage buckets by default
□ Scan repos for leaked secrets before every merge
□ Centralize logs and set alerts for root login, IAM changes, and public exposure
□ Test your incident response plan before you need it
□ Review your architecture choices as often as your code
The last one is the hardest — and the most important.

Why this changed how I build
Before the cryptominer incident, I thought cloud security was about configuration: the right IAM policies, the right firewall rules, the right patches.

I still think those matter. But I now believe the foundation matters more.

If your architecture assumes a shared kernel and a public IP, you're asking your configuration to be perfect forever. That's a losing game.

If your architecture gives every workload its own kernel and hides it from the public internet, you've made security the default. That's a much better place to operate from.

That's why I started using Krova Cloud for workloads where isolation matters. Not because it's a magic bullet, but because it aligns the default architecture with good security hygiene.

Try it yourself
If you're curious, you can spin up a Cube for free (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 security-test --cpu 1 --ram 2 --disk 20 --image ubuntu-24.04 krova ssh security-test
Once inside, run ss -tlnp and notice something beautiful: there are no public listening ports. Your server exists, but it's invisible to the internet.

Final thoughts
Cloud infrastructure security isn't just about tools and checklists. It's about architecture.

Containers gave us speed. microVMs give us speed and isolation.

Platforms like Krova Cloud make that isolation practical for everyday developers. And in a world where kernel bugs and automated scanning are constants, I think that's worth paying attention to.

What's your take? Are you still comfortable with shared kernels for sensitive workloads? Or are you already exploring microVMs and Firecracker? Drop a comment — I'd love to hear what's working for you.

Resources
Krova Cloud
Krova Cloud Security
Firecracker microVMs
AWS Lambda under the hood
NIST SP 800-190: Application Container Security Guide

Thanks for reading.
If you found this helpful, hit the ❤️ and follow for more cloud security and infrastructure posts.

5 Cloud Security Mistakes That'll Get You Hacked (And How to Fix Them)

Dhruv malaviya — Wed, 01 Jul 2026 09:14:17 +0000

5 Cloud Security Mistakes That'll Get You Hacked
A friend's startup got breached last month.

Cause? Public S3 bucket with customer data.

Fix time? 5 minutes.

Damage? $50K + lost customer trust.

Don't be that startup. Here are the 5 mistakes I see every week

1. Wildcard IAM Policies ❌
JSON

{ "Action": "*", "Resource": "*" }

Fix — Be specific:

{ "Action": ["s3:GetObject", "s3:PutObject"], "Resource": "arn:aws:s3:::my-bucket/*" }

2. Public Storage Buckets ❌
Fix — Block public access:

Bash

aws s3control put-public-access-block \ --account-id 123456789012 \ --public-access-block-configuration \ "BlockPublicAcls=true,IgnorePublicAcls=true,BlockPublicPolicy=true,RestrictPublicBuckets=true"

3. No Encryption ❌
Fix — Enable default encryption:

hcl

`resource "aws_s3_bucket_server_side_encryption_configuration" "example" {
bucket = aws_s3_bucket.my_bucket.id

rule {
apply_server_side_encryption_by_default {
sse_algorithm = "aws:kms"
}
}
}`

4. Missing MFA ❌
Fix — Enforce via SCP:

JSON

{ "Effect": "Deny", "Action": "*", "Resource": "*", "Condition": { "BoolIfExists": {"aws:MultiFactorAuthPresent": "false"} } }

5. No Monitoring ❌
Fix — Quick security scan:

Bash

`#!/bin/bash
echo "🔍 Checking public S3 buckets..."
aws s3api list-buckets --query 'Buckets[].Name' --output text | while read bucket; do
aws s3api get-public-access-block --bucket $bucket 2>/dev/null || echo "⚠️ $bucket: No public access block!"
done

echo "🔒 Checking open security groups..."
aws ec2 describe-security-groups \
--filters "Name=ip-permission.cidr,Values=0.0.0.0/0" \
--query 'SecurityGroups[].GroupName' --output text

echo "👤 Checking MFA..."
aws iam list-users --query 'Users[].UserName' --output text | while read user; do
aws iam list-mfa-devices --user-name $user --query 'MFADevices' --output text | grep -q . || echo "⚠️ $user: No MFA!"
done`

**Quick Tools
**Bash

pip install prowler prowler aws --checks cis_2.0

*Do This NOW
*

Enable S3 Block Public Access
Turn on default encryption
Enable MFA on root account
Run Prowler scan TL;DR: Least privilege + Encryption + MFA + Monitoring = 95% fewer breaches.

Like this? ❤️ Follow for more quick DevOps tips.

cloudsecurity #aws #devops

4 AWS Infrastructure Gotchas That Will Get Your Account Hacked (And How to Fix Them in Terraform)

Dhruv malaviya — Mon, 29 Jun 2026 13:03:23 +0000

We’ve all heard the horror stories: a developer pushes a quick Terraform module on Friday afternoon, and wakes up Monday to a $14,000 AWS bill because bots turned their staging environment into a Monero mining cluster.

The terrifying part about AWS security isn't sophisticated zero-day exploits—it’s default misconfigurations.

Before you run terraform apply today, audit your code against these 4 bite-sized security fixes:

1. Kill Wildcard (*) IAM Permissions
When you hit a 403 Access Denied error, it’s tempting to test with "Action": "", "Resource": "". If committed, a single app vulnerability lets attackers wipe your AWS account.

The Fix: Always hardcode least-privilege API actions and scope down to exact resource ARNs:
hcl

Action = ["dynamodb:GetItem", "dynamodb:Query"] Resource = "arn:aws:dynamodb:us-east-1:123456789012:table/prod-users"

2. Lock Down S3 Buckets Explicitly
Automated scanners enumerate millions of bucket names per hour. If you don't explicitly block public access, your uploads will be discovered and dumped.

The Fix: Always attach an explicit public access block to every bucket:
hcl

resource "aws_s3_bucket_public_access_block" "lockdown" { bucket = aws_s3_bucket.app_bucket.id block_public_acls = true block_public_policy = true ignore_public_acls = true restrict_public_buckets = true }

3. Never Open DB Ports to 0.0.0.0/0
Opening port 5432 (PostgreSQL) or 3306 (MySQL) to 0.0.0.0/0 so you can connect your local DB GUI invites automated brute-force bots within 10 minutes.

The Fix: Keep databases in private subnets. Only allow ingress from your app server's Security Group ID:
hcl

source_security_group_id = aws_security_group.app_server_sg.id
(Need local GUI access? Use AWS SSM Port Forwarding to tunnel in without open inbound ports).

4. Ditch Static CI/CD Access Keys
Stop generating AWS IAM Users with static .env Secret Access Keys for GitHub Actions deployments.

The Fix: Switch to OpenID Connect (OIDC) federation. Let GitHub Actions assume a temporary AWS IAM Role dynamically per run, generating short-lived tokens that expire immediately after deployment.

🛡️ The 5-Second Pre-Commit Check
Catch these footguns automatically before pushing code by running an open-source scanner in your terminal:

Bash

# Instantly flags open SGs, missing crypto, and wildcards trivy config ./terraform-dir

What is your favorite CLI tool for catching cloud infrastructure bugs? Drop it in the comments! 👇 (Hit 🦄 if this reminded you to check your security groups today).

Why I Switched to Krova.cloud - Better Security, No Overselling, 40% Cheaper

Dhruv malaviya — Thu, 11 Jun 2026 06:44:15 +0000

Hey Devs 👋

Tired of paying premium prices for oversold, shared-kernel cloud infrastructure? Same. Let me introduce you to Krova.cloud — here's why it caught my attention:

🔐 No Shared Kernel Each VM (called a Cube) runs its own isolated kernel via Firecracker microVM technology - same tech behind AWS Lambda. No shared kernel = no cross-tenant risk. Real isolation, not container-level illusions.

🌐 No Public IP Exposure Your Cube doesn't sit naked on the internet.

💾 Backups Done Right

✅ RAID 1 mirrored disks - drive failure won't kill your server
✅ Snapshots built-in - not a paid add-on
✅ Backups stored on separate redundant storage
📊 RAM & Disk - Sold 1:1 Most providers thin-provision their hardware and oversell it. Krova sells every GB of RAM and disk 1:1 with actual hardware. What you pay for is genuinely yours. No noisy neighbors. No surprise slowdowns.

💸 Price? 40%+ cheaper than AWS Lightsail, DigitalOcean & Vultr. Per-hour billing. No hidden fees. Custom-sized VMs - no forced bundles.

Free $5 credits to start - no credit card needed 👉 krova.cloud 🙌

Krova: a security-first “VPS” where your server has no public IP by default

Dhruv malaviya — Thu, 11 Jun 2026 05:19:33 +0000

Most “I got hacked” (or “why is this box getting hammered?”) stories I’ve seen start with the same default: every server gets a public IP.

I’ve been working on Krova — cloud compute that flips that default.

The 4 ideas (quick)
1) No public IP per server by default
A Krova “Cube” (server) lives on a private NAT’d network. There isn’t a public IP sitting out there waiting to get scanned.

2) No shared kernel
Each Cube runs as a Firecracker microVM with its own kernel - not shared-kernel containers.

3) Snapshots + restore/rollback
Built-in snapshots so “snapshot before upgrade → rollback if needed” is a normal workflow.

4) 1:1 RAM + disk (no overselling)
If you provision 4GB RAM + 40GB disk, that’s reserved 1:1 on the host (no thin-provisioning surprises).

What “using it” looks like
1) Create a Cube (pick vCPU/RAM/disk) and SSH in as root.
2) Deploy normally (systemd, Docker, packages -
3) Expose only what you need:

attach api.yourdomain.com → port 8080 (HTTPS)
open SSH (or Postgres) via a TCP mapping, allowlisted to your IP/VPN 4) Snapshot before risky changes. Restore if it breaks.

If you’re curious, the site is here:
https://krova.cloud/

I’d love feedback from folks who run infra:

Is “no public IP by default” a win, or does it break too many real-world workflows?
What would you want to see from snapshots/backups before trusting a newer provider?

Why I built my cloud platform on micro-VMs instead of containers (a security story)

Dhruv malaviya — Wed, 03 Jun 2026 07:55:21 +0000

Containers are great until you remember they all share one kernel. For a lot of workloads that's fine. But the moment you're running untrusted code, multi-tenant jobs, or anything you wouldn't want leaking into its neighbours, a single kernel exploit is the whole game. That worry is exactly why I made an early architecture call for my platform, Krova krova: no shared-kernel containers.

Enter Firecracker
Firecracker is the open-source micro-VM monitor AWS built to run Lambda and Fargate. Each instance is a real hardware-virtualized VM (KVM under the hood) with its own kernel, but it boots in around 125ms and carries almost none of the weight of a traditional VM. You get the isolation boundary of a VM with something close to the start-up feel of a container.

That trade-off is perfect for security-minded, ephemeral work:

Hypervisor-level isolation. Tenants are separated at the virtualization boundary, not by namespaces over a shared kernel.
Tiny attack surface. Firecracker deliberately ships a minimal device model, far less exposed than a full VM stack.

How Krova uses it

Every machine on Krova (a "Cube") is its own Firecracker micro-VM with its own kernel. They get private internal networking rather than a public IP each, ingress is explicit port mapping, and you can sleep or destroy a Cube the instant you're done. So "run something untrusted, then make it vanish" is the default path, not a thing you bolt on.

And because they boot in about a second and keep their disk between sleeps, the security model doesn't cost you convenience, which is usually the part that makes people skip isolation in the first place.