DEV Community: Dhruv Malaviya

It's October. Strangers Are Sending You Code. Here's How I Say Yes.

Dhruv Malaviya — Mon, 05 Oct 2026 12:02:00 +0000

October routes thousands of first-timers to your repo. The review order that keeps CI safe (pipeline first, deps second), grep for the three exfil shapes, fork-PR secret hygiene, per-job disposable runners, and how to reject a PR kindly

First PR of the season arrived October 2nd: account three days old, title fix typo, diff mostly a typo. Mostly.

October is the month strangers send you code, and if you maintain anything with a .git directory, your queue is about to have neighbors. Beautiful — and, if you're not careful, the month your CI meets someone's cousin's script. I've been the maintainer who flinched at a malicious hunk and the first-timer whose tiny PR got reviewed with kindness. Both wrote this post. The goal isn't keeping strangers out; it's keeping the door open without leaving it unlocked.

Review order: pipeline, deps, then everything

# 1. anything that EXECUTES — a typo PR that edits workflows is not a typo PR
git diff main...HEAD --stat -- '.github/' 'Makefile' '*.mk' 'Dockerfile' '*compose*.y*ml'

# 2. dependency deltas — typosquats live here dressed as helpfulness
git diff main...HEAD -- '*requirements*.txt' 'package.json' 'go.mod' 'Cargo.toml'
#    three questions per new package: who maintains it, how old is it, why this one

# 3. then everything else, at the depth its blast radius deserves

The three exfil shapes (grep them)
Most malicious October diffs aren't clever — same three shapes, different variable names:

git diff main...HEAD | grep -nE \
  'process\.env|os\.environ|getenv|/proc/self/environ'   # environment going somewhere
git diff main...HEAD | grep -nE \
  'base64|eval\(|atob|xxd -r'                            # obfuscation in an unobfuscated repo
git diff main...HEAD | grep -nE \
  'curl .*(-d|--data|-F)|wget |requests\.post|fetch\('   # new outbound calls

The real tell is scope creep: the mismatch between the title's promise and the diff's appetite. A fix-typo that adds a network call, a cron, or a download gets the hard look. Paranoia is vague and exhausts you; a checklist is cheap.

The safe room: fork PRs and disposable runners

