Northflank vs bex: Same Kubernetes-Native Pitch, Opposite Answers to Who Owns What

Northflank and bex make the same promise from opposite sides of a wall: git-push deploys with real Kubernetes underneath, no YAML-operating required. The wall is the control plane. Northflank operates a closed-source one as SaaS and meters you for it; bex ships you an Apache-2.0 one and gets out of the billing path entirely. Everything else in this comparison — the bill, the data, the uptime discipline — falls out of that single difference.

If you only read one table, read this one:

The rest of this post puts numbers and specifics behind each row, fairly enough that a team could pick either side for the right reasons.

Where they genuinely overlap​

Start with the honest part: the shared pitch is real, not marketing coincidence. Both platforms give developers the Render/Heroku-shaped workflow — connect a repo, push, get a running HTTPS service — with actual Kubernetes orchestration underneath rather than a single-box Docker daemon with a nice UI. Both handle preview environments, managed datastores, background jobs, and autoscaling without asking the developer to learn the orchestrator.

Northflank has spent 2026 saying exactly this from its own blog, publishing teardown-style comparisons against Railway, Render, Fly.io, and Coolify/Dokploy that all argue the same thesis: the single-box and proprietary-runtime PaaS options hit a ceiling, and Kubernetes-native orchestration with per-second metering is the grown-up answer. That positioning is why this comparison is worth writing precisely: Northflank's content frames the decision as which managed platform, and never gets to the question a team running real workloads eventually asks — what changes when the platform software itself is something you can run?

That is the actual fork. Northflank is closed-source SaaS in every mode it sells. Even BYOC — where Northflank provisions a cluster inside your AWS, GCP, Azure, or bare-metal account — leaves Northflank operating the control plane and charging a platform fee on top of your cloud list costs. bex is Apache-2.0 software: one Go operator reconciling an App CRD into Deployments, Services, Ingress, and TLS, deployable on a local Docker-backed cluster or a Hetzner fleet with only the Cluster API provider overlay changing. Same git-push shape. Opposite answer to "what am I renting?"

The bill, worked line by line​

Northflank publishes its metered rates, so this side of the comparison is arithmetic, not vibes: $0.01667 per vCPU-hour and $0.00833 per GB-hour, billed per second, plus $0.15 per GB-month for SSD and $0.06 per GB of egress. No per-seat fees. Take a concrete always-on small-team workload for a 730-hour month:

• API service, 1 vCPU / 2 GB: $12.17 compute + $12.16 memory = $24.33
• Background worker, 0.5 vCPU / 1 GB: $6.08 + $6.08 = $12.16
• Postgres, 1 vCPU / 2 GB + 20 GB SSD: $24.33 + $3.00 storage = $27.33
• Redis, 0.2 vCPU / 512 MB: $2.43 + $3.04 = $5.47
• Egress, 100 GB: $6.00

Total: about $75/month, and every line item scales with allocation. Double the API to handle growth and the meter roughly doubles with it. That is the honest shape of per-second billing: it prices exactly what you provisioned, including the headroom you provisioned for traffic that hasn't arrived yet.

