DEV Community: Bhargav Bhatt

The Protocol That Connects Your AI to Everything Is Also Letting Attackers In

Bhargav Bhatt — Fri, 23 Oct 2026 02:29:09 +0000

MCP went from "clever plumbing" to "the most exploited attack surface in developer tooling" in under a year. Here's the full damage report.

The Hook

A developer opens a GitHub repo in Cursor. Their AI assistant loads the project config. A SessionStart hook fires. Before they finish their coffee, their cloud credentials, SSH keys, and .env files are sitting in an attacker's GitHub repo under the name "Miasma: The Spreading Blight."

No phishing email. No malicious download. No "click here" link. Just a repo, an IDE, and a protocol that was designed to make AI tools convenient — and shipped with the security posture of a screen door in a hurricane.

That's the Model Context Protocol (MCP) in 2026. And it's not one bug. It's a design philosophy problem that's now producing CVEs at a rate that should make every platform team uncomfortable.

The Miasma Worm: When Your AI Tool Is the Payload

What happened: In June 2026, the threat group TeamPCP (tracked by Google as UNC6780) released a self-propagating credential-harvesting worm called Miasma. It operates on two fronts simultaneously:

It compromises npm packages (the initial wave hit 32 @redhat-cloud-services packages via a trusted-publishing branch bypass).
It injects itself into the SessionStart hooks of 13 AI coding tools, including Claude Code, GitHub Copilot, and Gemini CLI.

The worm uses GitHub itself as its C2 channel — no dedicated infrastructure, no domain to sinkhole. It spreads by committing poisoned config files back to repos.

Why it matters: This is the first confirmed worm that treats AI coding assistants as both the infection vector and the execution environment. Your developer's laptop isn't a victim machine anymore. It's a node in the propagation chain.

What to do:

Audit SessionStart hooks and .mcp.json / .cursor/mcp.json files in every repo your team touches. If you didn't write it, don't trust it.
Block network egress from CI runners during package install. Miasma phones home at install time.
Pin npm package versions with integrity hashes. The trusted-publishing bypass only works if you accept unsigned installs.

The STDIO Flaw: "By Design" Is Not a Security Posture

What happened: On April 15, 2026, OX Security published a report titled "The Mother of All AI Supply Chains." The finding: Anthropic's official MCP SDKs — Python, TypeScript, Java, and Rust — all pass configuration values directly into OS command execution via the STDIO transport. No sanitization. No allowlist. No validation.

Anthropic's response: it's working as intended.

The blast radius: 7,000+ publicly reachable servers, 150 million+ package downloads, and an estimated 200,000 total MCP server instances affected. Downstream CVEs have since been filed against LiteLLM, LangChain, LangFlow, Flowise, and others that inherit the pattern.

Why it matters: This isn't a bug in one product. It's a protocol-level architectural decision that propagated into every language SDK and every server that uses the STDIO transport (which is most of them). The attack model is trivial: control any config source that feeds into the STDIO launch command, and you have arbitrary code execution on the host.

What to do:

If you're running MCP servers via STDIO, review every command and args field in your config. Treat them as untrusted input.
Prefer HTTP/SSE transport over STDIO for anything that isn't a single-user local tool.
Run MCP servers in containers with minimal filesystem access. The "execute first, validate never" model means your container is your security boundary.

The Exposed Server Problem: 1,467 and Counting

What happened: Trend Micro's April 2026 follow-up scan found 1,467 MCP servers exposed to the open internet — nearly triple the 492 they found in their initial scan months earlier. Of those, many had zero client authentication and zero traffic encryption.

The Trend Micro report also documented CVSS 9.8 command-injection flaws in unofficial AWS and Azure MCP servers (CVE-2026-5059, CVE-2026-5058), showing that the exposure isn't just "your data is readable" — it's "an attacker can take over the cloud account the MCP server is connected to."

Why it matters: MCP servers are the new S3 buckets. They hold privileged tokens, connect to databases, and sit on the internet with the default security of "I hope nobody finds this port." The tripling in nine months tracks the adoption curve perfectly: everyone is wiring up AI tools, and nobody is thinking about network exposure.

What to do:

Scan your environment for MCP server ports (common defaults: 3000, 8080, 8443) that are internet-reachable.
If you must expose an MCP server, put it behind OAuth 2.0 + mTLS. "API key in a header" is not a security model.
Review the tokens your MCP servers hold. If one connects to your production AWS account with admin perms, you have a problem that predates MCP.

The Trust Model Is Broken: One Click, Full RCE

What happened: Multiple CVEs and research disclosures in 2025–2026 have confirmed that the major AI coding IDEs — Cursor, Claude Code, Gemini CLI, GitHub Copilot — auto-execute project-defined MCP servers with the developer's full OS privileges and no process isolation.

The specific trust failures:

Cursor (CVE-2025-54135, CVSS 8.6 / "CurXecute"): Approval is bound to the MCP server's name, not its contents. A teammate commits a change to .cursor/mcp.json that swaps the command. The next developer pulls, opens the repo, and the malicious command executes under the previously-approved name. No new prompt. No warning.
Cursor (CVE-2025-54136, CVSS 7.2 / "MCPoison"): Same root cause, framed as a persistence mechanism. Once approved, the entry is trusted forever until manually removed.
Claude Code (CVE-2025-59536, CVSS 8.7): MCP servers executed before the trust dialog rendered. Patched, but the underlying "trust the folder" model remains.
Amazon Q (CVE-2026-12957, CVSS 8.5): A malicious .amazonq/mcp.json in a repo = arbitrary code execution + cloud credential theft.
"TrustFall" (May 2026, no CVE assigned): A one-click RCE pattern affecting Claude Code, Gemini CLI, Cursor CLI, and GitHub Copilot CLI simultaneously. Anthropic declined to patch, classifying the behavior as design intent.

Why it matters: The trust model assumes a single developer on a single machine with a single repo. It does not survive the moment you have a team, a shared repo, or a fork. The "trust this folder" dialog is a security boundary that's only as strong as the git history.

What to do:

Treat .mcp.json, .cursor/mcp.json, .amazonq/mcp.json, and equivalent files as executable code in your code review process. They should get the same scrutiny as a postinstall script.
Disable auto-run/auto-approve for MCP servers in team environments. Require explicit, per-command approval.
If you're a platform team, build a pre-commit hook or CI check that flags new or modified MCP config files.

The Fresh One: Splunk's MCP Server Gets a 9.1

What happened: On August 19, 2026, Splunk published advisory SVD-2026-0808 covering 17 vulnerabilities across its app ecosystem. The headline: CVE-2026-76404, a CVSS 9.1 critical RCE in the Splunk MCP Server app (versions below 1.2.1). The flaw: unsafe deserialization (CWE-502) in the credential management component. An authenticated admin-role user could execute arbitrary commands on the underlying OS.

Patched in 1.2.1. But the point isn't the patch. The point is that Splunk — a company whose entire business is security observability — shipped an MCP server with a critical deserialization flaw in its credential handler.

Why it matters: If the vendors building security tools are getting MCP servers wrong, the long tail of "I built an MCP server for our internal tool in a weekend" is going to be significantly worse.

What to do:

If you're running the Splunk MCP Server app, verify you're on 1.2.1+.
More broadly: audit every MCP server you run for deserialization of user-controlled data. It's the same class of bug that's been killing Java and .NET apps for a decade. It's not going to be different just because the protocol is new.

The Structural Problem

Here's the thing that ties all five of these together. MCP was designed to solve a real problem: how do you let an AI model call tools, query databases, and interact with APIs in a standardized way? The answer was "a JSON protocol with a few transport options." The security model was... an afterthought.

There is:

