Dora NodaOwnkube will run your app on a $30 single EC2 box or a multi-AZ EKS fleet behind the exact same dashboard — and the gap between those two buttons is roughly 4x per month before your app serves a single request. That gap is the honest price of dual-substrate flexibility, and this post puts real numbers on it.
The verdict up front: Ownkube's BYOC model gives you two cluster shapes in your own AWS account — K3s Starter (single EC2 instance, $0 platform fee, provisioned in about 5 minutes) and EKS Production (managed multi-AZ EKS with node autoscaling, $5/vCPU + $1/GB-RAM platform meter on requested resources, provisioned in about 10 minutes). For a typical small-production workload (~2 vCPU / 8 GB requested), Starter lands around $60/month all-in while Production lands around $260/month — and a single-substrate Cluster API fleet on Hetzner serves the same workload for roughly $10–20/month. The rest of this post shows the receipts, names every seam the shared API papers over, and gives you a rule for when "works on either" beats "works exactly the way I provisioned it."
What "same API, two substrates" concretely means
Ownkube is a git-push PaaS — connect a repo, get a live URL with managed Postgres, automatic TLS, logs, metrics, autoscaling, and one-click rollbacks. You can start on Ownkube-hosted compute with no cloud account at all. The dual-substrate story appears when you bring your own cloud: the same app moves into your own AWS account with the same dashboard, same workflow, and same observability, and you pay AWS directly for the infrastructure.
Architecturally, Ownkube acts as a control plane that sends configuration intent ("deploy this image, with these env vars, at this scale") into your AWS account, where your VPC, Kubernetes cluster, apps, and databases actually run. The rollout happens through a role Ownkube assumes in your account; application data, logs, and runtime state stay inside your VPC. AWS is supported today, with GCP and Azure on the roadmap.
The two shapes you can pick in the create-cluster wizard:
| K3s (Starter) | EKS (Production) | |
|---|---|---|
| Substrate | k3s on one EC2 instance | Managed EKS, multi-AZ |
| Ownkube platform fee | $0 — you pay AWS only | $5/vCPU + $1/GB RAM per month, metered per second on requested resources |
| Provision time | ~5 minutes | ~10 minutes |
| Starting sizes | t3.medium ~$30/mo → t3.2xlarge ~$240/mo | Wizard defaults: 8 vCPU / 16 GiB, autoscaling after that |
| Best for | Dev, staging, side projects, small production | Live traffic that needs HA and node autoscaling |
On first cluster creation Ownkube also does once-per-account setup (shared IAM roles, a regional S3 bucket for state), then builds a VPC, subnets, NAT, and security groups, provisions the control plane, and installs its platform components (deployment pipeline, public routing, TLS, metrics collection). That is a lot of AWS surface area the platform owns so you don't have to — and it is identical regardless of which shape you pick. The differences that remain are the ones no dashboard can hide, which is where the money goes.
The costed three-way: one workload, two sizes
Let's price a typical workload honestly: a small-production web app plus Postgres, requesting roughly 2 vCPU and 8 GB of RAM. Then we'll scale it to 8 vCPU / 16 GB (Ownkube's own EKS wizard default) to see how each option's cost moves with size. All figures are monthly, on-demand, single-region estimates — infrastructure plus platform fees plus the unavoidable AWS extras — so the totals are comparable even if your region or discounts shift them a little.
Workload A — ~2 vCPU / 8 GB requested:
| K3s Starter | EKS Production | CAPH fleet on Hetzner | |
|---|---|---|---|
| Compute | t3.large (2 vCPU / 8 GiB) ~$60 | 2 nodes across AZs ~$120 | 1 cloud VM (4 vCPU / 8 GB) ~$10 |
| Control plane | $0 (runs on the box) | $73 ($0.10/hr EKS fee) | $0 (runs on your nodes) |
| Platform meter | $0 | $18 ($5×2 vCPU + $1×8 GB, on requested) | $0 (no per-unit meter) |
| Network extras | ~$0 (single box, no NAT bill) | ~$50 (NAT gateway + NLB) | ~$0 (generous included traffic) |
| Total | ~$60/mo | ~$260/mo | ~$10–20/mo |
Workload B — 8 vCPU / 16 GB requested:
| K3s Starter | EKS Production | CAPH fleet on Hetzner | |
|---|---|---|---|
| Compute | t3.2xlarge (8 vCPU / 32 GiB) ~$240 | EC2 nodes ~$250 | 1 node (8 vCPU / 16 GB) ~$19, or 3 for HA ~$60 |
| Control plane | $0 | $73 | $0 |
| Platform meter | $0 | $56 ($5×8 vCPU + $1×16 GB) | $0 |
| Network extras | ~$0 | ~$50 | ~$0 |
| Total | ~$240/mo | ~$430/mo | ~$20–60/mo |
Three things fall out of these tables. First, the EKS control-plane fee ($73/month per cluster, flat) dominates small workloads and fades into the noise on large ones — the classic managed-Kubernetes shape. Second, the absolute gap between Starter and Production holds at roughly $200/month across both sizes (~$200 at workload A, ~$190 at workload B), but its composition shifts: at workload A it is mostly the $73 control plane plus network extras, while at workload B the platform meter itself ($56, up from $18) does more of the work — and the meter keeps climbing past 8 vCPU.
That last point hides a ceiling worth stating plainly: the Starter wizard's biggest box is t3.2xlarge, so past 8 vCPU the single-box path ends and EKS is the only Ownkube shape left. The meter becomes mandatory, not optional. Third, the single-substrate Hetzner leg is not in the same league on unit cost: a dedicated 8-core / 64 GB machine with NVMe lists at €49/month, and cloud VMs run roughly $10–20/month at these sizes — with no control-plane fee and no per-vCPU meter at all. At workload A, EKS Production costs about 4x K3s Starter and more than 10x a single Hetzner node; the ratio compresses to under 2x at workload B only because the flat $73 matters less against bigger compute.
One more cost line belongs here because it bites later: EKS Kubernetes versions get 14 months of standard support, after which the control-plane fee jumps from $0.10/hr to $0.60/hr — a 6x increase — until you upgrade. A fleet that drifts behind on upgrades doesn't just carry CVE risk; it carries a ~$435/month-per-cluster control plane. Ownkube's wizard lets you pick the Kubernetes version at creation, but the upgrade treadmill itself is inherent to the managed substrate, not something the shared API can abstract away.
The seam table: what the abstraction papers over
Same dashboard, same okctl, same deploy flow — but underneath, k3s-on-one-box and managed EKS are different systems, and the differences are app-visible. This is the table that matters more than the price table, because every row is both a behavior your workload can accidentally depend on and a test matrix someone pays for forever:
| Seam | K3s (Starter) | EKS (Production) |
|---|---|---|
| Control plane | Runs on the box; dies with it | AWS-managed, multi-AZ; $73/mo flat |
| Load balancer | Klipper ServiceLB (host-port based) | NLB/ALB via AWS LB Controller (hourly + capacity charges) |
| Storage | local-path-provisioner, node-local — data dies with the box | EBS CSI gp3 volumes — network-attached, AZ-bound |
| IAM | EC2 instance profile, one identity for everything | IRSA or Pod Identity per service account |
| Upgrades | Re-bootstrap the box | Managed control-plane upgrades + node rotation; 14-month support window, then $0.60/hr |
| Node lifecycle / autoscaling | None — scale vertically to a bigger instance | Autoscaling node groups that add/remove nodes |
| Availability | Single node, single AZ | Multi-AZ by construction |
Read that table as a migration-risk register. An app developed on Starter that writes to a local-path volume, assumes a single instance's filesystem, or leans on the instance profile's broad permissions will not behave the same on Production — not because Ownkube's API changed, but because the substrate did. The platform can unify the deploy verbs; it cannot unify what a volume means. Teams that treat "we'll start on Starter and flip to Production later" as free are buying the switch at the price of re-validating every row of this table under real traffic.
There is a mirror-image cost on the platform side, too: every feature Ownkube ships must be verified against two substrates with different failure modes. That test matrix is the permanent tax on dual-substrate flexibility, and it is paid in engineering time whether or not any single customer ever switches shapes.
What a single-substrate Cluster API fleet buys instead
The alternative is to own exactly one substrate end-to-end. A Cluster API fleet on Hetzner — provisioned with the CAPH infrastructure provider, clusterctl init --infrastructure hetzner — replaces the two-shapes matrix with one declarative machine lifecycle: Cluster, MachineDeployment, and MachineHealthCheck resources reconciled by controllers, the same CNI, the same storage story, and fleet-wide upgrades expressed as desired-state changes rather than per-shape runbooks. There is one load-balancer semantic, one volume semantic, one IAM model. An app validated once is validated everywhere in the fleet, because everywhere in the fleet is the same machine.
What that uniformity buys concretely:
- One upgrade path. A Kubernetes version bump is a MachineDeployment rollout across identical nodes — no "managed control plane upgraded but the k3s boxes are still bootstrapped by hand" split state, and no $0.60/hr extended-support cliff owned by someone else's calendar.
- One cost model. Flat per-machine pricing with no control-plane fee and no per-vCPU meter means capacity planning is arithmetic, not metering forensics. The workload-B dedicated box (€49/month for 8 cores and 64 GB) costs less than the EKS control-plane fee plus platform meter alone.
- One machine API for automation. When AI agents operate the fleet — and Ownkube itself ships an MCP server with ~77 tools precisely because agents are becoming deploy operators — a single declarative machine lifecycle is a far smaller action space to get right than two substrates' worth of special cases.
The price is stated plainly: you own the machines and the ops. The control plane runs on your boxes, upgrades are your runbook, and there is no vendor wizard absorbing the VPC, NAT, and IAM design. For a team with no ops capacity, that price is correctly prohibitive — which is exactly the team Ownkube's wizard is for.
The decision rule
Dual-substrate and single-substrate are not rivals; they answer different constraints. Pick by constraint, not by aesthetic:
- Pick dual-substrate (Ownkube-style) when your workloads must live in AWS (data boundary, compliance scope, customer VPC), when you're ramping from dev to production and the same workflow across both phases is worth the meter, or when you have no ops team and a 5-minute wizard is the difference between shipping and not shipping. Start on Starter, but validate the seam table before you need Production — the switch is a migration, not a toggle.
- Pick single-substrate (Cluster-API-on-owned-metal) when you own the machines, run a steady-state fleet, care about unit cost per workload, or operate the fleet with agents that benefit from one machine API instead of two substrates' special cases. The persistent ~$200/month gap at larger sizes funds a meaningful amount of automation before it stops being the cheaper answer.
The industry is converging on both halves of this at once: PaaS control planes are getting better at spanning substrates (Ownkube's config-intent model, with GCP and Azure on its roadmap), while declarative machine lifecycle is getting better at making one substrate boring (Cluster API 1.12's in-place updates, maturing Hetzner providers). The winning question for a platform team is no longer "which substrate?" but "how many substrates can we afford to be correct on?" — counted in test matrices and upgrade runbooks, not just dollars. For most small teams, the honest answer is one.
Running the numbers on your own PaaS substrate? 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.
