Northflank's Vibe-Coding Playbook Has Four Stages. bex Only Ships Two of Them by Default

A Supabase key sitting in Moltbook's client-side JavaScript is the whole story of 2026 in one line: the AI wrote working code, and nobody added the one row-level-security policy that would have kept it from handing out full read/write access to 1.5 million API tokens and 35,000 email addresses. Wiz found it in hours. The founder had said, accurately, that he hadn't written a single line of code himself.

That gap — between "the AI produced a working app" and "the app is safe to run in production" — is what Northflank's 2026 enterprise vibe-coding guidance is actually about. Strip the marketing framing and it reduces to four jobs a platform has to do to an AI-generated app before it's allowed near real users: audit what the model actually built, harden the infrastructure the app leans on, observe what it does once it's live, and sandbox the code that runs at runtime. This post works through what each of those four stages concretely requires, then checks bex — the Cluster-API-based, deploy-from-chat PaaS this blog belongs to — against all four. Two are close to platform defaults already. Two are not, and the evidence for that is sitting in this repo's own bex.yml.

The four stages, concretely​

Northflank doesn't publish this as a single named "four-step framework" — it's spread across an eight-control checklist for enterprise deployment and a ten-item pre-ship list for shipping vibe-coded apps safely. But every item in both lists falls cleanly into one of four buckets, and that's the useful way to read it:

The reason this framing exists at all is that the failure mode isn't hypothetical. Veracode tested code from over 100 LLMs across four languages and found 45% of the samples failed security tests and introduced an OWASP Top 10 vulnerability — the models write more functional code every generation, but "security performance remained flat, regardless of model size or training sophistication."

Georgia Tech's Vibe Security Radar project tracked the consequence in real time: 6 confirmed CVEs attributable to AI coding tools in January 2026, 15 in February, 35 in March — a near-sixfold jump in two months, with researchers estimating the true count across public repos runs 5–10x higher than what's been confirmed. A separate Escape.tech scan of 1,400 vibe-coded applications found 2,038 highly critical vulnerabilities, 400+ leaked secrets, and 175 instances of exposed PII. None of that is a code-quality problem a platform can fix — it's an infrastructure-layer problem, which is exactly why the four stages above are about what surrounds the code, not the code itself.

What "ships by default" actually means​

The distinction that matters for a deploy-from-chat PaaS isn't whether a control exists somewhere in the docs — it's whether a tenant gets it by doing nothing, or has to go build it themselves. Concretely: a secrets manager that a tenant has to provision, wire credentials into, and remember to reference correctly is homework. A bex.yml manifest where declaring an app automatically gets scoped, rotated database credentials with no extra field to fill in is a default. An audit log a tenant has to stand up their own Elasticsearch cluster to receive is homework. One that exists the moment the first git push lands is a default.

This distinction matters more for a platform whose whole pitch is that an AI agent — not a human who reads the docs once and remembers — is the one calling the deploy API. An agent doesn't skim a security checklist and decide to enable RBAC. It calls the API surface it's given, and whatever isn't a default simply doesn't happen.

Sandbox: real, but coarser than the microVM story​

Every bex deployment already runs on a real Cluster API fleet — HCloudMachine objects for Hetzner Cloud capacity, or HetznerBareMetalHost/HetznerBareMetalMachine pairs for dedicated servers, with a MachineHealthCheck watching every node and Kubernetes' own eviction machinery rescheduling workloads off anything that stops responding. That gives every tenant's app a real isolation boundary by default: it's scheduled, namespaced, and cgroup-bounded by Kubernetes, on infrastructure the platform — not the tenant — provisions and repairs.

That's a genuine sandbox stage, but it's a coarser one than Northflank's checklist is describing. The isolation bex ships today is standard container isolation via containerd or CRI-O — the same node can run multiple tenants' workloads side by side, separated by namespaces and cgroups, not by a microVM per execution. Northflank's sandbox item is specifically about the case where an AI agent's own generated code executes arbitrary logic at runtime — a chatbot evaluating user input, an agent-built service calling out to a tool — where a process escape has to be caught by something stronger than a container boundary.

