Kubernetes — Lakshmi Narasimhan

Your Cloud Bill Is A Tax On Someone Else's Resume

Lakshmi Narasimhan — Fri, 24 Apr 2026 00:00:00 +0000

There’s an insurance company somewhere — real, working, profitable — with 100,000 monthly users and a peak concurrent load of about 5,000.

They spend high six figures a month on Kubernetes.

They employ twenty people to keep it running.

This story surfaced this week in the Hacker News thread on David Crawshaw’s cloud essay, and the comments section turned into a confessional. Engineer after engineer describing the same pattern: cluster adopted, cluster “optimized,” cloud spend doubled, incidents doubled, and somehow the only thing anyone can agree on is that they need to hire a platform engineer.

You don’t. You never did. Your entire application would run on a laptop.

The incentive nobody likes to say out loud

Here’s the quiet part: your DevOps team does not choose infrastructure based on what your application needs.

They choose it based on what their next job will pay for.

Kubernetes on a resume is worth more than Docker Compose on a resume. Terraform on a resume is worth more than “I SSH’d into the box.” Managed EKS on a resume is worth more than “I run a VM.” Every procurement decision in a modern engineering org is being made by someone who, at some level, is also writing the next page of their LinkedIn.

And management, god bless them, trusts the sales and marketing departments of Datadog and AWS and HashiCorp more than they trust their own engineers. So when someone internally says “we could do this on one server,” and someone externally sends a deck titledScaling Your Platform For The Future, guess which one wins the meeting.

The decision was never technical. You just paid the technical price for it.

Kubernetes is not the villain. The scale is.

Let’s be precise, because “Kubernetes” is doing a lot of work in this essay.

Full enterprise Kubernetes — managed control planes, service meshes, operators for everything, a dedicated platform team, Helm charts nested inside Helm charts like Russian dolls of YAML — that thing was built for Google’s problem. Multi-tenant, multi-region, thousands of services, teams that don’t talk to each other.

If your org does not look like that, you are wearing a costume.

K3s on a single VPS is not the same animal. Docker Compose on a single VPS is not the same animal. Kamal shipping containers to one Debian box is not the same animal. Those are orchestration for people who want one sane way to deploy a container, not a career in platform engineering.

The HN thread is full ofengineers who moved from full K8s to one of these simpler setups. The reports are boringly consistent: costs collapsed, incidents dropped, debugging became possible again. Nobody was shocked. Everyone had been waiting for permission to say it.

The solo founder’s version of this trap

You are not the insurance company. You do not have twenty people. You have you, and maybe a contractor, and a credit card that is getting nervous.

And yet — you will read the AWS Well-Architected Framework. You will follow a tutorial that starts with “first, let’s set up your VPC.” You will pay $80/month for a managed database to store 200 rows. You will provision a load balancer in front of one server. You will copy the shape of infrastructure you saw at your day job, because that shape felt legitimate, and you want to feel legitimate too.

This is how solo founders end up with a$600/month AWS bill for an app that has six users.

The shape of legitimacy is the trap. Nobody cares what your infrastructure looks like until you have customers, and once you have customers,“my app runs on one $12 VPS” is a story peoplelove. It’s the opposite of suspicious. It’s proof that the thing works.

What to actually do

One machine until you can’t. One VPS. One Postgres on that VPS. One reverse proxy. Docker Compose or Kamal to deploy. You are allowed to stop here for years.
Scale vertically first. Hetzner will rent you a 48-core EPYC machine with 256 GB of RAM for €199/month. A mid-tier managed Kubernetes cluster on AWS starts at more than that before you’ve run a single pod. Most apps die from bad unit economics, not from running out of CPU.
When you outgrow that — and you might not —K3s on a few boxes gives you orchestration without the org chart. This is the actual sweet spot for a solo operator who needs more than one machine but less than a platform team.
Treat every infrastructure recommendation as a resume artifact until proven otherwise. Ask who benefits if you adopt this. If the answer is “the person telling me to adopt it,” weigh accordingly.
Your cloud bill is a leading indicator of how much time you are spending on things that do not make your product better. Watch it like you watch your weight.

The cloud was supposed to be leverage. For most people, most of the time, it has become the opposite: a recurring invoice for someone else’s credibility.

You are allowed to just run the server.

]]>

The $30/Year Stack for Launching Small Bets