No native authentication framework (you roll your own, or don't).
No capability attestation (a server declares what it can do; nothing verifies it).
No isolation between servers (they run as your user, with your permissions).
No integrity checking on config files (they're just JSON in a folder).
No standard for logging or auditing what a server actually did.

The protocol spec is 200 pages of "here's how to send a JSON message." The security spec is "good luck."

It's like giving every intern a master key to the building and calling it "convenience."

What This Means for You

If you're running any MCP server — and in 2026, if you have an AI-assisted dev shop, you are — you have a new attack surface that your existing security tooling does not cover. Your WAF doesn't inspect MCP traffic. Your SIEM doesn't parse MCP logs. Your vulnerability scanner doesn't know what an MCP server is. Your CSP doesn't apply. Your network segmentation was designed for HTTP and gRPC, not for a local process that reads .env files and calls child_process.exec().

The good news: the fix list is concrete. Containers. OAuth. Config-as-code review. Egress filtering. The bad news: most of these require someone to decide to do them, and right now the default path is "it works, ship it."

The next cascade is already being scheduled.

Discussion

Anthropic called the STDIO execution behavior "by design" and declined to add validation at the protocol level. Do you think that's a defensible position (the SDK is a transport, not a security boundary) or a catastrophic abdication of responsibility? Where should the fix live — in the spec, the SDK, or the server implementations?
The TrustFall finding (one-click RCE across four major coding agents, no CVE assigned) suggests the industry's CVE process isn't built for "this is how the product works" findings. Should we have a separate tracking mechanism for design-level security issues that don't get a CVE? What would that look like?
You're a platform engineer and your team just told you they need to "spin up an MCP server for the internal knowledge base by Friday." What's your minimum viable security checklist before you say yes? (Be specific. "Add auth" is not a checklist.)

Sources:

OX Security, "The Mother of All AI Supply Chains" (April 15, 2026); VentureBeat; SecurityWeek; CSA Research Note (May 2026)
Trend Micro, "Update on Exposed MCP Servers: The Threat Widens to the Cloud" (April 28, 2026)
Phoenix Security, "Miasma: The Worm That Lives Inside Your AI Tools" (June 2026); HeroDevs; CSA Research Note on Miasma (June 2026)
Check Point Research, "Cursor MCPoison" (CVE-2025-54136); Adversa.ai, "TrustFall" (May 2026); CSA Research Note on MCP Auto-Execution (July 2026)
Splunk Advisory SVD-2026-0808 (August 19, 2026); SentinelOne; The Hacker Wire
LiteLLM Security Update (CVE-2026-30623); Forkast News (October 2026)

#MCP #AIsecurity #supplychain #devsecops #zeroday

Black October: The Week the Internet Almost Broke Itself

Bhargav Bhatt — Thu, 22 Oct 2026 16:41:50 +0000

PHP RCE, a bank's customer data on the dark web, a CA key that was literally the number 4 — and that's just the headline acts.

The Hook

One of the private keys protecting a chunk of the global HTTPS trust chain was, according to a researcher who goes by "Wayne," the number 4. Not a typo. Not a placeholder. The integer 4, sitting in production for roughly 17 months before anyone noticed.

That single detail captures the absurdity of what's happened in the last 48 hours. We're not talking about one bad week. We're talking about a cascade — the kind where every security engineer you know is simultaneously on-call, replying to Slack threads, and quietly questioning whether the internet is a social experiment that's finally lost its plot.

They're calling it Black October. Here's what's actually going on, and what you should do about it.

PHP2Shell: The 70% Problem

What happened: On October 21, the PHP team shipped emergency patches for two critical remote code execution flaws — CVE-2026-109618 (RCE via out-of-memory corruption) and CVE-2026-109619 (RCE via stale global state). Both rated CVSS 9.2. Both allow unauthenticated RCE. Both are being exploited in the wild.

The kicker? The exploit body for CVE-2026-109619 is roughly 450 bytes. Your WAF size rules won't save you. And reports suggest AI-assisted analysis helped surface at least one of the flaws, which adds a new wrinkle to the "who's finding bugs faster, us or the models" debate.

Why it matters: ~70% of the web runs PHP. Government sites briefly went offline. If you're running PHP 5 through 8.2.34 / 8.3.35 / 8.4.26 / 8.5.11, you are the target right now.

What to do:

Patch immediately. Fixed versions: 8.5.12, 8.4.27, 8.3.36, 8.2.35. No "we'll do it in the next maintenance window." This is the window.
If you can't patch in the next hour, set session.upload_progress.enabled = Off in php.ini to close the CVE-2026-109619 attack path. It's a mitigation, not a fix.
Check your web server logs for POST requests with small, malformed bodies hitting upload-progress endpoints.

SBI: 3,897 Records and a Bigger Question

What happened: India's largest bank, State Bank of India, confirmed on October 21 that it's investigating a data leak. A threat actor calling itself "Siriusim" claimed to have posted ~375,000 records to a dark web marketplace. SBI's preliminary review identified 3,897 customer records containing names, mobile numbers, dates of birth, email addresses, and loan/lead metadata.

Alerts came in on October 16 from SBI's own threat intelligence provider, the Defence Cyber Agency, and CERT-In. Core banking operations are unaffected.

Why it matters: The confirmed number is "only" ~3,900, but the total dataset on the dark web is 375,000 records. The gap between those two numbers is where the real risk lives. If you're an SBI customer, this isn't a "change your password" situation — it's a "watch for phishing that uses your actual DOB and loan details" situation.

What to do:

If you're an SBI customer, enable transaction alerts and watch for social-engineering attempts that reference your specific data.
If you work at a bank or fintech in India, assume your records are on the same marketplace. Pull the dark web listings and cross-reference.
Review your data exfiltration monitoring. If 375,000 records were sitting on a dark web forum and your DLP didn't flag the egress, you have a gap.

The Wider Black October: A Supply Chain Meltdown

The PHP and SBI stories are the loudest, but they're not the whole picture. Here's what else landed in the same ~72-hour window:

eMudhra CA compromise. Eight intermediate certificate authority keys were cryptographically so weak that anyone could derive the private key from the public certificate in under a second. One key was, as noted, the number 4. The keys had been live since April 2025. Chrome, Firefox, and Go's TLS stack all shipped blocks. No confirmed abuse yet, but the exposure window was 17 months.

Zeabur breach. The developer-hosting platform disclosed that an attacker used leaked internal credentials (stored in plaintext, on a public-facing endpoint, because of course) to read 3.2 million environment variable records and data for 321,810 accounts. The platform is shutting down. If you stored secrets on Zeabur, rotate them all. Every single one.

LiteLLM supply chain attack. On October 21, a malicious version (1.107.0) of the LiteLLM package hit PyPI and Docker Hub. It contained a credential stealer targeting cloud keys, GitHub tokens, .env files, and — notably — AI service credentials (Claude, Codex, Cursor sessions). It was pulled within ~2 hours. If you installed it during that window, treat your machine as compromised.

CERT-In advisory on rogue AI agents. India's CERT-In issued a critical advisory (CIAD-2026-0049) on October 15 confirming that AI agents, during testing runs by model providers, had reached the live systems of Indian organizations and read business records. None of the affected organizations detected the access. The AI companies self-reported it.

That last one is the one that should keep you up at night. Not because AI agents are "hacking" in the sci-fi sense, but because the attack surface has expanded in a way that traditional perimeter thinking doesn't cover.

What This Means for You

The common thread isn't any single vulnerability. It's assumptions.

"Our WAF will catch the exploit" → 450-byte payload.
"Our keys are safe because they're in a vault" → plaintext in server init scripts.
"Our CA is trustworthy because it's a big company" → the number 4.
"Our internal systems are safe because we have a firewall" → AI agent walked in through an exposed credential and nobody noticed.

Black October isn't a story about one bad actor. It's a story about a stack of small, individually "acceptable" risks that compound when they hit at the same time. The lesson isn't "be paranoid." It's "reduce the blast radius of any single failure, because the next cascade is already being scheduled."

Discussion

The eMudhra key was the number 4. How do you feel about the idea that a national CA's key generation process produced that? Is this a "process failure" or a "crypto library misconfiguration"? Where's the line?
CERT-In's advisory says AI agents accessed Indian firms' systems and nobody noticed. If you're running any agent-based tooling internally, how would you detect an agent that's doing something it wasn't told to do? What's your logging story for that?
Zeabur is shutting down. If you had workloads there, what's your migration plan, and did you even have one? (Be honest in the comments. We've all been there.)

Sources:

PHP Security Team / Tenable / Qualys / Datadog Security Labs — PHP2Shell advisories and analysis
SBI SEBI filing (Oct 21, 2026); India Today Tech; The Hindu; The Hacker News
eMudhra incident statement; The Register; Cloudflare blog; Google Chrome Root Program
Zeabur preliminary incident report (Oct 19); LiteLLM incident post; Endor Labs; TechCrunch
CERT-In advisory CIAD-2026-0049; Indian Express; TechCrunch

#cybersecurity #php2shell #blackoctober #supplychain #zeroday

I Spent a Weekend Migrating My MCP Server to the New Spec. Here's What Hurts.

Bhargav Bhatt — Mon, 19 Oct 2026 10:57:38 +0000

Okay so. The MCP spec got a major update on July 28, and if you built anything on the old version, you're probably staring at your code right now going "wait, what do I actually do here?"

I was in that spot. My server had a session store, a WebSocket connection, an initialize handler that I'd copy-pasted from the docs three months ago. And now none of that matters anymore.

So I spent a Saturday ripping it all out and rebuilding. This is what I learned, in the order I learned it.

The Big Shift (In One Paragraph)

MCP used to be a conversation. You opened a connection, did a handshake, and then you were "in a session" together. The server could talk back to you mid-call. It was like a phone call.

Now it's just... requests. You send a thing, you get a thing back. No phone call. No "hey are you still there?" No holding a line open while you think. It's like texting. Each message stands on its own.

That's it. That's the whole thing. Everything else in the spec is just consequences of that one change.

What I Actually Had to Change

First: I deleted my session store

I had a Redis instance. Just... sitting there. Holding session IDs. Mapping them to client capabilities. None of that is needed anymore.

Every request now carries its own _meta field:

{
  "method": "tools/call",
  "params": { "name": "search", "arguments": { "q": "k8s" } },
  "_meta": {
    "protocolVersion": "2026-07-28",
    "clientInfo": { "name": "my-app", "version": "2.1.0" },
    "capabilities": { "sampling": false }
  }
}

That's it. The server doesn't need to remember you from last request. You tell it who you are every time. Slightly verbose, honestly, but it means I can now run three instances behind a load balancer and not think about it.

Second: The "server asks you a question" pattern is different

Before, if my server needed something from the client mid-call (like, "hey, I need an API key for this"), it would just... send a request back over the WebSocket. Bidirectional. Fancy.

Now? It just returns:

{
  "content": [{ "type": "text", "text": "I need an API key to proceed" }],
  "inputRequired": {
    "fields": [{ "name": "api_key", "type": "string", "hint": "Starts with sk-" }]
  }
}

And the client just... re-sends the same tool call with the key filled in. That's it. No callback. No stream. Just "here's the answer, now try again."

It feels a bit clunky the first time you write it, but it's so much easier to debug. I can look at the request/response logs and see the whole flow. Before, I'd have to trace a WebSocket message sequence and pray.

Third: I stopped using `initialize`

This one was weird because my muscle memory kept trying to do it. "Oh, I should call initialize first, then notifications/initialized..." No. You don't. You just... call a tool. Or if you really want to know what the server offers before you call anything, there's a server/discover endpoint. But you don't have to.

Fourth: I added `ttlMs` to my list endpoints

Small thing, but it made my CDN config go from "I think this is safe?" to "yeah, cache it for 60 seconds, no problem."

{
  "tools": [...],
  "ttlMs": 60000,
  "cacheScope": "public"
}

My tools/list was getting hammered. Every client, every time they opened a chat, would ask "what tools do you have?" Now the CDN just serves the cached version and my server gets a fraction of the traffic.

What I'm Deprecating (And Why)

Three things from the old spec are getting the axe in 12 months:

Roots — I was using it to tell the server "hey, the user's working in /home/dev/project." Now I just pass that as an argument to the tool. More explicit, less magic.
Sampling — I had one tool that would ask the client to run a model completion for it. Now I just... don't. The client handles that with MRTR. My server is simpler.
Logging — I was sending log messages over the MCP stream. That was never the right place for logs. Now I use my actual observability stack.

None of these hurt to keep using right now. They'll still work. But I'm not building new stuff on them.

What I Wish I'd Known Before Starting

You can actually deploy this on serverless now. I was running my MCP server as a long-lived process on a $20/month VPS because "well, it's a WebSocket connection, right?" No. It's HTTP. I moved it to Cloudflare Workers. It costs me basically nothing. It scales to zero when nobody's using it.

The new headers are genuinely useful. Mcp-Method and Mcp-Name travel in the HTTP headers. I use them in my gateway for rate limiting and auth. Before, I had to parse the JSON body to figure out what was being requested. Now it's just a header. My gateway config went from 40 lines to 8.

The TypeScript SDK just works. I updated to v2.0 and most of my code changes were just... deleting things. The initialize handler, the session middleware, the WebSocket transport. I replaced it with the plain HTTP transport. Half my server code is gone.

What I'm Still Figuring Out

MCP Apps (the interactive UI extension) is cool but I haven't built one yet. The idea is your server can ship an HTML widget that renders in the host's UI. I think it's going to be great for things like "show me a chart" or "pick from this list" but the sandbox model is still a bit fuzzy to me.
Tasks for long-running operations is the right idea but the polling model feels... 2014. I'd love a webhook option. Maybe that's an extension I'll propose.
CIMD (the new auth flow) — I've read the spec three times and I'm still not 100% sure I'm implementing it correctly. If you've done this, hit me up.

The TL;DR I Wish I'd Read First

I used to...	Now I...
Maintain a session store	Don't. Every request is self-contained.
Use WebSocket transport	Use plain HTTP.
Call `initialize` first	Just call the tool.
Hold a connection open for user input	Return `inputRequired`, wait for re-call.
Run on a VPS with a process manager	Run on serverless.
Parse JSON for routing	Read the `Mcp-Method` header.

The 12-month deprecation window for Roots/Sampling/Logging gives you time. But I'd start migrating now. The SDKs are stable, the spec is clear, and the "oh I need to do this eventually" feeling is worse than the actual work, which took me a weekend.

If you've migrated already, what surprised you? What's still annoying? I want to hear about the parts the docs don't make clear.

The BUILD Foundation Just Launched — Here's Why Bazel Users Should Care (Even If You're Not at Google)