bex's Cluster API layer solves "which node is my app on and does it survive a hardware failure," which is a different, real problem from "can one tenant's untrusted runtime code reach another tenant's process on the same node." The first is a platform default today. The second isn't yet — it needs a RuntimeClass wired to gVisor or Kata for the specific case of executing agent-generated code, which is additive to, not replaced by, the fleet layer that already exists.

Harden and audit: what bex.yml actually has today​

Here's the concrete evidence, not an inference from architecture. This is the actual manifest schema this repo ships to deploy itself onto bex:

apps:
  - name: eden-cms-v2
    type: web
    image: eden-cms-v2:2af473569
    port: 3000
    replicas: 1
    healthCheckPath: /
    domains:
      - eden-cms-v2.onbex.co

Seven fields: name, type, image, port, replicas, health check path, domains. There is no field for a secrets reference, no field for a scoped database credential, no field for an RBAC role binding, and no field that gates a build behind a static-analysis or dependency-CVE check. None of that is missing by oversight — bex's own posts describe the developer surface as deliberately small: "no Deployment spec, no Ingress rule, no RBAC binding, no Helm values file ever crosses that surface." That's the right call for hiding Kubernetes' authoring complexity from a developer. It's a different question from whether the harden and audit controls that complexity was providing — scoped credentials, RBAC, a pre-ship CVE gate — still get applied automatically underneath, and today the manifest gives no evidence they do.

The same repo's own coverage of the secrets question treats picking a self-hosted secrets backend as a decision the operator makes, not a feature bex ships turnkey — "wiring a licensing-clean, multi-tenant secrets backend into your own fleet is exactly the kind of infrastructure decision worth owning." That's honest framing, but it's also the tell: if choosing and wiring a secrets backend is presented as the reader's job, secrets management isn't a bex default yet. Same story for audit: nothing in the bex.yml schema or the Render-compatible deploy API produces a scoped database credential automatically, and nothing gates a build on a dependency-CVE or static-analysis check before an image goes live. Of Northflank's four stages, these are the two where a tenant — or an agent deploying on a tenant's behalf — currently supplies the control itself, not the platform.

Observe: the stage nobody's shipped yet​

Observe is arguably the sharpest gap of the four, because it's the stage that matters specifically because the caller might be an agent instead of a human. Northflank's version is simple to state: every deployment, every secret access, every environment change logged with a timestamp and a user identity. Nothing in bex's current public surface — the Render-compatible API, the bex.yml manifest, the Cluster API fleet layer — produces that log today.

The case for shipping it isn't hypothetical. This blog's own coverage of deploy-intent prompts notes that "roll back payments" resolves differently depending on whether an environment is flagged production — which only works as a safety mechanism if there's a durable, identity-attributed record of which agent issued which call, not just a live API response. Without that log, a rollback an agent triggered and a rollback a human triggered are indistinguishable after the fact — exactly the condition that let a Replit agent wipe a production database during an explicit code freeze earlier this year, with nobody able to establish, in real time, who or what had just acted.

What shipping all four would take​

None of this is a gap that needs new infrastructure invented from scratch — Cluster API already gives bex the control-plane primitives (RBAC objects, admission webhooks, a reconciling API server) that the harden, audit, and observe stages need; they're just not yet exposed as manifest fields or wired into the build pipeline by default. Concretely: a secrets: block in bex.yml that provisions scoped, rotated credentials without the tenant touching a vault; a build-time gate that runs dependency and static-analysis checks before an image is promoted; and a durable, per-call audit log keyed to the identity — human or agent — that made the request. Sandbox needs one more thing layered on top of what's already there: a RuntimeClass option for the specific case of executing AI-generated code at runtime, distinct from the node-level isolation every deployment already gets.

The honest version of this post's headline: bex ships the fleet-management half of "safe by default" — the half that keeps a node failure from taking an app down — and still owes tenants the half that keeps an AI agent's own mistakes from taking a database down. Both halves are Kubernetes-native problems. Only one of them is solved.

Bex.co is the open-source, AI-native Render alternative — push a git repo, get a running HTTPS service on machines you own. Star the repo on GitHub or deploy your first app today.