Lakshmi Narasimhan — Mon, 19 Jan 2026 00:00:00 +0000

Every time I launch a new small bet, I need the same boring stuff: professional email, a chat widget, uptime monitoring. The kind of infrastructure that’s completely unsexy but makes you look like you have your act together.

For years, I overcomplicated this. Custom SMTP servers. Self-hosted monitoring. Elaborate setups that took days to configure and broke whenever I looked at them wrong.

Then I realized something: I was spending more time on infrastructure than on validating whether anyone wanted my product.

So I built a repeatable stack. Total cost: about $30-42 per year, per small bet. Here’s the whole thing.

Domain & Hosting: Cloudflare (Free)

Buy your domain wherever you want, but point the nameservers to Cloudflare immediately.

Cloudflare’s free tier is absurd:

DNS management (fast, reliable)
Free SSL certificates (automatic)
DDoS protection
CDN caching
Cloudflare Pages (unlimited sites, unlimited bandwidth)

That last one is key. Your landing page goes on Cloudflare Pages. Connect your repo, push to main, it deploys. No servers. No bills. No thinking about infrastructure when you should be thinking about whether anyone wants your product.

I run every small bet’s landing page on CF Pages. Zero hosting cost.

Email: Google Workspace (The India Pricing Hack)

You want professional email.hello@yourdomain.com, notyourdomain.help@gmail.com like some kind of digital nomad running a dropshipping scam.

Google Workspace direct pricing: $6/month. Painful when you’re running multiple bets.

Google Workspace through an Indian reseller: Rs.125/month. That’s roughly $1.50.

Same product. Same Gmail experience. Same everything. Just… cheaper, because regional pricing exists and Google apparently forgot to close this loophole.

Recommended resellers: Medha Cloud, Host IT Smart, Shivaami. They’re authorized, they’re legit, and they’ll save you $50+/year per domain.

Setup takes 30 minutes: verify domain, add MX records, configure SPF/DKIM/DMARC so your emails don’t land in spam. Done.

Support: Crisp Chat (Free)

Intercom wants $74/month. For a small bet that might make $0.

Crisp’s free tier gives you:

2 team seats (it’s just you anyway)
Unlimited conversations
Mobile app for notifications
A widget that doesn’t look like it was designed in 2008

Copy-paste their script tag into your landing page. Five minutes.

Upgrade trigger: when you have so many support conversations that you need automation. Which means you have customers. Which means you can afford to pay for things.

Monitoring: BetterStack (Free)

Your app will go down at 3am on a Sunday. This is not a prediction, it’s a guarantee.

BetterStack’s free tier:

10 uptime monitors
1GB logs/month
Email and Slack alerts
3-day log retention

Is 3-day retention enough? For a small bet you’re validating? Yes. You’re not running a bank.

Alternative: Axiom gives you 500GB ingest and 30-day retention if you’re logging more aggressively. Also free.

Error Tracking: Sentry (Free)

Your code will throw exceptions in production that never happened locally. Classic.

Sentry’s free tier:

5K errors/month
10K performance transactions
1 user
90-day retention

For a small bet, 5K errors/month is plenty. If you’re hitting that limit, either your app is broken or you have enough users to pay for it.

Database: Supabase (Free Tier or Self-Hosted)

Every small bet needs a database. Supabase’s free tier is genuinely useful:

500MB database
1GB file storage
50K monthly active users
Unlimited API requests

That’s enough to validate most ideas. The catch: you get 2 free projects total. After that, it’s $25/month per project.

For small bets that graduate to real products, I self-host Supabase on a $6/month Hetzner VPS. Full Postgres, auth, storage, realtime — no project limits, no usage caps. (I’m building a service calledSupabyoi to make this dead simple. More on that soon.)

The Complete Stack