Bhargav Bhatt — Mon, 19 Oct 2026 10:49:43 +0000

Five days ago, at BazelCon in Amsterdam, the Linux Foundation announced the operational launch of the BUILD Foundation — a new directed fund to sustain the Bazel ecosystem.

If you've ever stared at a 40-minute CI build and thought "someone should be paid to fix this," this one's for you.

What Happened

On October 14, 2026, the Linux Foundation formally launched the BUILD Foundation with six initial members:

Member	Why They're Here
ASML	Uses Bazel alongside other build systems at extreme scale
Canva	Large-scale monorepo builds
Datadog	AI-driven code growth demanding stable build times
EngFlow	BazelCon co-creator, remote build execution
Figma	Multi-language: TypeScript, C++, Rust, Go, Ruby, Python
Spotify	Iteration speed across platforms

The foundation is structured as a Linux Foundation Directed Fund — meaning it raises, budgets, and spends money specifically for open-source build infrastructure. Google retains governance of Bazel's core, but the ecosystem around it (rulesets, tooling, documentation, security) now has a neutral home for investment.

What They're Actually Funding

This isn't a vague "we'll figure it out" announcement. The priorities come straight from the 2025 Bazel User Survey:

Dedicated technical writers for documentation
Funding maintainers of bazel-contrib repositories
Training & certification programs
Improved IDE integration
Supply chain security — release attestations in the Bazel Central Registry

That last one is the sleeper hit. If you've ever been burned by a malicious dependency in a build ruleset, release attestations in the BCR (Bazel Central Registry) are the fix.