Fork PRs never see secrets. Keep the platform defaults that make this true (approval required before a fork first-timer's workflow runs; no secret exposure to forks). A stranger's first PR should execute in a room with nothing valuable in it.
Every job gets a throwaway box. My CI runs each job in a fresh microVM — on Krova Cloud a job spins a Cube with its own kernel and no public IP, then dies:

CUBE="ci-job-$PR_NUMBER-$RUN_ID"
krova cubes create "$CUBE" --cpu 2 --ram 4 --disk 40 --image ubuntu-24.04
# run the PR's tests inside; fork PRs mount zero secrets
krova cubes delete "$CUBE"     # teardown is the security feature

A poisoned cache from a malicious build can't greet the next build, because there is no next build on the same machine. When the room is safe, review relaxes from interrogation to conversation.

Be kind on purpose (with receipts)
The three-day-old account is someone's first week in this community. The checklist handles the threat; your words handle the human:

Thanks for this! The typo fix is perfect — merging. 🎉
One note: the workflow change isn't needed for the typo, so I've
split it into its own PR where it can get a proper review.
Welcome aboard — really glad your first one landed here.

Say thanks in every review including rejects. Explain a "no" in two sentences; a silent close teaches nobody. Never talk to a first-timer like a threat actor.

The honest part
You cannot deep-review a flood. Tier it: CI/deps/scripts get the full checklist; docs and typos get a fast, grateful yes. The tiering is the practice.
Automation flags shapes; humans read intent. A perfect auto-merge tool is just a faster door.
The safe room doesn't replace review. Isolation limits what a bad PR can do; only reading limits what a bad PR can become.

Keep the door open
October's queue is a gift pile. Some gifts are typos, some are gems, one might be wired. Open all of them — just open the wired one with the right room behind you.

My Smart Bulb Shares a Network With My Production Keys.

Dhruv Malaviya — Sat, 03 Oct 2026 08:10:56 +0000

Nineteen devices on one flat home LAN: my work laptop with prod access, a 2021-firmware bulb, a camera from a dead brand, and an ESP_4F2A nobody admits to buying. The fix: split the network, promote the router to perimeter, and treat home like a café — tunnels, scoped contexts, no standing creds.

I opened my router's device list like you open a fridge at midnight — without a plan, slightly guilty. Nineteen devices. My work laptop, which can reach production, was on the same flat home network as a $12 smart bulb with 2021 firmware, a camera from a brand whose website no longer exists, a TV phoning home to an unplaceable timezone, and something labeled ESP_4F2A nobody in my household admits to buying.

A home LAN is flat: everything trusts everything. The security of the machine holding my prod keys was, that evening, partially defined by a light bulb I bought on sale.

The living-room test
The café test for laptops has a home version: if the cheapest device on your network gets popped, what's the path from there to the thing you'd cry about? On a flat LAN the answer is usually "a scan, then a try." Not because the bulb is an evil mastermind — because flat networks turn one weak device into a viewing position over everything else.

First, see the whole estate:

# who actually lives on your LAN (router DHCP list is the honest source; this cross-checks)
nmap -sn 192.168.1.0/24 | grep -E 'Nmap scan report|MAC'

The split (free, boring, an afternoon)

work vlan  : laptop, work phone        → reaches SSH endpoints, nothing else inbound
iot vlan   : bulb, camera, TV, ESP_*   → internet only; sandbox where blast radius = each other
guest wlan : visitors                  → internet only, timed
# exceptions are deliberate, visible, few:
#   laptop → printer (print only)
#   phone  → doorbell app

Router settings, zero dollars. The bulb keeps bulbing; it just loses its view of my laptop. Then the router itself got promoted to perimeter: admin password off the sticker, auto-update on, remote management off. It's the only device in the house actually doing security — it deserved the ceremony.

Home is a café now
The laptop rules travel home: no standing production credentials, short-lived sessions, and services reached by tunnel — nothing listens publicly just because I'm on the couch:

#!/bin/bash
# home-is-a-cafe.sh
krova context use home          # scoped: create/wake/ssh ok; delete prod = no

krova ssh db-1  -L 5432:localhost:5432 &   # postgres over the encrypted channel
krova ssh web-1 -L 8080:localhost:8080 &   # app same; internet gets nothing

# local clients now hit localhost; the databases never "listened for me"
psql -h localhost -p 5432 -U app app_db

A popped bulb's "scan, then try" now finds localhost ports bound to encrypted tunnels it can't join, and a context whose worst day is a forgotten dev box — visible in one list, deleted in one word.

The honest part

Segmentation is messy in real life. The printer needs the laptop; the doorbell wants the phone; convenience files weekly complaints. The goal isn't a perfect diagram — it's that the default path from popped bulb to prod keys is gone, and exceptions are deliberate.
You can't audit a household. Kids' tablets, a partner's phone, the in-laws visiting Wi-Fi. The split is the admission that you'll never control every device — so control what they can see instead.
Home hygiene doesn't fix the castle. The walls still live server-side: no public IP by default, own kernel per Cube, default-deny inbound, scoped secrets. Segmentation shrinks the path to those walls; it doesn't replace them.

Go look at your device list
Not tomorrow. Now. Count the devices, find the oldest firmware, and ask the only question that matters: does that device share a network with the keys?

Mine did — neighbors for two years, and the bulb had the worse posture. The fix cost an afternoon and a new SSID name. Best security review I've done all year, and the arithmetic was free.

I Did Recon on My Own Company , Using Only What We Published.

Dhruv Malaviya — Wed, 30 Sep 2026 12:01:37 +0000

Twenty minutes of public-only recon on my own company: the README architecture diagram, job postings as a vendor list, an error-message hostname, .env.example as a secrets schema. The fix: split the manual from the map, scrub errors at the boundary, review jobs like publications.

Quarterly habit: twenty minutes attacking myself with public information only. No credentials, no insider knowledge. This quarter I pointed it at the asset I'd never audited because I never thought of it as one: our documentation.

The notebook I ended up with made me slightly nauseous.

What the public pile gave away

README architecture diagram — service names, queue names, the worker fleet. A map with a legend, updated last quarter.
A support-thread screenshot — an error toast containing an internal hostname and stack path. Errors are involuntary documentation.
Job postings — "must know Kafka, Datadog, Auth0, Terraform" is a vendor list with a budget attached, including which parts we're unhappy enough to replace.
A 2023 conference talk, still indexed, "simplified" diagram 90% accurate.
.env.example — variable names are a schema of your secrets; ours enumerated every third-party integration, alphabetically, with comments.

None of it was a breach. All of it was publishing. Recon is the cheapest phase of an attack, and we were subsidizing it.

Run your own twenty minutes (the sweep)

# 1. involuntary docs: hostnames, internal ranges, vendor names in the repo
grep -rniE '(\.internal|\.local|10\.0\.|192\.168\.|hostname|stack)' docs/ README.md | head -30

# 2. the secrets schema
cat .env.example          # read it like an attacker: that's an inventory

# 3. your jobs page is a publication
grep -iE 'kafka|datadog|auth0|pagerduty|terraform' jobs/*.md

# 4. then do the human part:
#    - search "yourproduct architecture"
#    - site:yourdomain.com diagram
#    - open your last three conference/blog artifacts

The manual vs. the map
Docs have two audiences by default, and only one is friendly; the document can't tell them apart. So we split:

docs-public/    # the MANUAL — behavior, interfaces, examples. Generous.
docs-internal/  # the MAP — topology, internal names, runbooks, vendor wiring.
                # Access-controlled, reviewed like code.

And the habits that cut involuntary leaks:

Errors get scrubbed at the boundary — what happened, never where:

app.use((err, req, res, next) => {
  const id = crypto.randomUUID();
  log.error({ id, err });                    // hostnames + stacks stay in logs
  res.status(err.status || 500).json({
    error: "Something went wrong.",          // no internal names in the toast
    ref: id
  });
});

.env.example documents shape, not inventory:

- # Stripe live key for payments team
- STRIPE_KEY=sk_live_...
- KAFKA_BROKERS=kafka-3.internal:9092
+ PAYMENTS_KEY=        # your payments provider key (scoped, rotated)
+ EVENT_BROKER=        # event pipeline endpoint

Job postings reviewed like publications:

- Own our Kafka + Datadog + Auth0 stack.
+ Own high-throughput event pipelines, observability, and auth integrations.

Candidates understand the second version perfectly. So does the person drafting your attack plan — except they learn less from it.

The honest part

Not security by obscurity. The walls stay walls: no public IP by default, own kernel per Cube, default-deny inbound, scoped secrets. Doc discipline just stops handing out the floor plan of the building the walls protect.
Open source moves the line, not the principle. If your topology is the repo, the discipline shifts to what isn't: your environments, vendors, operational wiring. Publish the software's manual; your instance's manual is yours.
Total erasure is impossible. Mirrored slides live forever. The goal is that today's publishing is deliberate, and the freshest intel an attacker gets is stale.

Run your own twenty minutes
Search your product name plus "architecture." Read your last three job postings like a stranger with a grudge. Open the .env.example. Screenshot one customer-facing error.

Then ask, for each artifact: who needs this to use us — and who else just learned something?

Staging Went Down Last Month. Our Customers Tweeted About It.

Dhruv Malaviya — Sat, 26 Sep 2026 16:27:17 +0000

Our 'staging' environment had real tenants via a forgotten DNS door, a two-year-old prod dump, and debug shortcuts — because environments are labeled by intention, not contents. The fix: classify by data, and make staging ephemeral with nightly rebirth on Krova Cloud.

One guard, courtesy of a commenter: the rebirth has a supply chain. The scrub and seed scripts are built against a schema, and migrations move the schema under them. If they live in a wiki or a separate repo, a migration silently breaks the nightly rebirth and nobody notices until the next demo. So they're versioned right next to the schema migrations — same repo, same PR — and the rebirth ends with a smoke test (healthz plus a sane row count) that alerts on failure. Cleanup became a property of the system; this keeps the system honest about its own breakage.

The alert said staging was unreachable. My first thought was who cares. The second, four seconds later: then why are customers tweeting that they can't log in?

The investigation found staging had been serving real users for months — a forgotten DNS record, a redirect from an old marketing page, customers onboarded during a demo and never moved. Staging hadn't "become production." It had become production for some people, which is the same thing with worse defaults.

What the audit found

A prod dump, copied "just once" two years ago. Real names, real emails, real rows. A copy of production data is production-shaped, whatever the hostname says.
Relaxed rules everyone knew about. Debug endpoints. An admin panel behind a path instead of a password. A test account whose password lives in an offsite whiteboard photo. In prod these are incidents; in staging they were convenience — right up until real people lived there.
No backups, no alerts, no drills. Nobody backs up a costume. Then the costume had tenants.

The rule we now enforce in every planning meeting: production isn't a name. It's wherever your users' data lives.

Classify by data, not hostname
Anything holding real user data gets production care — backups, alerts, auth, patching — even if it's called staging, demo, or bob-box. Real data enters scrubbed or not at all; the "one quick dump" is banned.

And staging itself is now ephemeral by design: it dies and is reborn nightly, scrubbed on boot, deleted every Friday. An environment that dies weekly cannot accumulate secrets, drift, tenants, or folklore.

#!/bin/bash
# staging-reborn.sh — nightly
set -euo pipefail

krova cubes delete staging        # old staging dies completely

krova cubes create staging \
  --image ubuntu-24.04 \
  --ssh-key "$(cat ~/.ssh/deploy.pub)" \
  --vcpu 2 --ram 4 --disk 40 \
  --user-data "$(cat scrub-cloud-init.yml)"

#cloud-config
# scrub-cloud-init.yml — staging is reborn clean every night
runcmd:
  - curl -sf -H "Authorization: Bearer ${DUMP_TOKEN}"
      https://storage.private/scrubbed-dump.sql.gz
      | gunzip | sudo -u postgres psql app
  - systemctl restart app

On Krova Cloud this lifecycle is affordable because it's billed by the minute, and a stopped Cube bills only its disk — Friday's delete is the default state, not an event.

The doors that make environments lie
Orphaned DNS is how staging acquires tenants. The weekly check:

while read -r d; do
  t=$(dig +short "$d" CNAME | head -1)
  # any record still pointing at staging is a door
  [ -n "$t" ] && case "$t" in *staging*) echo "DOOR: $d -> $t";; esac
done < domains.txt

Plus the classification check — ask staging what it's holding, not what it's named:

krova ssh staging -- sudo -u postgres psql app -tAc \
  "SELECT count(*) FROM users WHERE email NOT LIKE '%@example.com';"
# any number above zero means staging is lying to you

krova ssh staging -- ss -tlnp
# debug ports listening? that's a prod-shaped wound on a staging-shaped box

The honest part

Synthetic data has a realism tax. Some bugs only bite real-shaped data — the 400-character name, the emoji in the address line. We use a smaller, weirder synthetic set plus occasional scrubbed real samples, reviewed like code. Perfection isn't on the menu; classification is.
Small teams can't afford full parity. Fine. The rule isn't "staging must equal production." It's "nothing real lives in a place with pretend rules." One sentence, enforceable at any size.
Ephemeral staging doesn't fix prod. Prod still needs real walls: no public IP by default, own kernel per Cube, scoped secrets. This post is about misclassification, not about replacing the castle.

Environments lie. Data doesn't.
Go ask your staging what it's holding — not the hostname, the contents. If the answer includes real names, real emails, or one customer who wanders in through a forgotten door, you don't have a staging environment. You have an unmonitored production wearing a costume.

Ours wore it for months. The customers never noticed. That's not a compliment. That's the scariest part.

I Audited My Dead Side Projects. Some Weren't Dead.

Dhruv Malaviya — Mon, 21 Sep 2026 13:06:00 +0000

Forty minutes of list-making found a VPS still running after two years, a dangling CNAME ripe for subdomain takeover, and a valid API key on a machine I'd mentally buried. The audit scripts, the decommission runbook, and the sleep-instead-of-rot policy.

Last Saturday I listed every project I'd ever deployed — side projects, hackathon demos, "quick tests." Forty minutes to write; reading it back took my breath away. Because dead projects don't die. They wait.

What the graveyard was hiding

Three projects I'd euthanized were still running — a VPS humming for two years with dependencies from the floats era. Forgotten app = dependency museum = vulnerability list.
A cancelled domain still CNAME'd to a service I no longer owned. The record dangled like an unplugged phone line; anyone claiming the orphaned resource receives traffic meant for me. Subdomain takeover, living exactly where nobody looks.
A .env on the old box with a key that was still valid. Two years of "I'll clean that up someday," one working key to my current life.

None of these were hacks. All of them were mine. The scariest attack surface I own isn't production — it's the graveyard.

The audit, automated where possible
Schools teach shipping. Nobody teaches burying. So here's the part of my audit that runs as a script:

#!/bin/bash
# graveyard-audit.sh — dangling DNS + estate inventory
set -euo pipefail

# 1. dangling CNAMEs: target no longer resolves = claimable by strangers
while read -r d; do
  t=$(dig +short "$d" CNAME | head -1)
  [ -n "$t" ] && [ -z "$(dig +short "$t" A)" ] \
    && echo "DANGLING: $d -> $t"
done < domains.txt

# 2. what's actually running, by state
krova list --json | jq -r '.[] | "\(.name)\t\(.state)"'

# 3. secret archaeology in old project dirs — then revoke every hit
grep -rEho '(kro|ghp|aws|sk)_[A-Za-z0-9_-]{8,}' old-projects/ | sort -u

The human part stays human: every CI variable, every service account, every "temporary" panel. The script catches the dangling and the running; you catch the remembered.

The decommission runbook (order matters)
A project isn't dead when the app is down. It's dead when nothing anywhere points at it or opens it:

# memory first, then the box
krova snapshots create oldproj --name burial
krova cubes delete oldproj          # delete dialog preserves a backup by default

# THEN, in the same sitting — this is the part everyone skips:
#  - delete the DNS records (A, CNAME, _acme-challenge, TXT)
#  - revoke the keys it held
#  - remove CI/CD variables and webhooks
#  - cancel service accounts / OAuth apps

Delete the box first and the DNS later, and "later" is where the graveyard grows. One sitting, full kill.

Sleep instead of rot

For the "someday maybe" tier, the respectful middle state: hibernation. On Krova Cloud a powered-off Cube bills only its disk — no running process, no open port, no public IP to begin with:

krova cubes power-off maybe-someday   # pennies/month, zero exposure
krova cubes wake maybe-someday        # revive in seconds when nostalgia strikes

Sleep is what keeps the graveyard from refilling: a project is either alive, asleep, or buried. Rotting is no longer a state I allow.

The honest part

A list isn't a fix. The audit produced a document; the boring weekend of deleting records and revoking keys produced the safety.
You can't audit what you never wrote down. New projects get a row the day they're born — domain, keys, and their planned death: who revokes what.
The graveyard isn't the castle. The living stack still needs real walls: no public IP by default, own kernel per Cube, scoped short-lived secrets. The audit shrinks the estate attackers can explore; it doesn't replace defending what's alive.

Dead projects don't die. They wait.
Every reader has a graveyard. Some of yours are glowing right now — a box you forgot, a record you orphaned, a key that outlived its project. The audit is forty minutes; the fixes are one boring weekend.

I Deleted My Entire Security Stack. My Apps Got Safer.

Dhruv Malaviya — Wed, 16 Sep 2026 19:01:13 +0000

fail2ban, the ufw ruleset, the WAF, the log-watchers — all purged in a month, and my apps got safer, because every one of them was a compensating control for a single inherited default: a public IP. The purge checklist, the before/after, and what I kept.

Uninstalling fail2ban felt like removing a smoke detector. My finger hovered for a genuine minute. Then I pressed enter, and over the next month almost everything went: the ufw ruleset I'd maintained for years, the WAF config, auditd's screaming cron, the nightly "security" scripts whose output I'd stopped reading in 2024.

My apps got safer. That sentence is the opposite of what it sounds like, so let me show the work.

The compensating question

Before the purge I asked what each tool was actually compensating for:

fail2ban → SSH reachable from the entire internet
ufw ruleset → a public address with ports that must be filtered
WAF → the app directly reachable by anything that finds its IP
log-watchers → the noise generated by all of the above

Different tools, one root cause: the machine has a public address — a decision I never made, just inherited, because "server comes with an IP" is how servers work. I wasn't running a security stack. I was running a payment plan on a bad default.

Changing the default
The workloads moved to Cubes on Krova Cloud — Firecracker microVMs, own kernel each, and the part that retired the stack: no public IP. Private NAT'd network, traffic through managed TLS ingress, default-deny inbound, only explicitly opened ports reachable. I open none.

Before/after, same eyes:

# BEFORE — old VPS, the street:
$ ss -tlnp
LISTEN 0.0.0.0:22      # the brute-force magnet
LISTEN 0.0.0.0:80
LISTEN 0.0.0.0:443

# AFTER — Cube, from inside:
$ krova ssh app-1 -- ip -brief addr
eth0  UP  10.0.x.x/24          # private. that's the whole list.

$ krova ssh app-1 -- ss -tlnp
LISTEN 127.0.0.1:8080          # the app, listening to itself

$ krova tcp list app-1
# empty. no port forwards, nothing to filter, nothing to ban.

With no address there's nothing to brute-force, so fail2ban has no job. With default-deny and no surface, the ruleset has no job. One migration weekend retired four tools and ~1,000 lines of compensating config.

The purge checklist (and why it's safe)

apt purge fail2ban          # no public SSH → nothing to ban
ufw disable                 # retired, NOT "off and exposed" —
                            # safe only because the platform default
                            # is private + default-deny inbound
# WAF config → archived; app-level validation stays in the app
crontab -e                  # delete auditd + nightly scanner lines

Read that ufw disable line carefully. It is safe because the exposure left first. On a box with a public IP, the same command is a breach with extra steps. Order matters: default first, meds second.

What I did NOT delete

Secrets hygiene — scoped, short-lived, injected at runtime.
Backups + restore drills — off-host copies, scheduled restores into a fresh Cube.
Patching & dependency cadence — the boring rhythm continues.
Application security — authn/authz, input validation, tenant checks. The purge hit tools defending the door; the app's own locks were never the target.

The honest part

Keep your tools if your symptom is mandatory. Gameservers, UDP media, weird protocols — real public-address workloads exist. This isn't "firewalls are a scam"; it's "ask whether the symptom is optional." For a shocking number of web workloads, it is.
Architecture isn't a sedative. No public IP shrinks the surface; it doesn't review your PRs. The threat model got smaller, not zero.
Ops stay yours. Isolation is the platform's job; patching, backups, drills remain the owner's, same as any self-hosted box.

I didn't remove the locks. I removed the street.
Most of my "security" was pain management for a street I never needed. When the street went away, the pharmacy closed.

Ask your stack the compensating question tonight. You might find a default you inherited, a wound you've been medicating for years — and a weekend where the meds go away.

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.