Domain — ~$10-15/year
Cloudflare (DNS + Pages) — Free
Google Workspace (India) — ~1.50/month( 1.50/month( 18/year)
Crisp — Free
BetterStack — Free
Sentry — Free
Supabase — Free

Total: ~1.50/month, 1.50/month, 30-42/year

That’s DNS, hosting, professional email, live chat, uptime monitoring, error tracking, and a database for less than a single month of most “startup” tools.

The Rules

Don’t upgrade until you have paying customers. Free tiers exist for validation. Use them.

Keep the setup identical across bets. Same tools, same patterns, same DNS records. You should be able to launch a new bet’s infrastructure in an afternoon, not a weekend.

Resist the urge to self-host. Yes, youcan run your own mail server. You can also perform your own dental surgery. Neither is advisable.

When To Actually Upgrade

Google Workspace — You need >30GB storage → $7/mo
Crisp — You need chatbots or >2 team members → $25/mo
BetterStack — You’re pushing >1GB logs/month → $24/mo
Sentry — You’re hitting 5K errors/month → $26/mo
Supabase — You need >2 projects or more storage → $25/mo (or self-host)

Notice a pattern? These are all “you have real traction” problems. Good problems to have.

What’s Not Covered (Yet)

This is the skeleton — the basic infrastructure every small bet needs from day one.

I’ll cover these in separate posts:

Tech stack choices (frameworks, languages, deployment)
Payment processing (Stripe, Lemon Squeezy, regional considerations)
CI/CD pipelines (GitHub Actions, deployment automation)
Landing page patterns (what actually converts)

One thing at a time.

The Point

Infrastructure should be invisible. It should cost almost nothing while you’re validating. It should scale up only when you have revenue to pay for it.

$30/year per bet means you can run 10 small bets for less than most people pay for a single Notion subscription.

Stop building infrastructure. Start shipping products.

This is part of my “Deploy” series — simple infrastructure patterns for solo operators who’d rather build products than manage servers.

]]>

I Found a Cryptominer in My Client's Production Cluster. Claude Code Found the Attacker.

Lakshmi Narasimhan — Sat, 03 Jan 2026 00:00:00 +0000

New Year’s Day. Coffee in hand. Ready to ease back into work.

Then I saw the logs.

2026-01-02T06:34:27 GET xmrig-6.24.0-linux-static-x64.tar.gz
2026-01-02T06:34:30 GET http://37.32.6.33:7979/m
2026-01-02T06:34:30 spawn /opt/systemf/m ENOENT

xmrig. In production. Someone was mining Monero on my client’s Kubernetes cluster.

The horror.

The Investigation

I had a few hundred megabytes of JSON logs and approximately zero patience for manually correlating timestamps. So I did what any reasonable person would do: I asked Claude Code to analyze the logs and figure out what triggered the miner download.

Within seconds, it built a timeline:

Time Event

06:34:26. Normal request to /onboarding

06:34:27. xmrig downloaded from GitHub

06:34:30. Secondary payload from sketchy IP

06:34:57. Container OOMKilled

The cryptominer was so resource-hungry it consumed 2GB of memory in 30 seconds and crashed the container. Ironic. The attacker’s greed saved us from a prolonged compromise.

But how did they get in?

Chasing Red Herrings

Claude Code’s first suspect: a low-version npm package calleddevice-unique-keygen. Added by a developer whose email matched the package maintainer. Classic supply chain attack pattern.

I got excited. Maybe too excited.

Claude Code fetched the GitHub repo, analyzed the source code, checked for postinstall scripts, looked for obfuscated code, searched for eval() calls.

Nothing. The package was clean. Just a browser fingerprinting library. Boring. Legitimate.

We moved on.

No malicious init containers. No sidecars. No .ashrc shenanigans. The Dockerfile was clean. The pod spec was clean.

Everything was clean except someone was definitely mining crypto on our infrastructure.

The Actual Answer

Claude Code rannpm audit on the codebase.

critical │ Next.js is vulnerable to RCE in React flight protocol
Package │ next
Patched │ >=15.3.6
Your ver │ 15.3.4
CVSS │ 10.0

CVSS 10. The maximum possible score. The “your house is actively on fire” of security ratings.

The app was running Next.js 15.3.4. A publicly disclosed RCE vulnerability. No authentication required. An attacker could run arbitrary commands on the server by sending a crafted request.

That’s exactly what happened. They sent a request, ran wget twice, downloaded the miner, and started extracting crypto value from compute cycles they weren’t paying for.

The container’s memory limit stopped them. A $20/month Kubernetes resource limit prevented what could have been ongoing theft.

What Claude Code Actually Did

I want to be clear about what happened here. I didn’t single-handedly unravel a sophisticated attack. I didn’t manually correlate log timestamps or reverse-engineer obfuscated npm packages.

I said “check these logs” and Claude Code:

The entire investigation took under an hour. Not because I’m fast. Because Claude Code is.

The Fix

pnpm update next@^15.3.6

One command. That’s the remediation for a CVSS 10.0 vulnerability.

We also orphaned the compromised pods for forensic analysis, rotated secrets, and added proper security contexts to prevent future wget adventures.

The Lesson

Two things saved us:

One thing would have prevented this entirely: runningnpm audit before deployment.

The attacker exploited a vulnerability that was publicly disclosed and patched. We just hadn’t updated yet.

Godspeed with your own dependency updates.

My Medium friends can read this over there as well.

]]>

I spent years on Kubernetes. Now I'm betting against it.

Lakshmi Narasimhan — Thu, 04 Dec 2025 00:00:00 +0000

I’ve spent years in the Kubernetes ecosystem. I wrote about K3s. I ran production clusters. I know my way around kubectl, Helm charts, and the CNCF landscape.

And I’m building a deployment tool that doesn’t use any of it.

Here’s why.

Kubernetes solves problems you don’t have

K8s is incredible engineering. It solves real problems:

Multi-team deployments without stepping on each other
Automatic failover across dozens of nodes
Fine-grained resource allocation at massive scale
Rolling updates for services with thousands of instances

If you’re Spotify, you need this. If you’re running a 50-person engineering org, you need this.

If you’re a solo dev with one FastAPI app and a Celery worker? You don’t.

As one dev put it: “Do you want to build a product, or do you want to build an infrastructure team? Kubernetes makes sense for the latter, but it’s often overkill for the former.”

You need:

git push → app is live
Rollback when you break something
Logs you can actually read
Alerts when the site goes down

That’s it. Everything else is ceremony.

The hidden cost isn’t the cluster

“But K3s is lightweight! You can run it on a $6 VPS!”

True. I’ve done it. Here’s what they don’t tell you:

A solo devrecently posted on r/kubernetes with a title that said it all: “Solo dev tired of K8s churn… What are my options?”

His pain point wasn’t learning Kubernetes. It was the maintenance:

“I don’t mind learning the topics and writing the config, I do mind having to deal with a lot of work out of nowhere just because the underlying tools are beyond my control and requiring breaking updates.”

He’d been burned by Bitnami charts pulling the rug, NGINX ingress breaking changes. Things that worked stopped working — not because he changed anything, but because the ecosystem did.

“It all felt very straightforward, and it worked so well for a bit, but it starts to crumble even when I haven’t changed anything on my side.”

This is the hidden cost. Not the setup — the churn.

The YAML tax: Every change requires editing manifests. Add an env var? YAML. Change a port? YAML. Want a cron job? That’s a whole new CronJob resource. One team had a production outage caused by an improperly indented YAML line. A single space broke prod.

The debugging tax: Something’s wrong. Is it the pod? The service? The ingress? The network policy? The PVC? Hope you remember how to readkubectl describe.

The upgrade tax: K3s made this easier, but you’re still running a distributed system. A 2024 report found over 77% of Kubernetes practitioners still have issues running their clusters — up from 66% in 2022. It’s getting harder, not easier.

The cognitive tax: Part of your brain is always allocated to “how does Kubernetes work” instead of “how do I ship features.”

As one commenter put it: “Choose your churn.” There’s always something.

The Reddit OP’s conclusion? He gave up on K8s entirely. Settled on plain NixOS on a single Hetzner VPS. Accepted that 99.9% uptime from one server is good enough. Skipped the redundancy he thought he needed.

“I am trying to write my software, I just want a reliable thing to host it with the freedom and reliability that one would expect from a system that stays out of your way.”

That’s the real ask. A system that stays out of your way.

For teams, the Kubernetes tax is worth paying. You split it across people, you build expertise, you amortize the cost.

Solo? You pay it all yourself, every time.

What actually works for solo devs

So if not Kubernetes, what?

The same Reddit OP nailed the PaaS problem too:

“These ‘managed-docker’ services charge per container/pod and force the user to over-provision. Your pod doesn’t run on 250mb RAM? Ok pay for 1GB even though you only need 500mb.”

I’ve tried everything:

Heroku (great until the bill hits)
Railway/Render (same story, nicer UX — $50-100/mo for what costs $5 on a VPS)
Dokku (solid, but showing its age)
Coolify (powerful, but now you’re babysitting another server)
K3s (overkill for most solo projects)
Raw Docker + nginx (works but tedious)