Now the same four workloads on one flat-rate owned box running bex — the kind of Hetzner-class machine in the roughly $20/month tier of the post-2026-hike catalog. (Hetzner repriced twice in 2026, so check the buyable tier rather than anyone's remembered price; the structural point survives any specific SKU.) The workloads bin-pack onto one machine alongside the control plane, and the monthly number doesn't move when you double the API's replica count within the box's headroom. Same workloads, roughly $20 flat versus $75 metered — a 3.7x gap that widens every time the team grows into headroom the meter would have charged for from day one.

Sensitivity matters more than either point estimate. The meter wins in exactly one shape: workloads that are genuinely intermittent and small — a staging API that idles 20 hours a day, preview environments that live for hours. Northflank's own framing concedes the mirror image: consistent usage favors flat capacity. And there is a line item you cannot price from public information at all: the BYOC/BYOK platform fee. Northflank publishes the Managed meter down to the fifth decimal but not what it charges to operate the control plane over your cloud account or your existing cluster — that number requires a sales conversation, which means the mode that most resembles self-hosting is also the mode whose premium you can't put in a spreadsheet.

The data: whose cloud, whose metadata​

The bill decides the budget conversation; data residency decides the compliance one, and here the modes matter more than the marketing. On Northflank Managed, everything — workloads, databases, logs, secrets — sits on Northflank's infrastructure. BYOC moves the workloads, data, and secrets into your VPC, which satisfies the "customer data stays in our account" requirement. But the orchestration metadata still flows to Northflank's control plane: the closed-source coordinator that schedules, deploys, and observes your estate lives outside your boundary in every mode except the sales-gated forward-deployed enterprise tier.

That is a coherent enterprise story — a SOC 2-ready posture with RBAC, audit logs, and SAML out of the box — and for many teams it clears every review. It is not the same as running the software yourself. You cannot read the control plane's source, fork it, pin it, or run it air-gapped. If Northflank changes a behavior, a price, or a deprecation timeline, your recourse is a support ticket and a contract, not a pull request.

bex inverts all of that because there is no vendor-operated component in the self-hosted path. The control-plane store, the API, the dashboard, the MCP server your agents call — all of it runs on machines you own, under a license that permits reading, forking, and modifying everything. The audit story is "here is the source and here are our machines" rather than "here is our vendor's attestation." The tradeoff is symmetric and worth stating plainly: you inherit every operational burden the SaaS was carrying — upgrades, backups, secret rotation, incident response — and bex's docs say so rather than hand-waving it.

For agent-operated fleets there is a sharper version of the same question. An agent that deploys through Northflank's API is operating infrastructure through a vendor's control plane with vendor-side audit. An agent operating bex through its MCP server is touching machines you own, with logs you hold. Which one your security review prefers depends on whether it trusts vendor attestations or owned infrastructure more — but only one of the two lets the agent's entire operational footprint stay inside your boundary.

The uptime discipline: who gets paged​

This is the section where Northflank wins today, and a fair comparison says so. Northflank reports 99.99% historical uptime and backs enterprise agreements with an SLA carrying service credits. When the control plane has a bad day, Northflank's engineers get paged, and your recourse is contractual. For a team with no platform engineer and a product launch next quarter, that sentence can outweigh everything above it.

bex's side of the row is shorter and less comfortable: public alpha, no SLA, and upstream guidance that doesn't recommend it for production workloads yet. You own upgrades, you own the paging rotation, you own the postmortems. The project's own docs scope evaluations carefully — compatibility checked per operation, known gaps listed — which is the right posture for alpha software and exactly the wrong thing to hear if you needed someone to yell at during an outage.

Weight this row by team shape, not by ideology. A two-person startup shipping its first paid tier should probably rent the SLA and revisit the question at scale; the $55/month meter premium is noise next to one engineer's salary. A platform team already operating Kubernetes, already carrying a pager, and already paying a metered bill in the thousands is paying the premium for an SLA layered over infrastructure it could operate — that team should price the buyback. The mistake is letting either answer feel universal. Uptime discipline is a staffing question wearing a vendor question's clothes.

Decision checklist​

If the three rows above feel abstract, here is the same comparison as rules:

• If customer data must stay in your account but a vendor control plane is acceptable, Northflank BYOC is the lowest-effort compliant answer — but get the platform fee in writing before you model the year.
• If the bill already exceeds one engineer's week per month in toil-equivalent, price the owned box. Metered convenience has a breakeven point and it arrives earlier than teams expect.
• If you need source access, air-gap operation, or fork-level control, only bex qualifies. No SaaS mode, however VPC-adjacent, is a substitute for the source.
• If you have no one to carry a pager, rent Northflank's SLA today. Revisit when uptime discipline exists in-house regardless of vendor.
• If agents are first-class operators, prefer the platform whose entire operational surface — API, logs, control plane — lives where your agents' audit trail does.

One migration note: the paths are asymmetric. Moving from Northflank Managed to bex means re-platforming onto machines you provision — real work, eased by the fact that both sides speak Kubernetes and container images underneath. Moving from bex to Northflank BYOK is closer to a handoff: import the cluster you already run and let their control plane take the pager. Starting on owned infrastructure keeps both doors open; starting on Managed keeps one.

Kubernetes-native was never the decision​

Strip this comparison to its mechanism and the lesson generalizes past either vendor. "Kubernetes-native" describes the orchestration substrate — a real and meaningful upgrade over single-box Docker for anything past a side project — but it answers none of the three questions that determine a platform relationship: who meters the bill, who holds the data and metadata, and who gets paged. Northflank's 2026 comparison content is genuinely useful within the managed-platform frame and structurally incapable of stepping outside it, because the vendor writing it is itself a meter.

The migrating team's real question was never which dashboard is prettier. It is whether the platform is a supplier or a dependency: a bill you can recompute against hardware you could own, data you can point to on machines you control, and an uptime story that names its owner honestly. Get those three answers in writing — from the pricing page, the architecture doc, and the status page history — and the Kubernetes underneath can be nearly identical while the platforms diverge completely.

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.