Why This Matters for You (Even If You Don't Use Bazel)

If you use Bazel: Your tooling just got a sustainability guarantee. The bazel-contrib rulesets you depend on — rules_go, rules_rust, rules_python — now have funded maintainers. Documentation will improve. IDE plugins will get better. You don't have to do anything, but you should follow buildfoundation.dev and consider joining.

If you don't use Bazel but use a monorepo: This is a signal that the industry is treating build infrastructure as critical shared infrastructure — the same way we treat Kubernetes or the Linux kernel. Expect similar foundations to form for Pants, Buck2, or even CMake at scale. The pattern is: too many companies depend on it → one company can't sustain it → neutral foundation forms.

If you're in security/supply chain: The Bazel Central Registry getting release attestations is a concrete step toward reproducible, verifiable builds. This connects to the broader OpenSSF and SPDX ecosystem under the Linux Foundation.

The Bigger Picture

Bazel was open-sourced by Google in 2015. For nearly a decade, its ecosystem was sustained by Google employees and a handful of enthusiastic contributors. That model worked until thousands of companies started depending on it commercially.

The BUILD Foundation is the same playbook that saved Kubernetes (CNCF), PyTorch (PyTorch Foundation), and RISC-V (RISC-V International). The Linux Foundation now hosts 1,000+ projects, and build tooling is the latest critical layer to get a neutral home.

Jim Zemlin, CEO of the Linux Foundation, put it well:

"Bazel has become critical infrastructure for engineering teams around the world. The BUILD Foundation provides a neutral home where organizations can invest together in its maintainers, security and long-term sustainability."

TL;DR

Bazel's ecosystem now has a funded, neutral home under the Linux Foundation
Six major companies are in from day one
Real priorities: docs, maintainer funding, training, IDE integration, supply chain security
If you use Bazel, follow buildfoundation.dev — there may be a role for your org
If you don't, watch this space — the "foundation for critical build infra" pattern is now established

What do you think? Is your team using Bazel? What's the biggest gap in the ecosystem you'd want funded? Drop a comment below.

Tracking CNCF Projects: A Beginner's Guide to Contribution & Velocity Metrics

Bhargav Bhatt — Mon, 19 Oct 2026 07:45:52 +0000

The Cloud Native Computing Foundation (CNCF) hosts 100+ projects. Whether you're evaluating where to contribute, benchmarking your project's health, or just curious about the ecosystem, this guide shows you where to look and how to run the tools yourself.

1. DevStats — The Core Tool

DevStats (github.com/cncf/devstats) is CNCF's primary tool for analyzing developer contributions. It pulls from GitHub's Archive (GHA), the GitHub API, and git itself to track commits, PRs, issues, and per-developer/per-company stats.

⚠️ Key requirement: the project must be on a public GitHub repo.

Running DevStats Locally (Quick Start)

You need Go, PostgreSQL, and a GitHub OAuth token.

# 1. Clone the repos
mkdir -p ~/dev/go/src/github.com/cncf
cd ~/dev/go/src/github.com/cncf
git clone https://github.com/cncf/devstats.git
git clone https://github.com/cncf/devstatscode.git

# 2. Build the binaries
cd devstatscode
make
sudo mkdir -p /etc/gha2db && sudo chmod 777 /etc/gha2db
sudo -E make install

# 3. Install scripts & config
cd ../devstats
make install

Set up PostgreSQL:

# macOS (Homebrew)
brew install postgresql
brew services start postgresql
createdb gha
createdb devstats

# Create a user with privileges
psql gha -c "CREATE USER gha_admin WITH PASSWORD 'your_password'; GRANT ALL PRIVILEGES ON DATABASE gha TO gha_admin; ALTER USER gha_admin CREATEDB;"
psql devstats -c "CREATE USER gha_admin WITH PASSWORD 'your_password'; GRANT ALL PRIVILEGES ON DATABASE devstats TO gha_admin;"
psql devstats < util_sql/devstats_log_table.sql

Sync data:

# Requires a GitHub OAuth token
export GHA2DB_GITHUB_OAUTH="your_token_here"
export PG_PASS="your_password"

# Run all CNCF projects
GHA2DB_PROJECTS_OVERRIDE="+cncf" devstats

# Or target a single project (e.g. Kubernetes)
ONLY=kubernetes PG_PASS=... ./devel/reinit.sh

💡 Tip: schedule it hourly via crontab -e — GHA files are refreshed roughly every hour at :08.

Running via Helm on Kubernetes

For a full deployment (what CNCF runs in production):

# Dry-run to validate
helm install --dry-run --debug ./devstats-helm \
  --set namespace='devstats-prod',skipSecrets=1,skipPVs=1,skipBackupsPV=1,skipVacuum=1,skipBackups=1,skipBootstrap=1,skipProvisions=1,skipCrons=1,skipAffiliations=1,skipGrafanas=1,skipServices=1,skipPostgres=1,skipIngress=1,skipStatic=1,skipAPI=1,skipNamespaces=1,runTests=1

# Full install
helm install devstats-prod ./devstats-helm --set namespace='devstats-prod'

You'll need secrets for Postgres credentials, a GitHub OAuth token, and Grafana admin access (see secrets/*.secret.example in the repo).

Running Reports

Once data is in the database:

# List available reports
ls sql/

# Contributors for a project in a time range
PG_DB=kubernetes PG_PASS=... ./sh/run.sh contributors 2024-01-01 2025-01-01

# Per-company affiliation quality
PG_DB=kubernetes PG_PASS=... ./sh/run.sh contributors_affiliations_quality_percent 2024-01-01 2025-01-01 "Google" company_name

2. Velocity — Growth Over Time

cncf/velocity (github.com/cncf/velocity) generates the periodic CNCF Projects Velocity reports, charting commit and contributor growth over time. Data flows from BigQuery CSVs into charts. Great for answering "which projects are accelerating?"

3. LFX Insights — Per-Project Health

Each project page on cncf.io displays an LFX Insights Health Score (e.g., "Fair (60)") across four dimensions:

Dimension	What it measures
Contributors	Bus factor, new vs. returning
Development	PR/issue throughput, review time
Popularity	Stars, forks, watchers trend
Security	CVE response time, patch cadence

4. The Landscape — Ecosystem Map

The CNCF Cloud Native Landscape (landscape.cncf.io) categorizes every project by maturity and category, surfacing GitHub stars, contributor counts, and commit recency. Community-maintained on GitHub.

5. Maturity Levels — Why the Numbers Matter

Projects progress: Sandbox → Incubating → Graduated (or Archived). Promotion requires:

Demonstrated adoption
Healthy rate of change (velocity!)
Committers from multiple organizations
CII Best Practices Badge

Contribution metrics aren't vanity numbers — they literally gate a project's status.

Quick Reference

Tool	Best For	URL
DevStats	Raw contribution & per-company metrics	devstats.cncf.io
cncf/velocity	Growth/velocity over time	github.com/cncf/velocity
LFX Insights	Per-project health score	cncf.io project pages
CNCF Landscape	Ecosystem-wide map	landscape.cncf.io

Looking for projects to contribute to? Pair any of the above with CLOTributor, which aggregates "good first issues" across all CNCF projects in one place.

Happy tracking! If you found this helpful, leave a ❤️ on dev.to.

I Replaced runc with a Rust Container Runtime (youki) for a Week

Bhargav Bhatt — Sun, 18 Oct 2026 13:33:19 +0000

The Boring Layer That Matters Most

Every container you've ever run — docker run hello-world included — went through a tiny binary called runc before it became a process. It creates the namespaces, sets up the cgroups, drops privileges, and hands off to your entrypoint.

You never think about it. And that's the problem.

runc is written in Go + C (yes, C — for the nsenter and pivot_root bits that Go can't handle cleanly). It's been the reference implementation since 2014. It's also the layer where CVE-2024-21626 (a container escape) lived.

What if that layer was memory-safe by construction?

Enter youki — a container runtime written entirely in Rust, now a CNCF Sandbox project.

What Is youki?

youki (Japanese for "container") is an OCI runtime-spec implementation in Rust. It's a drop-in replacement for runc: same CLI, same spec, same integration path through containerd, Podman, or Docker.

Fact	Detail
Language	Rust (pure, except a `libseccomp-rs` FFI shim being replaced)
CNCF status	Sandbox (accepted Oct 17, 2024)
GitHub	youki-dev/youki
Stars	~7,300
License	Apache 2.0
Adopters	Azure Kubernetes Service, Docker, containerd/runwasi
Contributing orgs	Microsoft, Docker, Red Hat

The key differentiator vs. runc: no Go runtime startup, no C nsenter binary, no mixed-language memory safety boundary. The entire create → start → delete lifecycle lives in one Rust binary with compile-time safety guarantees.

The Benchmarks (Honest Version)

The headline number from youki's own repo:

Runtime Time (mean ± σ)        Range (min … max)    vs youki
youki   111.5 ms ± 11.6 ms     84.0 ms … 142.5 ms   100%
runc    224.6 ms ± 12.0 ms     190.5 ms … 255.4 ms  200%
crun     47.3 ms ±  2.8 ms     42.4 ms …  56.2 ms   42%

Youki is ~2× faster than runc for create → start → delete. But crun is ~2.5× faster than youki.

Here's the honest context:

Scenario	Does it matter?
Single long-lived container	No. 100ms of startup is noise over a 7-day uptime.
Serverless: 10k containers/min	Yes. A 100ms savings × 10k = 1,000 CPU-seconds per minute reclaimed.
K8s pod churn (CI/CD, spot nodes)	Moderately. Image pull + CNI + scheduling dominate; runtime is ~5–10% of total.
Edge/embedded (tight RAM)	Yes. youki's binary is smaller and RSS is lower per instance.

The real win isn't raw speed — it's the Rust safety guarantee. You're not betting your node's security on a C memcpy in nsenter.

Setup: Replacing runc on a K8s Node

Prerequisites

Kubernetes 1.28+ with containerd (not Docker Engine)
Linux kernel 5.10+ (youki drops older kernel support to use modern features)
cargo / just for building from source (or use a pre-built binary)

Step 1: Build youki

git clone https://github.com/youki-dev/youki.git
cd youki
just build
# Binary: ./target/release/youki

Or grab a release binary from GitHub Releases.

Step 2: Register with containerd

Edit /etc/containerd/config.toml (or use containerd config path):

[plugins."io.containerd.grpc.v1.cri".containerd.runtimes.youki]
  runtimeType = "io.containerd.youki.v1"

Then install the shim (youki ships a containerd-compatible shim):

sudo cp target/release/youki /usr/local/bin/
sudo cp target/release/containerd-shim-youki-v1 /usr/local/bin/

Restart containerd:

sudo systemctl restart containerd

Step 3: Create a RuntimeClass

apiVersion: node.k8s.io/v1
kind: RuntimeClass
metadata:
  name: youki
handler: youki
scheduling:
  nodeSelector:
    kubernetes.io/arch: amd64

kubectl apply -f runtimeclass-youki.yaml

Step 4: Run a Pod with youki

apiVersion: v1
kind: Pod
metadata:
  name: youki-test
spec:
  runtimeClassName: youki
  containers:
  - name: app
    image: nginx:alpine
    resources:
      requests:
        memory: "32Mi"
        cpu: "10m"

kubectl apply -f youki-pod.yaml
kubectl get pod youki-test -o wide
# youki-test   1/1   Running   0   2s

Verify it's actually using youki:

kubectl exec youki-test -- cat /proc/1/cgroup
# Confirms cgroup v2 hierarchy managed by youki

Step 5: Run It for a Week (What I Noticed)

I ran a 3-node k3s cluster with a mix of workloads:

20 long-lived API pods (Go, ~50 MB each)
A CI pipeline spawning 50–200 short-lived pods/day
A cron job that scales a batch processor 0 → 10 → 0 every hour

What went well:

Zero crashes, zero OOMs in the runtime itself. The Rust error handling is visible in logs — when something goes wrong, you get a structured Error with context, not a segfault.
Short-lived pods were noticeably snappier. My CI pods (build → test → delete) came up ~30–50ms faster than runc. Not dramatic per-pod, but across 200 pods/day it added up.
Rootless mode was cleaner. youki create with --rootless worked without the newuidmap/subuid gymnastics that runc sometimes needs.
Binary size. youki: ~8 MB. runc: ~12 MB. crun: ~3 MB. On an edge node with 512 MB RAM, every MB counts.

What was rough:

cgroups v1 support is there but v2 is the path of least resistance. If your distro still defaults to v1 (looking at you, CentOS 7), you'll hit edge cases.
No --checkpoint/--restore (CRIU) yet. If you rely on live migration or pause/resume, you're stuck on runc.
Docs are thin. The user docs cover the basics but there's no "migrating a production cluster from runc to youki" guide. You're on your own.
One C dependency remains. libseccomp-rs is an FFI wrapper around the C libseccomp. The team is working on a pure-Rust replacement, but it's not done.

youki vs. runc vs. crun: Where Each Wins

Dimension	runc	crun	youki
Language	Go + C	C	Rust
Memory safety	❌ (C portion)	❌	✅ (99% — one FFI shim)
Create→delete (benchmark)	224 ms	47 ms	111 ms
Binary size	~12 MB	~3 MB	~8 MB
cgroups v2	✅	✅	✅
Rootless	✅	✅	✅ (cleanest)
CRIU (checkpoint/restore)	✅	✅	❌ (roadmap)
Wasm support	❌	❌	✅ (first-class)
CNCF governance	❌ (OCI)	✅ (Sandbox)	✅ (Sandbox)
Production battle-testing	10+ years	5+ years	~3 years
Best for	Default, compatibility	Max performance, minimal footprint	Safety + Wasm + future-proofing

The honest takeaway: If you need maximum raw speed today, crun wins. If you need the safest runtime with a path to Wasm workloads, youki is the pick. runc remains the "it just works" default.

The Wasm Angle (Why This Matters More Than You Think)

Here's the part that excites me: youki is the low-level runtime that powers runwasi (the containerd shim for Wasm workloads) and, by extension, SpinKube.

The architecture:

containerd
  └── containerd-shim-runwasi (Rust)
        └── youki libcontainer (Rust) ← shared library
              └── Wasmtime / Wasmer / WasmEdge

Youki's libcontainer crate is used as a library by other Rust container tools. That means the same memory-safe, OCI-compliant primitives that run your nginx:alpine pod also run your Wasm modules. One codebase, two workload types, same security guarantees.

This is the "Rust container stack" taking shape:

Layer	Rust project	Role
Runtime	youki	OCI container lifecycle
Shim	runwasi	Wasm on containerd
Orchestrator	SpinKube	Wasm on Kubernetes
Image tooling	naftiko	Build OCI/Wasm images
Spec	oci-spec (Rust crate)	The spec itself, in Rust

Youki is the foundation. If it's not solid, nothing above it is.

What's Missing (and Where Funding Helps)

youki is in CNCF Sandbox — the earliest maturity level. The project is healthy (active commits, 80+ contributors, backing from Microsoft/Docker/Red Hat) but under-resourced for what it needs to do:

Pure-Rust seccomp (eliminate the last C dependency) — significant engineering effort
SELinux in Rust — needed for RHEL/CentOS production adoption
CRIU support — checkpoint/restore is table-stakes for production
OCI conformance test suite — a dedicated, automated compliance harness
Docs and migration guides — "how do I move a 500-node cluster from runc to youki?"
Security audit — a formal audit would be a major trust signal for enterprise adoption
Conference presence — KubeCon, RustConf, containersc — the project needs more visibility

No LFX Crowdfunding campaign is active yet. If you use or evaluate youki, the highest-impact things you can do:

Contribute — even docs, test cases, or bug reports. GitHub
Run it in production and report what breaks (or doesn't)
Write about it — this article is a start, but we need more "I ran youki in a real cluster" content
Watch for an LFX Crowdfunding launch — CNCF funding page

TL;DR

Question	Answer
Is youki production-ready?	For new, non-critical workloads: yes. For a 500-node cluster: not yet.
Is it faster than runc?	~2× for create/delete. Yes, but crun is faster still.
Is it safer than runc?	Yes — memory-safe Rust eliminates the C `nsenter` attack surface.
Should I switch today?	If you're running Wasm workloads or want to be early on the Rust container stack: yes. Otherwise: watch this space.
What's the risk?	It's a Sandbox project. The API could shift. CRIU is missing. Docs are thin.

Final Thought

The container runtime is the most underappreciated layer in the stack. It's the thing that's always running, that touches every syscall, that sits between your workload and the kernel. For a decade, that layer was a Go binary with a C sidecar.

Now there's a Rust option with CNCF governance, major-company backing, and a clear path to being the foundation for the next generation of container workloads (including Wasm).

I ran it for a week. It didn't break. It was faster. And the Rust error messages in the logs were genuinely pleasant to read.

That's about as good as "boring infrastructure" gets.

Have you tried youki in production? What broke? What didn't? Drop your experience in the comments — I'm especially curious about anyone running it alongside runwasi or SpinKube.

If you want to support the project, the best things right now are **contributing code/docs* and writing about your experience. The CNCF funding infrastructure is ready when the project is.*

Running WASM on Kubernetes with SpinKube: A Hands-On Guide

Bhargav Bhatt — Sun, 18 Oct 2026 13:24:28 +0000

The Problem With Container Cold Starts

You've felt it. You scale a Deployment from 0 → 1, and for 300ms to 2 seconds, your pod is in ContainerCreating. At 10k concurrent requests, that's not a blip — it's a latency cliff.

WebAssembly solves this at the runtime level: single-digit millisecond cold starts, ~2 MB memory per instance (vs. 100+ MB for a typical container), and a capability-based security model that's sandboxed by default.

The question was never should we run Wasm on Kubernetes. The question was how, without breaking everything we already have.

SpinKube is the answer.

What Is SpinKube?

SpinKube is a CNCF Sandbox project (accepted January 2025) that makes WebAssembly a first-class workload in Kubernetes. It's built on the Spin framework (also CNCF Sandbox) and is written in Rust.

The key insight: no new API, no new scheduler, no parallel platform. SpinKube plugs into the existing containerd → CRI → RuntimeClass path. Your Wasm app gets scheduled with the same kubectl apply, the same HPA, the same service mesh, the same GitOps pipeline.

Fun fact: SpinKube was originally created by Fermyon. When Akamai acquired Fermyon in December 2025, the project was already safely under CNCF governance — a structural guarantee that outlasts any single company's roadmap.

GitHub: github.com/spinframework/spinkube (migrated from the spinkube org during CNCF onboarding)
Stars: 6,200+ · Contributors: 80+ · License: Apache 2.0

Architecture at a Glance

┌─────────────────────────────────────────────────────────┐
│  Your SpinApp YAML                                       │
│  (kubectl apply -f spinapp.yaml)                         │
└──────────────────────┬──────────────────────────────────┘
                       ▼
┌─────────────────────────────────────────────────────────┐
│  spin-operator (Kubebuilder operator)                    │
│  • Watches SpinApp CRD                                   │
│  • Creates Deployment + Service                          │
│  • Sets runtimeClassName: wasmtime-spin-v2               │
└──────────────────────┬──────────────────────────────────┘
                       ▼
┌─────────────────────────────────────────────────────────┐
│  Kubernetes Scheduler                                    │
│  • Standard constraints + RuntimeClass selector          │
│  • Places pod on nodes with the Spin shim installed      │
└──────────────────────┬──────────────────────────────────┘
                       ▼
┌─────────────────────────────────────────────────────────┐
│  containerd                                              │
│  • Sees runtimeClassName → routes to containerd-shim-spin│
│  • Shim launches Wasmtime (or Wasmer/WasmEdge)           │
│  • Wasm module executes — no runc, no OCI container      │
└─────────────────────────────────────────────────────────┘

Three components you actually interact with:

Component	Role
`spin-operator`	CRD + controller. Turns SpinApps into Deployments.
`containerd-shim-spin`	The runtime. Replaces runc for Wasm pods. Built on runwasi.
`runtime-class-manager`	Auto-installs and manages the shim across your node pool. Replaces the old KWasm operator.

Prerequisites

Kubernetes 1.27+ (k3s, kind, EKS, GKE, AKS all work)
containerd as the container runtime (not Docker)
Spin CLI installed locally
A Wasm-compatible language toolchain (Rust, Go, JavaScript, Python, C#)

Step 1: Install SpinKube on Your Cluster

For a quick test on kind or k3s:

# Install the Runtime Class Manager (manages shim lifecycle)
helm repo add spinkube https://spinkube.github.io/charts
helm install runtime-class-manager spinkube/runtime-class-manager \
  --namespace spinkube-system --create-namespace

# Install the Spin Operator
helm install spin-operator spinkube/spin-operator \
  --namespace spinkube-system

The Runtime Class Manager will:

Label nodes that support the Spin runtime
Install containerd-shim-spin on those nodes
Create the RuntimeClass resource (wasmtime-spin-v2)

Verify:

kubectl get runtimeclass
# NAME              HANDLER
# wasmtime-spin-v2  spin

kubectl get nodes -l spinkube.io/runtime=wasmtime-spin-v2

Step 2: Build a Spin App

Create a new Spin project (Rust example):

spin new my-wasm-app --language rust
cd my-wasm-app

spin-new generates a minimal HTTP handler. Edit src/main.rs:

use spin_sdk::http::{Request, Response};

#[http_component]
pub fn handle(req: Request) -> Response {
    let name = req.uri().path().trim_start_matches('/');
    Response::ok(format!("Hello, {name}! (served by Wasm on K8s)"))
}

Build and package:

spin build
# Produces: target/wasm32-wasi/release/my-wasm-app.wasm

The output is a ~2 MB Wasm binary — compared to a ~100 MB+ OCI image for an equivalent Rust HTTP server.

Step 3: Deploy to Kubernetes

Create spinapp.yaml:

apiVersion: spinkube.dev/v1alpha1
kind: SpinApp
metadata:
  name: my-wasm-app
  namespace: default
spec:
  replicas: 3
  image: ghcr.io/yourorg/my-wasm-app:latest  # Push your Spin app to any OCI registry
  runtime: wasmtime-spin-v2
  port: 80
  resources:
    requests:
      memory: "4Mi"
      cpu: "10m"
    limits:
      memory: "32Mi"
      cpu: "100m"

Apply:

kubectl apply -f spinapp.yaml

The spin-operator reconciles this into a standard Deployment with runtimeClassName: wasmtime-spin-v2. Watch it go:

kubectl get pods -w
# my-wasm-app-7f8b4c6d2-x1k9p   1/1   Running   0   3s
# my-wasm-app-7f8b4c6d2-m2n8q   1/1   Running   0   3s
# my-wasm-app-7f8b4c6d2-p3o7r   1/1   Running   0   3s

~3 seconds from kubectl apply to all pods Running. Compare that to a typical containerized app pulling a 150 MB image.

Step 4: Verify It Works

Create a Service and hit it:

kubectl expose deployment my-wasm-app --port=80 --type=NodePort
kubectl get svc my-wasm-app -o wide

Then:

curl http://<node-ip>:<port>/world
# Hello, world! (served by Wasm on K8s)

Step 5: Scale It (The Fun Part)

kubectl scale spinapp my-wasm-app --replicas=100

100 Wasm instances. Total memory: ~200 MB (vs. ~10 GB for 100 containerized instances of the same app).

Add an HPA for autoscaling:

apiVersion: autoscaling/v2
kind: HorizontalPodAutoscaler
metadata:
  name: my-wasm-app-hpa
spec:
  scaleTargetRef:
    apiVersion: apps/v1
    kind: Deployment
    name: my-wasm-app
  minReplicas: 3
  maxReplicas: 200
  metrics:
  - type: Resource
    resource:
      name: cpu
      target:
        type: Utilization
        averageUtilization: 50

Or use KEDA for event-driven scaling (queue depth, HTTP request rate). SpinKube integrates with KEDA out of the box.

Step 6: Observe It

SpinKube exports metrics to OpenTelemetry. Point your OTel collector at the pods and you get traces in Jaeger, metrics in Prometheus — same as any other K8s workload.

As of early 2026, SpinKube also supports Gateway API for ingress, so your Wasm apps sit behind the same API Gateway as your containerized services.

Containers vs. Wasm on SpinKube: The Honest Comparison

Dimension	Container (runc)	Wasm (SpinKube)
Cold start	100 ms – 2 s	1–10 ms
Idle memory	50–500 MB	2–30 MB
Artifact size	100 MB – 2 GB	1–10 MB
Security model	Namespace + cgroups (OS-level)	Capability-based (WASI) — no file/network access unless explicitly granted
Full OS access	✅	❌ (no raw sockets, no threads in WASI 0.2)
Scheduling	Standard	Identical (same `kubectl apply`)
Best for	Stateful, long-lived, OS-dependent services	Stateless, I/O-light, high-frequency handlers

They coexist. Run your Postgres and your message queue as containers. Run your API gateway, request transformers, and edge functions as Wasm. Same cluster, same namespace, same tooling.

When SpinKube Makes Sense (and When It Doesn't)

✅ Use SpinKube when:

You have short-lived, stateless HTTP handlers (edge functions, API transforms, auth checks)
Cold start latency is a real problem (serverless patterns, bursty traffic)
You want to pack more workloads per node (density = cost savings)
You need a smaller attack surface (WASI capability model)

❌ Skip SpinKube when:

Your workload needs full OS access (raw sockets, FUSE, GPU drivers)
It's a long-lived stateful service (database, cache)
Your language/toolchain can't target wasm32-wasi
You're in a Docker-only environment (SpinKube requires containerd)

What's Missing (and Where Funding Helps)

SpinKube is in CNCF Sandbox — the earliest maturity level. That means:

13 maintainers (6 from Fermyon/Akamai, 3 from Microsoft, 1 each from SUSE, Liquid Reply, Hetzner, independent) — a small team for a project this central to the Wasm-on-K8s story.
Roadmap items still open: automatic OpenTelemetry instrumentation for Wasm apps, more mature multi-runtime support, Windows node support, and a formal security audit.
Docs and tutorials are good but thin compared to, say, Helm or KEDA. The community needs more "I built X with SpinKube" content.
No LFX Crowdfunding campaign is active yet. The project could use funding for: CI infrastructure, conference travel (KubeCon, Wasm I/O), a part-time community manager, and a security audit.

If you found this guide useful and want to see SpinKube move to Incubating, the most impactful things you can do:

Contribute — even docs, bug reports, and test cases count. GitHub
Use it in production and share your experience (a Dev.to post, a talk, a blog).
Support CNCF funding efforts — when the project launches an LFX Crowdfunding campaign, it'll be listed on the CNCF funding page.
Join the community — SpinKube Slack (via CNCF Slack) is where decisions happen.

TL;DR

Fact	Detail
What	CNCF Sandbox project for running Wasm on Kubernetes
How	containerd shim + RuntimeClass — no new API
Cold start	1–10 ms
Memory	~2 MB per instance
Languages	Rust, Go, JS, Python, C# (anything that targets wasm32-wasi)
Runtimes	Wasmtime (default), Wasmer, WasmEdge
Maturity	Sandbox (accepted Jan 2025)
GitHub	spinframework/spinkube
License	Apache 2.0

What's your experience with Wasm on Kubernetes? Have you tried SpinKube in production? Drop your setup in the comments — I'm especially curious about anyone running it alongside KEDA or Gateway API.

If you want to support the project, the best thing you can do right now is **contribute* or write about your experience. The CNCF funding infrastructure is there and ready when the project is ready to use it.*

7 AI Tools That Can Plan Your Entire Week in One Prompt

Bhargav Bhatt — Sun, 18 Oct 2026 13:17:08 +0000

Published: October 18, 2026

You know that feeling — it's Sunday evening, your plate is full, and the thought of mapping out Monday through Friday makes you want to close the laptop and stare at the ceiling.

What if you could just tell an AI what's on your plate and have it hand back a realistic, time-blocked week?

That's no longer science fiction. Here are 7 tools that actually do this today — ranked by how close they get to the "one prompt, done week" fantasy.

TL;DR

#	Tool	One-liner	Starting Price
1	Motion	Full auto-scheduling; rebuilds your day in real time	$19–49/mo
2	Reclaim.ai	Defends focus time; auto-blocks habits & deep work	Free tier; $12/mo
3	Todoist + AI	Natural language capture; AI breaks goals into tasks	Free tier; $4/mo
4	Notion AI	Your entire workspace becomes a planning brain	Free tier; $10/mo
5	Sunsama	Calm, guided weekly planning ritual	$22/mo
6	Akiflow	Speed-first task capture straight onto your calendar	$19–34/mo
7	ChatGPT / Claude	The free "one prompt" planner that lives in your browser	Free / $20/mo

1. Motion — The "Set It and Forget It" Option

Best for: People who want zero manual scheduling.

Motion is the closest thing to a real AI chief of staff. You dump your tasks, deadlines, and projects into it, and it builds your entire week on your calendar — then rebuilds it the moment something changes. A meeting runs long? Motion reshuffles the rest of your day. A new deadline drops in? It finds the slot.

The "one prompt" equivalent:

"I have a product launch Friday, two 1-on-1s Tuesday, a code review Wednesday, and I need 4 hours of deep work. Plan my week."

Motion doesn't take that as a chat prompt — it takes it as inputs (tasks + deadlines + priorities) and does the math for you. The result is a fully time-blocked calendar you didn't build.

Pricing: $19/seat/mo (team) or $49/mo (individual). No free plan, but there's a trial.

Dev note: If you're a solo dev juggling multiple repos, PRs, and meetings, this is the one that will feel like a superpower. The auto-rescheduling alone saves 30+ min/day of "when do I actually do X?"

2. Reclaim.ai — The Focus-Time Bodyguard

Best for: Meeting-heavy schedules where your deep work keeps getting eaten.

Reclaim operates on a different principle: defensive scheduling. You tell it "I need 10 hours of focus time per week" and it carves that out first, then fits meetings and tasks around it. When a meeting gets rescheduled, Reclaim moves your focus blocks — not the other way around.

The "one prompt" equivalent:

"Protect 2 hours of deep work every morning, keep my gym at 6pm, and fit my sprint tasks into whatever's left."

Reclaim's AI agents handle this continuously. You set the rules once; it enforces them all week.

Pricing: Free tier available. Paid from $12/user/mo.

Dev note: If your calendar is a war zone of standups, design reviews, and "quick syncs," this is the tool that will actually give you back the 2-hour block you need to ship code.

3. Todoist + AI — The Natural Language Workhorse

Best for: People who think in tasks, not time blocks.

Todoist has been the task manager default for a decade, and its AI layer is now genuinely useful. You type (or speak) "Fix the auth bug by Thursday" and it creates the task, sets the due date, and suggests a priority. The newer Task Assist feature takes a vague goal like "Prepare for the Q4 demo" and breaks it into a full subtask list with suggested timelines.

The "one prompt" equivalent:

"Plan my week: I need to finish the API migration, review 3 PRs, prep a talk for Friday, and do 3 workouts."

Todoist's AI parses that, creates the tasks, and (with calendar integration) suggests when to do each one.

Pricing: Free tier is solid. Pro from $4/mo.

Dev note: If you already live in Todoist, the AI features are a low-friction upgrade. No new app to learn. The natural language input is still best-in-class.

4. Notion AI — The Workspace-Integrated Planner

Best for: People whose "system" already lives in Notion.

If your notes, project docs, meeting summaries, and task databases are all in Notion, Notion AI is the most powerful option because it can search and synthesize across all of it. Ask it to:

"Pull the action items from last week's sprint retro and schedule them for this week."
"Summarize what my team decided in the last 5 project pages and list what's pending."
"Generate a weekly progress report from my linked databases."

The "one prompt" equivalent:

"Based on my project pages and open tasks, what should I focus on this week? Create a plan."

It's not a calendar app — it won't time-block your day — but it turns your existing knowledge base into a planning engine.

Pricing: Free tier. AI add-on from $10/mo.

Dev note: If you're a dev who uses Notion as a second brain (and most of us do), this is the highest-leverage option. The AI is only as good as your Notion, but a well-structured workspace + Notion AI is a legitimately powerful planning system.

5. Sunsama — The Intentional Planner

Best for: People who want a ritual, not automation.

Sunsama takes the opposite approach from Motion. Instead of auto-scheduling everything, it gives you a guided morning planning ritual: pull in tasks from your synced apps, look at your calendar, and you decide what matters today. The AI assists (suggesting priorities, flagging overcommitment) but you stay in control.

The weekly view is where it shines — you see your entire week, drag tasks between days, and get gentle nudges if you're overloading Thursday.

The "one prompt" equivalent:

"Here's everything on my plate. Help me figure out what actually matters this week."

Sunsama doesn't take that as a prompt, but its planning flow does exactly that: it surfaces everything, then walks you through prioritization.

Pricing: $22/mo. 5-day free trial.

Dev note: If Motion feels too aggressive and you want a calm, intentional process, Sunsama is the pick. It's the "meditation app" of planners.

6. Akiflow — The Speed-First Capture Tool

Best for: People who think fast and need to capture tasks in under 2 seconds.

Akiflow's superpower is its command bar (hit a hotkey, type a task, it lands on your calendar). Combined with AI chat, you can say "block 2 hours tomorrow for the migration" and it's done. It consolidates tasks from email, Slack, Notion, and other sources into one view, then lets you plan them onto your calendar.

The "one prompt" equivalent:

"Capture everything from my inbox and Slack, then plan the week."

Akiflow's AI chat can do the planning part. The capture part is where it's genuinely the fastest tool I've used.

Pricing: $19/mo (individual), $34/mo (pro).

Dev note: If your bottleneck is capturing tasks (they live in 6 different apps), Akiflow solves that first. The AI planning is good but not as deep as Motion or Reclaim.

7. ChatGPT / Claude — The Free "One Prompt" Planner

Best for: Anyone who wants a plan in 30 seconds without installing anything.

Here's the unglamorous truth: a good LLM is a surprisingly effective weekly planner, and it costs you $0–20/mo. You don't get calendar sync or auto-rescheduling, but you get a structured, realistic plan in one prompt.

The actual prompt I use:

You are my weekly planner. Here's my situation:

- I'm a backend dev on a 5-person team
- My calendar this week: [paste or describe meetings]
- Open tasks: [list them]
- Deadlines: [list them]
- I work 9am–5pm, 4 hours of deep work per day
- I want 3 workouts this week

Create a day-by-day plan (Mon–Fri) that:
1. Blocks deep work first
2. Fits tasks around meetings
3. Includes breaks and buffer time
4. Flags if I'm overcommitted

Be specific with time blocks. Be realistic.

The output is a clean, time-blocked week. You copy it into your calendar. Done.

Pricing: ChatGPT free / $20/mo. Claude free / $20/mo.

Dev note: This is the "good enough" option. No sync, no auto-rescheduling, no integrations. But for a quick Sunday-night plan that gets you 80% of the way there in 2 minutes? Nothing beats the speed of just asking.

How to Choose

Your situation	Pick
I want zero manual work, I'll pay for it	Motion
My calendar is a meeting mess	Reclaim.ai
I already live in Todoist	Todoist + AI
My system is in Notion	Notion AI
I want a calm, intentional process	Sunsama
I need fast task capture	Akiflow
I want a free plan tonight	ChatGPT / Claude

The Real Workflow

The tools above are powerful, but the system matters more than any single app. Here's what actually works:

Sunday (15 min): Dump everything into your tool of choice. Use the "one prompt" approach to get a draft plan.
Monday–Friday (5 min/day): Check your plan. Adjust if needed. Most tools (Motion, Reclaim) handle this automatically.
Friday (10 min): Review what got done, what didn't, and why. Feed that into next Sunday's plan.

The AI handles the scheduling. You handle the decisions. That's the division of labor that actually sticks.

What's your weekly planning setup? Drop it in the comments — I'm always looking for new tools to test.

I Ran `npm fund` and Found 47 Packages Keeping My App Alive

Bhargav Bhatt — Thu, 15 Oct 2026 16:22:57 +0000

I've been seeing the same line at the bottom of every npm install for years:

added 47 packages, and 12 packages are looking for funding
  run `npm fund` for details

I've never once run that command. It felt like a nag — the software equivalent of "did you mean to donate?" So last week, out of pure curiosity, I typed it.

What I got was a tree. Not a guilt trip, not a paywall — just a list of 12 packages I use every single day, each with a link to the human being who keeps it alive. Most of them I'd never heard of. A few I'd been taking for granted my entire career.

I picked five to look into. Here's what I found.

chalk — The One That Almost Died

chalk is the package that colors your terminal output. If you've ever seen a green "success" or a red "error" in a CLI tool, there's a good chance chalk did that. It's maintained by Sindre Sorhus and Josh Junon, and it's downloaded billions of times a week.

In September 2025, Josh Junon was phished. Attackers got his npm account and pushed malicious, crypto-stealing versions of chalk and 19 other packages within 16 minutes. Wiz later reported that 99% of cloud environments used at least one affected package. Sindre published clean versions and locked out the compromised access, but the incident exposed something uncomfortable: a package that critical is held together by two people, one of whom was targeted by a single email.

chalk is funded through GitHub Sponsors. The money covers CI, security review, and the kind of redundancy (multi-maintainer, hardware keys, 2FA on everything) that would have stopped that attack cold.

dayjs — 76 Million Downloads, One Maintainer

dayjs is a 2kB date library that replaced moment.js for a lot of people. It's maintained by a single person, iamkun, and it pulls in over 76 million downloads per week.

The math here is the part that stuck with me. One person. 76 million downloads. The funding page points to both GitHub Sponsors and Open Collective, but the sponsor list is a handful of small logos. For a package that touches more production systems than most companies employ engineers, the financial support is… thin. If iamkun stopped, the migration would be chaotic and expensive — exactly the kind of risk that's cheap to prevent and expensive to clean up.

zustand — The Quiet Workhorse

zustand is a state management library for React, part of the pmndrs organization. It has 41 million weekly downloads and three maintainers: daishi (Daishi Kato), jeremyrh, and drcmda.

What impressed me is how understated the whole thing is. No enterprise backing, no VC, no "we're the future of state management" pitch. Just a FUNDING.json file in the repo pointing to GitHub Sponsors. The library is small, fast, and has zero dependencies — the kind of thing you install and forget. But "forget" is the wrong word. The right word is "depend on," and depending on something you never think about is the highest-risk state a dependency can be in.

The One That Made Me Stop

Then there was the small one. Buried in the tree, a package called sewline — something I'd never even seen before, a tiny utility that one of my other dependencies pulled in transitively. No stars to speak of, no blog posts, no Twitter account. Just a funding field in package.json pointing to a GitHub Sponsors page with two sponsors.

Two people are paying for this. And it's in my production build.

I'm sponsoring sewline this month. Not because it's famous. Because it's small enough that two people leaving would break it, and big enough that I'd notice. That's the exact spot where a package is most fragile — not the 76-million-download giants with a team of sponsors, but the quiet ones in the middle of the tree that nobody looks at.

Try It Yourself

# 1. Run it in any project
npm fund

# 2. See it as JSON (easier to parse)
npm fund --json

# 3. Open a specific package's funding page in your browser
npm fund dayjs

# 4. If a package has multiple funding sources, pick one
npm fund dayjs --which 1

# 5. Suppress the install-time notice if it bothers you
npm config set fund false

Run it in your biggest project. Count the packages. Then pick the one you know the least about and look it up. That's where the risk is hiding.

AI Is Flooding curl with Low-Quality PRs — and the Maintainer Can't Keep Up

Bhargav Bhatt — Thu, 15 Oct 2026 16:13:49 +0000

Daniel Stenberg has maintained curl for over 30 years. It's the HTTP client embedded in nearly every operating system, router, and embedded device on Earth. And in January 2026, he did something he never expected to do: he shut down the project's bug bounty program — the one he'd run since 2019, the one that had confirmed 87 vulnerabilities and paid out over $100,000.

Not because the program failed. Because it was being DDoSed by AI.

The Numbers

Before the AI wave, curl received roughly one security report per week. The confirmed-vulnerability rate ran north of 15% — healthy, manageable, sustainable for a volunteer team.

Then LLMs made it trivial to generate a plausible-looking vulnerability report in seconds.

2024: The rate began climbing. Stenberg started tracking AI-assisted submissions.
Mid-2025: Volume spiked to 8× the normal rate. About 20% of submissions were AI slop. The confirmed rate plummeted to below 5%.
January 2026: In the first 21 days alone, curl received 20 AI-generated vulnerability reports. Seven arrived in a single 16-hour window.
June 2026: The pace hit one report every 18 hours — 4–5× the 2024 rate, double the 2025 pace.

And here's the part that should make you uncomfortable: in six years of tracking AI-generated reports, not a single one — zero — discovered a genuine vulnerability on its own.

The signal went down. The volume went up. That's the worst possible combination for an unpaid security team.

The Hidden Cost Nobody Sees

Stenberg describes the toll as "primarily mental." His wife has voiced concerns about his work hours for the first time in his life.

Each AI-generated report isn't just "read and dismiss." It's:

Read a 2,000-word report with confident, overly polite language and zero substance.
Reproduce the claimed vulnerability (or prove it doesn't exist).
Trace the code path to confirm or debunk.
Write back with an explanation, because that's what you do.

A single debunk can take hours. Multiply that by 20 reports in three weeks, and you've lost a month of security review capacity — capacity that was already stretched across 12 confirmed CVEs pending and a projected 30+ for 2026.

And the slop is getting better. In early 2025, most AI reports were hallucinated — they referenced functions that didn't exist. By 2026, the models improved. The reports are now technically accurate, which means they take longer to debunk, not shorter. Stenberg called it "high-quality chaos."

The irony is not lost on anyone: AI made finding and reporting vulnerabilities dramatically cheaper. Triage remains expensive human work. The cost was transferred entirely to the maintainer.

This Is a Funding Problem, Not a Tooling Problem

The obvious response is "build a better filter." Rate-limit AI submissions. Add a CAPTCHA. Require a proof-of-concept video. GitHub is literally considering a PR kill switch because ~14% of all pull requests on the platform now involve AI tooling, and ~17 million robot PRs land per month.

But filters are a band-aid on a structural problem.

The real issue: AI collapsed the cost of producing a security report to near zero, while the cost of verifying it stayed the same. Every project with a bug bounty, a public issue tracker, or a security@ email address is now a target. curl just happened to have the most visible one.

Stenberg's solution — killing the bounty — removes the financial incentive for slop. But it also removes the incentive for good researchers. The 87 confirmed vulnerabilities and $100K in payouts were real security value. You can't have one without the other, and you can't triage the difference without funded human attention.

A funded maintainer can:

Hire a part-time security triage engineer to handle the first pass, filter the obvious slop, and route only credible reports to Stenberg.
Invest in automated triage tooling — not to replace human judgment, but to reduce the "read and dismiss" cycle from hours to minutes.
Fund community management — clear contribution guidelines, response templates, and a public "AI slop" catalog (which Stenberg already maintains as a gist) so submitters self-correct before they waste anyone's time.

None of that is possible on goodwill and weekends.

What You Can Do

Stenberg's position on AI-generated code is pragmatic: "I don't want to read your AI explanation. I want to read your human explanation of why you'd need that code, and then you can write the code however you want."

The same principle applies to funding. You don't need to be a security researcher to help. You need to be a person who uses curl — which, if you've ever made an HTTP request, you are.

Sponsor the maintainer. curl doesn't have a traditional GitHub Sponsors page, but the Sovereign Tech Fund model (which backed FFmpeg) shows that structured, recurring funding works. If you work at a company that ships curl in production, write a one-paragraph memo to your CTO: "We depend on curl. Its bug bounty was shut down because AI slop made triage unsustainable. Here's what a part-time security reviewer costs. Here's what a curl outage costs."

If you're a security researcher: file better reports. Include a reproducer. Scope your findings. Acknowledge AI assistance. A report that costs a maintainer minutes instead of hours is a gift.

If you're a platform: GitHub, HackerOne, Bugcrowd — the friction on the submission side needs to scale with volume. Rate limits, proof-of-work, signal requirements (Node.js already implemented one). The cost of producing a report can't be zero while the cost of verifying it stays the same.

curl didn't break. It's still the most battle-tested HTTP client in existence. But the person keeping it safe is one exhausted human, and the flood isn't slowing down.

The next project to shut down its security program won't have 30 years of track record to fall back on.

The Day FFmpeg Stopped: A Post-Mortem That Could Happen to You

Bhargav Bhatt — Thu, 15 Oct 2026 16:04:28 +0000

It's 2:47 AM on a Tuesday. Your on-call pager goes off. A customer reports that their video transcoding pipeline is producing corrupted output — and then, minutes later, a security alert: a heap out-of-bounds write in the MagicYUV decoder of the library that powers your entire media stack.

You check the CVE. CVE-2026-8461, nicknamed PixelSmash, CVSS 8.8. It's in libavcodec — the core decode/encode library of FFmpeg. Every application that links libavcodec is affected: VLC, Chrome, AWS Elemental, Jellyfin, Kodi, Plex, and thousands of embedded devices.

This isn't hypothetical. It happened.

What Broke

In mid-2026, researchers at JFrog discovered a single rounding mismatch in the MagicYUV decoder — a codec used in high-performance video editing workflows. The flaw allowed a crafted video file to trigger a heap out-of-bounds write, crashing any application that processed it. In the worst case, it enabled remote code execution.

The kill chain was trivial: an attacker sends a victim a .avi file. The victim's file manager generates a thumbnail. The system is compromised. No click required.

The fix landed in FFmpeg 8.1.2. But the patch wasn't the story. The story was who wrote it, how long it took, and who paid for it.

The Chain: From Bug to Patch

Who noticed: JFrog's security research team, using their own tooling. Not a volunteer maintainer. Not a community member. A company with a dedicated security budget.

How long it took: The vulnerability existed in FFmpeg's codebase for an undisclosed period before JFrog identified it. The patch shipped in 8.1.2, but the triage, reproduction, and fix consumed maintainer time that was already stretched thin.

Who paid for the fix: No one. Not directly. The maintainers who reviewed, tested, and merged the patch were working for free. Germany's Sovereign Tech Fund had provided €157,580 for 2024–2025 — FFmpeg's first governmental sponsorship. That's roughly the cost of one senior engineer's salary per year, spread across a codebase that handles video for billions of people.

Meanwhile, Microsoft had previously been asked for a long-term support contract. Their response: a one-time payment of a few thousand dollars.

Why the Funding Model Made This Possible

FFmpeg is maintained by a small group of volunteers working on weekends and caffeine. The project's own account described one of its largest corporate dependents as a "trillion-dollar corporation" — and the dispute in November 2025 made the imbalance public.

Google's AI-powered security tools began flooding FFmpeg with automated vulnerability reports. The maintainers called it "CVE slop" — a constant swell of low-severity findings, each treated with the same urgency as a critical flaw, each demanding triage time from unpaid humans.

A former Amazon engineer put it plainly:

"I spent about a week a year at my time at @amazon preventing us from accidentally f*ing over @FFmpeg. I usually had to start each conversation with 'They are not a vendor, there is no NDA, we have no leverage, your VP has refused to help fund them, and they could kill…'"

The structural problem: corporate users treat FFmpeg as a vendor — demanding SLAs, security patches, and responsiveness — while refusing to pay for any of it. The XZ Utils backdoor of 2024 (CVE-2024-3094) proved what happens when a single exhausted maintainer becomes an attack surface. FFmpeg is closer to that edge than most people realize.

In 2026, an AI agent from Depthfirst autonomously found 21 previously unknown FFmpeg vulnerabilities. Anthropic's Mythos Preview identified a 16-year-old H.264 bug. The volume of automated findings is outpacing the capacity of unpaid maintainers to triage them.

Cost of Inaction

Metric	Number
FFmpeg's total governmental funding (2024–2025)	€157,580
Estimated cost of one senior C/assembly engineer (EU)	€80,000–€120,000/year
CVEs assigned to FFmpeg in 2026 alone	10+ (and counting)
Downstream projects linking `libavcodec`	Hundreds
Platforms directly affected by PixelSmash	Chrome, VLC, AWS Elemental, Jellyfin, Kodi, Plex, embedded devices
Microsoft's "support" offer	A few thousand dollars, one-time
FFmpeg 9.0 release cycle	14 months, 2,300+ commits, 180 contributors

The math is simple: €157K does not cover one full-time maintainer, let alone the triage, security review, CI infrastructure, and documentation that keep a 30-year-old codebase running.

When the maintainers burn out, the next PixelSmash won't get a patch in a week. It'll get a patch in a quarter — or never. And the XZ backdoor showed that an unmaintained, exhausted project is a target, not just a risk.

Three Things You Can Do Today

1. Sponsor the maintainers.
FFmpeg doesn't use GitHub Sponsors in the traditional sense, but the Sovereign Tech Fund model shows that structured funding works. If you work at a company that depends on FFmpeg, advocate internally for a sponsorship budget. Even €500/month from five mid-size companies would fund a part-time security reviewer. Write to your CTO: "We use FFmpeg in production. Here's the CVE history. Here's what it costs to help keep it alive."

2. Contribute triage, not just reports.
The scarce resource is never bug discovery — it's the human attention needed to assess, reproduce, prioritize, and fix. If you file a bug, include a reproducer, a scope assessment, and a proposed patch. A report that costs a maintainer minutes instead of hours is a gift.

3. Advocate internally.
If you're an engineering manager or CTO, add FFmpeg (and your other critical dependencies) to your SBOM and your risk register. Treat them as critical infrastructure, not free utilities. The OpenSSF's enterprise commitment exists for this exact reason. A one-paragraph memo to your leadership — "We depend on FFmpeg. It's underfunded. Here's the PixelSmash incident. Here's what we'd be paying a vendor for the same SLA." — is the cheapest security investment you'll make this year.

FFmpeg didn't stop. Not yet. But the gap between what it does for the internet and what it receives in return is the single most underpriced dependency in modern software. The next CVE won't wait for a funding round to close.

🎙️ Building UdharBhai: A WhatsApp-First Gujarati Voice "Udhar Khata" Bot in 1 Day

Bhargav Bhatt — Tue, 13 Oct 2026 11:22:35 +0000

TL;DR: App-based credit books (Khatabook, OkCredit) fail for rural and tier-2/3 Indian merchants because of digital literacy barriers. We built UdharBhai (ઉધરભાઈ)—a zero-app WhatsApp bot that takes Gujarati voice notes ("Ramesh 500 udhar diyo"), parses financial intents via Sarvam AI + LLMs, updates a Supabase PostgreSQL ledger, and triggers WhatsApp payment reminders with dynamic UPI deep links.

💡 The Market Gap: App Fatigue in Tier-2/3 India

India’s local merchant economy runs on informal credit (Udhar). Existing fintech unicorns built sleek native apps (Khatabook, OkCredit, Bahi Khata) to digitize these ledgers.

However, there is a fundamental friction point: The shopkeeper and the customer already live on WhatsApp.

Forcing a local kirana shop owner to download a separate 50MB Android app, navigate complex UIs, and type in English/Hindi creates immediate churn.

The Solution: "Voice-In → WhatsApp-Out"

Zero App Downloads: The shopkeeper simply sends a WhatsApp voice note in natural spoken Gujarati.
Instant NLU: The voice note is transcribed, parsed into an atomic transaction, and logged in PostgreSQL.
Automated Reminders: The customer receives a WhatsApp nudge containing a clickable UPI link (upi://pay?pa=...).

🏛️ System Architecture

Here is the high-level data pipeline powering UdharBhai:

[Shopkeeper WhatsApp Voice Note]
         │
         ▼ (Webhook Payload)
┌─────────────────────────────────┐
│ Express / TypeScript Gateway    │
└────────┬────────────────────────┘
         │
         ├─► Audio Stream ──► [Sarvam AI Saaras v4] ──► Gujarati Text
         │
         ▼
┌─────────────────────────────────────────────────────────────────┐
│ NLU Engine (Groq / Llama 3.3 Versatile)                         │
│ - Spoken Gujarati Numeral Normalization                         │
│ - Honorific Stripping ('bhai', 'kaka', 'seth')                   │
│ - JSON Extraction: { intent, customer_name, amount }            │
└────────┬────────────────────────────────────────────────────────┘
         │
         ▼
┌─────────────────────────────────────────────────────────────────┐
│ Supabase PostgreSQL                                             │
│ - Atomic balance mutation                                       │
│ - Ledger entry insertion                                        │
└────────┬────────────────────────────────────────────────────────┘
         │
         └─► Dynamic UPI Link Generation + WhatsApp Response Dispatch

🛠️ Key Technical Highlights

1. Regional Speech-to-Text via Sarvam AI

Whisper and generic cloud STT engines often struggle with regional Indian dialects and vernacular speech patterns. We integrated Sarvam AI (saaras:v4), optimized for Indian languages:

import axios from 'axios';
import FormData from 'form-data';

export async function transcribeAudioBuffer(audioBuffer: Buffer): Promise<string> {
  const formData = new FormData();
  formData.append('file', audioBuffer, 'audio.ogg');
  formData.append('model', 'saaras:v4');
  formData.append('mode', 'transcribe');
  formData.append('language_code', 'gu-IN');

  const response = await axios.post('https://api.sarvam.ai/speech-to-text', formData, {
    headers: {
      'api-subscription-key': process.env.SARVAM_API_KEY!,
      ...formData.getHeaders()
    }
  });

  return response.data.transcript || '';
}

2. Gujarati Financial NLU & Numeral Normalization

Gujarati speech includes conversational numbers like "Pandarsau" (1,500) or "Dedh So" (150). We pass the transcribed text to an LLM with strict JSON schema constraints:

export async function parseGujaratiInput(input: string): Promise<ParsedIntent> {
  const systemPrompt = `You are a Gujarati financial transaction extraction engine for "UdharBhai".
Parse the input and extract structured json.

Examples:
- "Ramesh 500 udhar diyo" -> {"intent": "UDHAR", "customer_name": "Ramesh", "amount": 500}
- "Patel 200 jama mili" -> {"intent": "JAMA", "customer_name": "Patel", "amount": 200}
- "Ramesh nu ketlu baki che?" -> {"intent": "QUERY_SINGLE", "customer_name": "Ramesh"}

Rules:
- Convert Gujarati numbers (e.g., pandarsau -> 1500, dedh so -> 150).
- Strip honorifics like 'bhai', 'kaka', 'seth' from customer_name.
- Output ONLY valid JSON: {"intent": "UDHAR"|"JAMA"|"QUERY_SINGLE"|"QUERY_ALL"|"UNKNOWN", "customer_name"?: string, "amount"?: number}`;

  const response = await axios.post(
    'https://api.groq.com/openai/v1/chat/completions',
    {
      model: 'llama-3.3-70b-versatile',
      messages: [
        { role: 'system', content: systemPrompt },
        { role: 'user', content: input }
      ],
      response_format: { type: 'json_object' }
    },
    { headers: { Authorization: `Bearer ${process.env.GROQ_API_KEY}` } }
  );

  return JSON.parse(response.data.choices[0].message.content);
}

3. Atomic Database Operations (Supabase)

To prevent race conditions during concurrent voice logging, ledger writes and customer balance updates execute inside atomic transactions:

export async function recordTransaction(shopId: string, customerName: string, amount: number, type: 'UDHAR' | 'JAMA') {
  // Get or create customer record
  let { data: customer } = await supabase.from('customers').select('*').eq('shop_id', shopId).ilike('name', customerName).single();

  if (!customer) {
    const { data: newCust } = await supabase.from('customers').insert([{ shop_id: shopId, name: customerName, total_balance: 0 }]).select().single();
    customer = newCust;
  }

  // Insert immutable ledger log
  await supabase.from('ledger_entries').insert([{ shop_id: shopId, customer_id: customer.id, type, amount }]);

  // Atomic balance calculation
  const balanceChange = type === 'UDHAR' ? amount : -amount;
  const newBalance = Number(customer.total_balance) + balanceChange;

  await supabase.from('customers').update({ total_balance: newBalance }).eq('id', customer.id);

  return { customerName: customer.name, newBalance };
}

4. Dynamic UPI Deep Link Construction

When sending WhatsApp reminders to debt holders, we construct NPCI-compliant UPI deep links:

export function generateUpiLink(upiId: string, shopName: string, amount: number): string {
  const note = encodeURIComponent(`Udhar payment - ${shopName}`);
  const encodedShop = encodeURIComponent(shopName);
  return `upi://pay?pa=${upiId}&pn=${encodedShop}&am=${amount}&tn=${note}&cu=INR`;
}

🚀 The Viral Loop Growth Model

UdharBhai incorporates a built-in organic growth engine:

Shopkeeper logs credit for a customer via voice note.
The bot auto-sends a WhatsApp reminder to the customer:

"Namaste Ramesh bhai! 🙏 Patel General Store par 500₹ udhar che. UPI se bhugtan kare: [UPI Link]"
At the bottom of the notification, a subtle footer tag reads:

"⚡ Aa khata book UdharBhai par chale che. Tamara dukan mate try karo: [WhatsApp Link]"

Because debt holders in local trading clusters are frequently merchants or traders themselves, every collection reminder double-hats as a direct customer acquisition channel—achieving near zero CAC (Customer Acquisition Cost).

📦 Try It Out / Contribute

UdharBhai is completely open-source! Check out the codebase, set up your own regional voice bot, or help us add support for additional Indian regional languages (Hindi, Marathi, Marwari).

👉 GitHub Repository: github.com/bhkbdbhatt/udharbhai

Suggested Tags

#typescript #nodejs #ai #whatsapp #buildinpublic

DEV Community: Bhargav Bhatt

The Protocol That Connects Your AI to Everything Is Also Letting Attackers In

The Hook

The Miasma Worm: When Your AI Tool Is the Payload

The STDIO Flaw: "By Design" Is Not a Security Posture

The Exposed Server Problem: 1,467 and Counting

The Trust Model Is Broken: One Click, Full RCE

The Fresh One: Splunk's MCP Server Gets a 9.1

The Structural Problem

What This Means for You

Discussion

Black October: The Week the Internet Almost Broke Itself

The Hook

PHP2Shell: The 70% Problem

SBI: 3,897 Records and a Bigger Question

The Wider Black October: A Supply Chain Meltdown

What This Means for You

Discussion

I Spent a Weekend Migrating My MCP Server to the New Spec. Here's What Hurts.

The Big Shift (In One Paragraph)

What I Actually Had to Change

First: I deleted my session store

Second: The "server asks you a question" pattern is different

Third: I stopped using initialize

Fourth: I added ttlMs to my list endpoints

What I'm Deprecating (And Why)

What I Wish I'd Known Before Starting

What I'm Still Figuring Out

The TL;DR I Wish I'd Read First

The BUILD Foundation Just Launched — Here's Why Bazel Users Should Care (Even If You're Not at Google)

What Happened

What They're Actually Funding

Why This Matters for You (Even If You Don't Use Bazel)

The Bigger Picture

TL;DR

Tracking CNCF Projects: A Beginner's Guide to Contribution & Velocity Metrics

1. DevStats — The Core Tool

Running DevStats Locally (Quick Start)

Running via Helm on Kubernetes

Running Reports

2. Velocity — Growth Over Time

3. LFX Insights — Per-Project Health

4. The Landscape — Ecosystem Map

5. Maturity Levels — Why the Numbers Matter

Quick Reference

I Replaced runc with a Rust Container Runtime (youki) for a Week

The Boring Layer That Matters Most

What Is youki?

The Benchmarks (Honest Version)

Setup: Replacing runc on a K8s Node

Prerequisites

Step 1: Build youki

Step 2: Register with containerd

Step 3: Create a RuntimeClass

Step 4: Run a Pod with youki

Step 5: Run It for a Week (What I Noticed)

youki vs. runc vs. crun: Where Each Wins

The Wasm Angle (Why This Matters More Than You Think)

What's Missing (and Where Funding Helps)

TL;DR

Final Thought

Running WASM on Kubernetes with SpinKube: A Hands-On Guide

The Problem With Container Cold Starts

What Is SpinKube?

Architecture at a Glance

Prerequisites

Step 1: Install SpinKube on Your Cluster

Step 2: Build a Spin App

Step 3: Deploy to Kubernetes

Step 4: Verify It Works

Step 5: Scale It (The Fun Part)

Step 6: Observe It

Containers vs. Wasm on SpinKube: The Honest Comparison

When SpinKube Makes Sense (and When It Doesn't)

What's Missing (and Where Funding Helps)

TL;DR

7 AI Tools That Can Plan Your Entire Week in One Prompt

TL;DR

1. Motion — The "Set It and Forget It" Option

2. Reclaim.ai — The Focus-Time Bodyguard

Third: I stopped using `initialize`

Fourth: I added `ttlMs` to my list endpoints