The best setup I’ve found:Kamal.

It’s from 37signals. They run Basecamp and HEY on it. It’s just Docker + SSH. No cluster, no orchestrator, no YAML manifests.

kamal deploy

That’s it. It SSHs into your server, pulls your container, does a zero-downtime swap. Rollback is one command. Logs are one command.

It’s boring. It works.

My bet: AI interface > dashboards > CLI > YAML

Here’s where it gets interesting.

Kamal solved the “deploy” problem. But ops is more than deploy:

Why is the app slow right now?
What happened at 3am?
Should I upgrade my VM or optimize my code?
Show me the errors from the last hour

These questions require jumping between tools. SSH into the box, grep the logs, check Grafana, cross-reference with your deploy history.

My bet: you shouldn’t need to do any of that.

You should just ask.

“Why is memory usage spiking?” → Here’s what’s using RAM, and here’s the trend over the last week.

“Roll back to yesterday’s deploy” → Done. Here’s what changed.

“Show me errors from the /api/checkout endpoint” → Found 47 errors, here’s the pattern.

This isn’t science fiction. LLMs are good at this now. The interface just doesn’t exist yet.

What I’m building

VMKit is my attempt at this interface.

Bring your own VPS (Hetzner, DigitalOcean, whatever)
It handles Kamal, Traefik, SSL, monitoring
The interface is conversation — web chat or MCP server in Claude Code

No Kubernetes. No YAML manifests. No 47-screen dashboards.

Just say what you want.

I might be wrong. Maybe solo devs actually love clicking through Render’s UI. Maybe the Kubernetes complexity is worth it for everyone.

But I don’t think so. I think the right answer for one person running one to three apps is radically simpler than what we have today.

vmkit.dev if you want to follow along.

The uncomfortable truth

I’m not anti-Kubernetes. I’m anti-complexity-for-its-own-sake.

K8s is a tool. An incredibly powerful one. But tools have contexts where they make sense and contexts where they don’t.

Solo dev shipping a SaaS? You don’t need pod autoscaling. You need deploys that work and a way to debug when they don’t.

That’s the bet.

]]>

AWS Is Overrated

Lakshmi Narasimhan — Sat, 11 Oct 2025 00:00:00 +0000

If you’re an indie dev building your first SaaS, AWS is not your friend.

It’s a maze of services, dashboards, and acronyms pretending to make you productive while quietly billing you for curiosity.

Sure, it’s “the industry standard.” But here’s the thing: you’re not Netflix. You’re not Stripe. You don’t need fifteen managed services to ship an MVP. You just need one working prototype in front of users.

When I started shipping my own SaaS projects, I defaulted to AWS too. Everyone said it was the “serious” choice. I spun up EC2s, tinkered with VPCs, IAM roles, and CloudWatch dashboards.

Two weeks later, my app still wasn’t live. But my bill was.

That’s when it clicked. AWS is optimized forscale, notspeed. It’s designed for teams with DevOps pipelines, budgets, and compliance officers. Indie devs have none of those.

Here’s the real problem:

AWS makes youfeel productive because it has a service for everything.

But it slows you down because you end upassembling infrastructure instead of shipping software.

You’re busy wiring VPCs while your users are waiting for a login page.

If you’re building your first SaaS, you’re better off with:

Render orFly.io for fast deploys.
Railway,Supabase if you love simplicity.
DigitalOcean app platform
Or even your ownK3s box on a $30 DigitalOcean droplet if you like to tinker.(More on this in future posts)

You’ll have full control, predictable costs, and a deploy story you can explain in a single sentence.

That’s what matters at your stage — not five-nines availability across three regions.

AWS will always have its place. It’s incredible at running serious workloads, regulated systems, and multi-tenant platforms at scale.

But for indie devs trying to launch, learn, and iterate fast — it’soverkill.

Use the simplest stack that lets you ship.

Add complexity only when success forces you to.

Because nothing kills momentum faster than debugging IAM policies instead of building features.

TL;DR

If you’re a solo founder or small team, your advantage isn’t scale — it’s speed.

Don’t trade that away for a cloud that was never built for you.

I share one short post daily-ish for productive indie developers — how to ship faster, cheaper, and saner. Subscribe if that’s your vibe.

]]>