Engineering · June 2026

We Broke KNative at 7,000 Apps. Here's What We Built Instead.

The page you're reading is served by software that didn't exist three months ago. We built it in three weeks, with two engineers and a lot of AI. This is that story.

The story begins

Summer 2025. Kineto ships its first version. The idea was simple: describe an app, AI generates and deploys it — instantly, with its own URL. The infrastructure was equally clean. We picked KNative on Kubernetes: each generated app gets its own Knative service, its own subdomain, its own lifecycle. Scale to zero on idle. Spin up on demand.

Promising. Very promising.

The issue

At 1,000+ apps, things got less smooth.

Cold starts started creeping — 15 seconds became 20, became 30. The scale-to-zero promise quietly collapsed, because a 30-second cold start means users complain, which means you keep everything warm. We weren't doing serverless anymore. We were running containers with extra steps and extra waiting.

The fix that almost worked

We dug in. Istio — the default KNative networking layer — was heavy. We migrated to net-kourier, a lighter router. Cold starts dropped to 10–15 seconds. Morale recovered. We shipped the migration across 7,000+ apps.

Then net-kourier's internal controller refused to start.

Not a graceful degradation. Not a partial failure. A hard, flat no — it couldn't build its routing state at that scale. Users noticed. We scrambled. We rolled back.

Then we sat in the quiet and had the conversation we'd been avoiding: we're doing the right thing with the wrong tool.

No more promises

We spent a couple of weeks looking for the next platform. Something that promised to run thousands of small, mostly-idle Node apps with fast cold starts and real isolation.

There wasn't one. Not for our shape of problem. Everything either came with the same scaling assumptions we'd just been burned by, or required compromises we weren't willing to make.

The bus stop

One of us was heading home after yoga, waiting at a bus stop, talking to Gemini about the problem. Deno Deploy came up.

Something clicked.

The insight wasn't complicated: what if each pod hosts many apps instead of one? Instead of 7,000 Knative services — a handful of pods, each running dozens of isolated apps. Deno gives process-level isolation. Go gives fast routing. cgroups gives resource control at the pod level.

We didn't need another platform. We needed to build the platform.

Knapp, the rise

Two engineers. Three weeks. AI doing the heavy lifting — and by heavy lifting, we mean roughly 90% of the code written agentic-first. That's not a rounding error; it's a deliberate way of working, and it's the reason the timeline was three weeks and not three months.

The result was Knapp — Kineto Application Platform. Each pod runs a knapp-host: a Go reverse proxy that spins up isolated Deno processes on demand and routes traffic by app ID. In front of them sits knapp-gateway: a stateless router using rendezvous hashing so the same app always hits the same host, with no coordination overhead.

The prototype worked. Then dev worked. Then production worked.

The punchline

We used AI to build the platform that runs AI-generated apps. We're not sure if that's ironic or just efficient. Probably both.

Knapp is in production and it's the infrastructure underneath every app we run. And if you're reading this on our blog — yes, it's being served by Knapp right now.

Next?

A year ago, "let's build our own serverless platform" in a two-person team was a planning failure. Not because we lacked the skill — because the cost of being wrong was measured in months. Now it's measured in days. The prototype either works in a week, or you revert and try something else. Knapp worked. We shipped it.

We've since pivoted toward Kinetik — our messenger-first AI agent — but Knapp runs underneath every app. The infrastructure we needed didn't exist, so we built it in three weeks and it's been running ever since.