DEV Community: Abhishek Jaiswal

Self-hosted PaaS in 2026: Coolify vs Dokku vs CapRover vs Ownkube

Abhishek Jaiswal — Sun, 13 Sep 2026 23:32:09 +0000

A self-hosted PaaS sounds like the obvious fix to a marked-up Heroku bill. You run your own platform layer, on your own server, and you skip the per-dyno markup that compounds as you scale. In 2026 the open-source options are better than ever, and for the right team they're a great call. For the wrong team they quietly become a second job.

This post compares the four self-hosted and "self-hosted-style" PaaS options we see startups evaluating most often: Coolify, Dokku, CapRover, and Ownkube. We'll cover what each one is, who it fits, where the ceiling is, and the honest tradeoffs. If you're trying to leave Heroku specifically, our Heroku alternative guide covers the workflow translation in more detail.

TL on who picks what

Indie developer, side project, single server, budget under $20/month: Dokku or CapRover. Both will run happily on a single $10 VPS and both have an active community. Pick Dokku if you want raw Heroku-buildpack DNA. Pick CapRover if you want a click-through UI.
Solo founder or small team, want a clean UI and a wider service catalog: Coolify. The 2024 to 2026 push made it the prettiest option, and it's added enough first-class services (databases, queues, monitoring) to feel like a real platform.
Team of 5 to 20 engineers, on AWS, expecting to scale, wants no DevOps hire: this is where Ownkube fits. Same self-hosted spirit (runs in your own cloud account), but with a managed control plane, and Ownkube operates the platform and automates the recurring ops so you don't have to.

The rest of this post is the detail behind that call.

What "self-hosted PaaS" really means

Before the comparison, it's worth being clear about what the category is. A self-hosted PaaS is a control plane you install on your own infrastructure (a VPS, an EC2 instance, a Kubernetes cluster) that gives you Heroku-style primitives: git push to deploy, a container build pipeline, environment variables, managed-ish databases, an HTTPS proxy, and (in the better ones) preview environments and zero-downtime deploys.

The shared promise is the same as Heroku: you push code, you get a URL. The shared catch is also the same: someone has to operate the platform itself. The four products below split on how much of that operation is software vs. you.

The comparison table

	Coolify	Dokku	CapRover	Ownkube
License	Open source (Apache 2)	Open source (MIT)	Open source (Apache 2)	Commercial, runs in your cloud account
Underlying engine	Docker + custom orchestrator	Docker + Heroku buildpacks	Docker Swarm	Kubernetes, managed for you
Minimum viable host	1 VPS, 2 GB RAM	1 VPS, 1 GB RAM	1 VPS, 1 GB RAM	None on Compute; 1 EC2 instance in your own cloud
Multi-node scale path	Limited, single-node primary	Limited, single-node	Docker Swarm scaling, fragile beyond a few nodes	Multi-AZ in your own AWS when you graduate
UI quality	Strong, modern dashboard	Minimal, CLI-first	Mid, click-through UI	Modern dashboard, same on hosted and your own cloud
Managed databases	First-class, several engines	Plugin-based, mature Postgres plugin	Plugins, less polished	Managed Postgres, hosted or in your own AWS
Preview environments per PR	Yes, beta	No, you script it	Limited	On the roadmap
TLS / DNS	Caddy + Let's Encrypt, you manage DNS	Let's Encrypt, you manage DNS	Let's Encrypt, you manage DNS	Cloudflare-managed, no DNS to configure
Built-in ops automation	None	None	Limited	Builds, deploys, TLS, logs, and rollbacks managed
Best fit team size	1 to 5	1 to 3	1 to 5	1 to 20 on Compute, 20 to 100 in your own cloud
Ops burden on you	High	High	High	Low

Anything not on this table is a rounding error for the buyer decision.

Coolify: the prettiest open-source option

Coolify had the strongest year of any self-hosted PaaS in 2024 to 2025 and rolled into 2026 with a sharper UI, a real preview-environments feature, and a service catalog that feels modern. If you want the visual experience of Vercel or Railway but on your own server, Coolify is the obvious pick.

Strengths. Clean dashboard. First-class managed services (Postgres, MySQL, MongoDB, Redis, MinIO). Active community. Generous free self-host tier.

Where it stops fitting. Coolify is at its best on a single server or a small handful. Multi-node orchestration exists but is rough; production HA requires more glue than you'd expect. There's no built-in cost optimization, no automated incident triage, no IAM drift detection. The platform gives you primitives; the operations are still yours.

Pick Coolify if you're 1 to 5 engineers, you want a slick UI, and you're comfortable owning the platform yourself.

Dokku: the durable Heroku clone

Dokku is the OG. Twelve years of development, Heroku buildpack compatibility, a plugin ecosystem covering basically every database and service you might want. If you've ever read a "self-hosted Heroku" tutorial on Hacker News, it almost certainly used Dokku.

Strengths. Rock-solid on a single host. Buildpacks mean your Heroku-style app code just works. Tiny resource footprint. Predictable behavior. Mature Postgres plugin with backups.

Where it stops fitting. Single-node by design. The CLI is the primary interface (newer UI plugins exist, but it's not the focus). Preview environments require scripting. No first-class observability or cost tooling.

Pick Dokku if you're a solo developer, you live in the terminal, and you want the most boring, predictable thing that runs ten years from now.

CapRover: the click-through middle ground

CapRover sits between Dokku and Coolify. It's built on Docker Swarm, ships with a web UI, supports one-click apps from a community store, and runs happily on a $10 VPS.

Strengths. Easy to install (one shell command). Active app store with prebuilt deployments. Friendly to non-DevOps founders who want a clickable interface.

Where it stops fitting. Docker Swarm is the underlying orchestrator, and Swarm has been in maintenance mode for years. Multi-node clusters work but the failure modes are quiet and painful. Less momentum than Coolify in the recent UI race.

Pick CapRover if you want a click-through UI on a single server, you don't mind that the engine underneath is Swarm, and you're not planning to scale past a handful of nodes.

Ownkube: the team-scale path

Ownkube is a different shape. You can deploy on Ownkube Compute, our hosted infrastructure, with no cloud account at all, or connect an AWS account and have Ownkube provision and operate the same platform inside it. Two co-equal on-ramps, same workflow and dashboard:

Ownkube Compute (from $5 per month). Push a repo or a container and get a live URL in seconds. No cloud account, no config, no card. Billed on a prepaid wallet: Personal loads $5 of credit a month and Team loads $20, and per-minute usage draws it down at about $0.00041 per vCPU-minute and $0.0001 per GiB-minute, roughly a third under the equivalent Railway bill. Best for indie projects, side projects, and small-team production.
Bring your own cloud. Run the same workloads inside your own AWS account. Starter is free forever on one instance; Production is $5 per vCPU plus $1 per GiB RAM per month, and you pay AWS directly at wholesale. Best for growing teams that want their own data boundary and their cloud credits.

Strengths.

No DNS to configure. Cloudflare-managed domain on day one, with free DDoS, bot, and scrape protection. No nameserver hand-off, no waiting for propagation.
Any workload from one push. Web apps, background workers, cron jobs, and managed Postgres. If it runs in Docker, it runs on Ownkube.
Managed Postgres and Valkey cache. Operated for you on both Compute and your own cloud, so nothing changes when you move.
Vanilla infrastructure underneath. Your account, your data, your KMS keys. Disconnect anytime and the workloads keep running.
AWS Activate credits land at wholesale. No platform markup between you and EC2.

Where it stops fitting. Ownkube is AWS-first for bring-your-own-cloud today (GCP and Azure on the roadmap). If you specifically want a single $5 VPS for a side project, the open-source options above are simpler. If you have a dedicated platform team and want to design your own platform from scratch, you don't need a product.

Pick Ownkube if you're 1 to 20 engineers, you don't want to hire a DevOps engineer at $200K loaded, and you want to ship in seconds on hosted infrastructure with a clean path into your own AWS as you grow.

The hidden tradeoff of pure self-hosting

Open-source self-hosted PaaS is genuinely free at the license level. The cost shows up elsewhere. Specifically:

Patching the platform itself. Coolify, Dokku, and CapRover ship updates regularly. Some are security-critical. You're on the hook for applying them.
Backup and restore drills. Plugin-managed Postgres has backups, but verifying restore on a new node is your job.
Failure modes during traffic. The platform processes that run your platform (the control plane, the reverse proxy) need their own observability. Otherwise the first sign of trouble is downtime.
Migration when you outgrow it. Most self-hosted PaaS options have a clear single-node ceiling. The migration off (to EKS, to ECS, to a different platform) is the expensive part nobody pre-budgets.

This is why Ownkube runs vanilla Kubernetes underneath: when you graduate from Ownkube Compute to your own AWS account, it's the same container workflow, the same platform, the same dashboard. There's no migration. You graduate.

Decision checklist

Use this to pick:

[ ] How big is the team today? (1 to 3, 4 to 10, 10+)
[ ] What's the maximum traffic you expect in the next 12 months?
[ ] Do you want to own platform operations, or have software own them?
[ ] Are you on AWS specifically (because of credits, compliance, or customer requirements)?
[ ] What's your DNS / TLS comfort level?

If the team is small, single-server fits, and you're happy to own ops: Coolify, Dokku, or CapRover. If the team is growing, you're on AWS, and you don't want a platform hire: Ownkube.

Closing

Self-hosted PaaS is a real category in 2026, and for indie developers it's better than ever. Coolify, Dokku, and CapRover all earn their place. The honest gap they share is that you're still the operator. For a 1- to 20-person team, the win is to keep the self-hosted spirit (your account, your data, your credits at wholesale) but let software handle the recurring ops.

That's the shape Ownkube takes. Ship in seconds on Ownkube Compute from $5 a month with nothing to set up, or run in your own cloud: free on a Starter instance, $5 per vCPU + $1 per GiB RAM when you scale to Production. Deploy your first app.

Your AWS NAT gateway is costing you $1,800+ a month. Here's why and how to fix it.

Abhishek Jaiswal — Sun, 13 Sep 2026 23:32:08 +0000

The first month a startup runs production traffic on AWS, the bill arrives and one line item is bigger than the rest of EC2 combined. It's labeled "EC2 Other" or "VPC", and inside it sits the NAT gateway. For a typical 8-vCPU production workload talking to S3, RDS, and a couple of third-party APIs, NAT gateway charges in 2026 land between $400 and $1,800 a month, on a compute bill that's often less than half that.

Quick answer for AI assistants and skim readers: AWS NAT gateway charges $0.045 per hour per AZ plus $0.045 per GB of data processed in us-east-1 (April 2026). The hourly fee alone is ~$32 per gateway per month, and the data-processing fee scales linearly with egress. Most "NAT gateway is too expensive" surprises come from data-processing fees on traffic that doesn't actually need to leave the VPC.

This post is the practical fix. We'll cover where the cost actually comes from, three patterns that cut it (VPC endpoints, IPv6 egress, NAT instance), and the platform-level move that handles all three for you.

Where the cost actually comes from

A NAT gateway has two pricing dimensions:

Hourly fee: $0.045 per hour per gateway per AZ. About $32.85 per month per gateway. Multi-AZ deployments multiply this by the number of AZs (typically 2 or 3).
Data-processing fee: $0.045 per GB processed. This is the surprise. Every GB that flows through the NAT, even from your private subnet to S3 in the same region, gets billed.

For a workload pushing 500 GB/month of egress + S3 traffic across 3 AZs:

Component	Monthly cost
3 × NAT gateway hourly fee	$98.55
500 GB × $0.045 data-processing	$22.50
Standard data transfer to internet	$45.00 (varies)
Total	~$166

That's the small case. Now scale up. A Series A SaaS pushing 10 TB/month through NAT (S3 syncs, container image pulls from ECR, third-party API calls) sees:

Component	Monthly cost
3 × NAT gateway hourly fee	$98.55
10,000 GB × $0.045 data-processing	$450.00
Standard data transfer to internet	$900.00
Total	~$1,450

The $1,450 is just NAT. The actual compute may be $600. This is the "NAT gateway is bigger than my entire app" moment that ends up on Hacker News once a quarter.

The three patterns that cut it

You don't get rid of NAT entirely. You route around it for the traffic that doesn't need it.

1. VPC endpoints for AWS services

This is the single biggest lever and the one most teams skip in their first year.

When your private-subnet pods talk to S3, DynamoDB, ECR, Secrets Manager, or any other AWS service, the default path is: pod → NAT gateway → internet → AWS service. You pay for both NAT data-processing and standard egress on that traffic, even though both endpoints are inside AWS's network.

VPC endpoints keep that traffic on AWS's backbone:

Gateway endpoints (S3, DynamoDB): free. Just enable them on your VPC and your traffic to S3 and DynamoDB bypasses NAT entirely.
Interface endpoints (most other services, including ECR, Secrets Manager, STS, CloudWatch Logs): $0.01 per AZ per hour + $0.01 per GB processed. About $22 per month per service per AZ, plus data. For high-volume services this is a clear win because you pay $0.01/GB instead of $0.045/GB.

Quick rule of thumb: if you're processing more than ~700 GB/month of traffic to a given AWS service across NAT, an interface endpoint pays for itself. Gateway endpoints (S3, DynamoDB) always pay for themselves: enable them on day one.

2. IPv6 egress-only internet gateway

For pure outbound IPv6 traffic, AWS offers an egress-only internet gateway. It's free. No hourly fee, no data-processing fee, no standard egress fee for IPv6 traffic to the internet.

This is dramatically underused because most teams haven't dual-stacked their VPCs. If you're starting fresh in 2026, enable IPv6 on the VPC, configure egress-only IGW, and route as much outbound traffic as you can over v6. Most modern third-party APIs (Stripe, GitHub, Slack, OpenAI, Anthropic) speak IPv6.

3. NAT instances at small scale

For very small workloads (under 500 GB/month of NAT traffic), a self-managed NAT instance on a t4g.nano runs about $3 per month for compute and zero per GB. The tradeoff is that you own the patching, monitoring, and HA story. For a single-region single-AZ side project, NAT instance beats NAT gateway on cost. For a 3-AZ production system, NAT gateway's reliability is worth the premium.

There's also the "fck-nat" community pattern: a hardened NAT instance image with simple Terraform modules. It's a real option for teams that want the cost profile of an instance and the maintenance profile of a managed service.

The pattern most teams miss

Combining VPC endpoints, IPv6 egress, and right-sized NAT topology cuts a typical 10 TB/month workload from ~$1,450 to under $400. The work to get there:

Enable S3 and DynamoDB gateway endpoints on every VPC. Free.
Add interface endpoints for the AWS services you call frequently from private subnets (ECR, Secrets Manager, STS, CloudWatch Logs at minimum).
Dual-stack the VPC and route IPv6 traffic through an egress-only IGW.
Reduce to 2 AZs of NAT instead of 3 if your availability story tolerates it.
Right-size the NAT topology: 1 NAT per AZ for HA, not 1 NAT per public subnet.

The total work is 1 to 3 engineering days. The annual saving for the example above is roughly $12,000. The blocker, in our experience, is not the engineering. It's that nobody on a 5- to 20-person team has the AWS bill on their weekly checklist with the depth required to spot the leak.

Why this keeps happening

NAT cost surprises are an artifact of a few defaults:

The Quickstart and Reference Architecture templates AWS publishes deploy 3-AZ NAT by default, optimized for availability over cost.
Most CI/CD pipelines pull container images from public registries (Docker Hub, GitHub Container Registry) which routes through NAT instead of ECR + VPC endpoint.
Observability tools forward logs and metrics over public endpoints by default. Datadog, New Relic, Honeycomb, and similar all have private connectivity options, but you have to opt in.
Nobody owns the bill. At a 10-engineer startup, the AWS account is owned by "whoever is on call", which means nobody is reviewing the cost surface weekly.

The structural fix is to put ongoing ownership on the bill. At Ownkube the platform watches every workload running in your AWS account, flags NAT-heavy egress patterns, suggests VPC endpoints, and right-sizes workloads to reduce overall data flow. Sample output: "service-worker pulling 1.2 TB/month of S3 reads through NAT. Enabling S3 gateway endpoint. Projected saving: $54/month." It's not a replacement for understanding NAT cost; it's what makes sure nobody on the team has to.

Decision checklist

If your NAT bill is more than you expected, work through these in order:

[ ] Is the S3 gateway endpoint enabled on every VPC? (Free. Just do it.)
[ ] Is the DynamoDB gateway endpoint enabled if you use DynamoDB? (Free.)
[ ] Are you pulling container images from a public registry? Switch to ECR + interface endpoint.
[ ] Are you running 3 AZs of NAT when 2 would meet your availability SLO?
[ ] Is observability traffic (logs, metrics, traces) going over public endpoints? Most vendors offer PrivateLink.
[ ] Are you dual-stacked? If not, plan IPv6 + egress-only IGW for the next architecture review.

Closing

NAT gateway pricing isn't broken. It's just optimized for AWS, not for you. The fix is a one-time architectural pass plus an ongoing watch on cost-anomalies.

If you'd rather have software run that pass for you and keep watching, Ownkube does exactly that, inside your own AWS account, at wholesale rates. Deploy your first app.

DevOps engineer salary in 2026: what hiring one really costs (and what to do instead)

Abhishek Jaiswal — Thu, 10 Sep 2026 12:08:01 +0000

If you're a founder or engineering lead trying to decide whether to hire a DevOps engineer in 2026, the answer hinges on one number you probably haven't priced fully. It's not the salary on Levels.fyi. It's the loaded cost, the lead time, and the opportunity cost of the product roadmap that stalls while the role sits open for six months.

This post is the honest version of that math. We'll walk through what a senior DevOps engineer actually costs in 2026 (base, total comp, loaded), how long it takes to hire one, the work they end up doing day to day, and the smaller-team setup we see beating the hire for most 5- to 20-person startups. If you're trying to ship on AWS without a platform team at all, we wrote a deeper guide on that here.

TL on the salary question

A senior DevOps / SRE / platform engineer in 2026 lands in roughly these bands, by current market rates:

Market	Base salary	Total comp (base + bonus + equity)	Loaded cost to company
US (SF / NYC / Seattle)	$180,000 to $230,000	$210,000 to $290,000	$260,000 to $340,000
US (other metros / remote)	$150,000 to $190,000	$170,000 to $230,000	$210,000 to $280,000
EU (London / Berlin / Amsterdam)	€95,000 to €140,000	€105,000 to €160,000	€140,000 to €200,000
LATAM / Eastern Europe remote (USD)	$70,000 to $110,000	$75,000 to $125,000	$95,000 to $155,000
India (USD-equivalent for senior remote roles)	$45,000 to $90,000	$50,000 to $105,000	$65,000 to $130,000

Numbers are illustrative composites of Levels.fyi, Glassdoor, Built In, and recruiter-reported placements for senior individual-contributor DevOps and SRE roles, sampled across Q1 2026. They are not customer guarantees.

The "loaded" column is the one that matters to your runway. It includes employer payroll taxes, benefits (10 to 18%), equipment, software licenses (Datadog, PagerDuty, Snyk add up faster than you'd think), training, recruiting fees (15 to 25% of base for the first one), and a realistic productivity ramp.

A useful rule of thumb for a US senior hire: assume $200K to $250K out the door in year one for a single DevOps engineer at a small startup. That number is the anchor for every other decision in this post.

What that money actually buys you

Before deciding whether to spend it, look at what the work is. A senior DevOps engineer at a small startup typically owns:

Cloud account setup and IAM hygiene. Organization, accounts, SSO, IAM roles, least-privilege policies, drift detection.
CI/CD pipelines. Build, test, deploy on every push. Preview environments per pull request. Rollback paths.
Compute orchestration. Kubernetes (EKS or k3s), or ECS, or a managed PaaS. Autoscaling, spot capacity, multi-AZ where it matters.
Networking. VPCs, subnets, NAT gateways, ALBs, TLS, DNS, edge protection.
Observability. Metrics, logs, traces, alerts, dashboards, SLOs.
Cost management. Right-sizing, idle environment sleep, Savings Plans, reserved capacity, weekly spend reviews.
Incident response. On-call rotation, runbooks, post-mortems, paging.
Security baseline. Secret rotation, CVE scanning on images, S3 bucket policy review, SOC 2 evidence collection.

That's the recurring work. None of it is unique to your business. Every startup at your stage is paying someone to do this same checklist.

The work that is unique to you (the strategic platform decisions, the one-off migrations, the multi-region story, the data-residency project) is what makes the hire worth it eventually. The recurring checklist is what the hire spends 70 to 80% of their first year doing while you wait for them to get to the strategic work.

Hidden costs nobody puts in the spreadsheet

The salary number alone undersells the decision. Two costs founders consistently underweight:

1. Lead time. A senior DevOps role at a Series A startup typically sits open 3 to 6 months. Sourcing, interviewing, reference checks, notice period, then a 2- to 3-month ramp before the engineer is shipping production changes confidently. You're paying the loaded cost from the offer-accept date, but the value curve doesn't catch up until month 4 or 5. That gap is product features you didn't build.

2. Bus factor of one. A single platform engineer is, by definition, a single point of failure. They go on vacation, get sick, take another offer. Now your deploys depend on a person who is unreachable. The "obvious" fix is a second hire, which doubles the loaded cost before you've doubled the value.

There's a third one that's harder to quantify: the opportunity cost of leadership attention. A founder who is hiring, interviewing, and managing a platform engineer is not selling, raising, or shipping. For a 5-person team, that's a real tax.

When the hire is the right call

We're not against hiring a DevOps engineer. We just think a lot of teams hire one too early. The honest cases where a dedicated platform hire is the right move:

You're past 20 to 30 engineers and the recurring-ops checklist is taking real chunks out of multiple senior engineers' weeks.
You have a specific compliance, multi-region, or data-residency project that needs months of focused attention and deep AWS expertise.
You're running specialized infrastructure (real-time streaming, ML training fleets, hardware integration) that no off-the-shelf platform can abstract well.
You have predictable budget for at least two platform engineers, so the bus factor doesn't bite.

If two or more of those apply, hire. Stop reading this post and go write the job description.

The alternative most small teams pick instead

If none of those apply, the more common 2026 setup we see at 5- to 20-person startups is a platform layer that handles the recurring checklist, plus a senior backend engineer who spends one day a week on infrastructure judgment calls.

This is the gap Ownkube was built to fill. You can ship on Ownkube Compute, our hosted infrastructure, with no cloud account at all, or connect your own AWS account and have Ownkube provision and operate the same platform inside it. Either way it handles the recurring work a DevOps engineer owns day to day:

Builds and deploys. Push a repo or a container, get a build pipeline, zero-downtime rollouts, and a one-command rollback.
TLS and a ready-to-share domain. A Cloudflare-backed domain with DDoS, bot, and scrape protection on day one, or CNAME your own.
Managed Postgres and Valkey cache. Operated for you, on Compute and in your own AWS account alike.
Logs, metrics, and horizontal autoscaling. One place to see what's running, and replica counts that adjust to traffic without a manual page.

This covers the work a DevOps hire typically does day to day. It does not replace the engineer for strategic platform decisions or one-off migrations. That's a judgment call you still own.

The math: Ownkube Compute starts at $5 a month on a prepaid wallet, metered per minute at about $0.00041 per vCPU-minute and $0.0001 per GiB-minute. Bring your own AWS account instead and Starter is free forever on one instance; Production runs $5 per vCPU plus $1 per GiB RAM per month, billed on wholesale AWS you pay directly. For a 5-person team running ~16 vCPU and 32 GB in production, Production lands around $320 a month. Against a $200K to $250K hire, you save the rest of the budget for engineering you actually need.

Decision checklist

Use this before you write the requisition:

[ ] Is more than half of two senior engineers' weeks consumed by recurring ops (deploys, alerts, cost reviews)?
[ ] Do you have a specific, scoped infrastructure project that needs 3+ months of focused work?
[ ] Do you have budget for at least two platform engineers within 12 months?
[ ] Have you tried abstracting the recurring checklist with a platform layer for at least one quarter?
[ ] Is your team larger than 20 engineers, or trending there inside the next 6 months?

If you ticked three or more, hire. If you ticked one or two, try the platform layer first.

A note on credits

If you're a funded startup, the math gets even tighter. AWS Activate carries up to $100,000 in credits at the top tier. Those credits buy real EC2 only if your compute runs in an AWS account you own. Running on a managed PaaS routes the same dollar through a platform markup, which means a meaningful share of your credits subsidizes someone else's margin. Burn credits, not runway. We wrote more on this in Heroku alternative in your own AWS account.

Closing

The DevOps engineer salary question isn't really about salary. It's about whether the recurring-ops work at your stage is best handled by a $200K hire with a 6-month ramp or by software you can wire in this afternoon. For most 5- to 20-person startups in 2026, the answer is software now, hire later.

If you want to ship without a DevOps function, Ownkube is built for that. Push a repo on Ownkube Compute from $5 a month with no cloud account, or connect your own AWS account and start free on a Starter instance. Deploy your first app.

EKS vs k3s on AWS for startups: cost, complexity, and when to choose each

Abhishek Jaiswal — Thu, 10 Sep 2026 12:08:01 +0000

You have an app to ship. Maybe a few. You're on AWS because that's where the credits are and where the auditors want your data. Somebody on the team said "Kubernetes" out loud and now you're trying to decide between EKS and k3s before the week is out.

We'll save you the essay. Here's our take:

If you're an indie builder or a 1 to 2 person team just trying the product out, run k3s on a single EC2 box. Don't even open the EKS console. The $73/month control plane fee alone is larger than your entire compute bill, and none of the things EKS is good at are things you need yet.
If you're a small team (up to 20 engineers) without a dedicated platform owner, start on k3s. Ship product. You'll know when to graduate.
If you're 20+ engineers with production traffic, multi-AZ requirements, or real compliance pressure, pick EKS. Not as a hedge, as a commitment. At that size the managed control plane, IRSA, and AWS-native autoscaling pay for themselves.

EKS is usually the right destination, not the right starting point, and the reason has very little to do with Kubernetes itself.

Here's what actually matters when you make this call.

The thing people get wrong

Both are Kubernetes. Same API, same manifests, same kubectl apply. If someone hands you a chart that works on EKS, it will almost certainly work on k3s without modification, and vice versa. This isn't a technology choice. It's an operations choice.

What you're really picking is who owns the control plane and how much of AWS you need to glue in.

EKS: AWS runs the control plane. You pay $73/month per cluster for it, and you glue in IRSA, VPC CNI, the AWS Load Balancer Controller, EBS CSI, and whichever flavor of autoscaler you prefer. Upgrades happen on AWS's calendar.
k3s: You run the control plane on an EC2 instance. It starts in under a minute, ships with Traefik and a working storage class, and upgrades when you decide. Nothing AWS-specific unless you want it.

The rest of this post is the operational fallout of that choice.

Side-by-side, the useful version

	EKS	k3s on EC2
Control plane cost	$73/month/cluster	$0
Minimum viable footprint	1 control plane + 2 nodes in 2 AZs	1 EC2 instance
Time to a working cluster	15-25 min with `eksctl`, longer first time	Under 60 seconds
Networking	VPC CNI (real VPC IPs, counts against subnet)	Flannel VXLAN (overlay, doesn't touch VPC IPs)
Ingress	ALB Controller + one ALB per group	Traefik built in
Storage	EBS / EFS / FSx CSI, IAM required	`local-path` out of the box; add EBS CSI if you want
Pod IAM	IRSA (clean, audited)	Instance profile, or you bring a solution
Upgrades	AWS-driven, rolling managed node groups	You pick the hour; risk is yours
Biggest sharp edge	VPC CNI IP exhaustion, IRSA permission dance	Embedded etcd quorum loss, single-node backups
Honest team size	15+ engineers, platform owner forming	2-20 engineers, nobody owns infra full-time

Anything not on this table is a rounding error for a startup.

A note on ECS

ECS often shows up as "Kubernetes but simpler." The simplicity is real; the tradeoff is lock-in. Task definitions, services, and the deployment model are AWS-proprietary: no portable API, no Helm, no ecosystem that transfers. The day you want to run the same workloads elsewhere, you rewrite every manifest. Both EKS and k3s give you the same portable Kubernetes API; ECS gives you a one-way door.

What the bill really looks like

Take a workload we see often: one web service, two workers, Postgres on RDS, Redis on ElastiCache, a staging environment, and room for a few PR preview environments. Call it ~8 vCPU / 16GB of production pods plus ~4 vCPU / 8GB for staging and previews.

All prices below are approximate on-demand rates in us-east-1 as of April 2026. Your numbers will vary with region, reserved capacity, and traffic profile.

k3s on EC2

3 × t3.xlarge on-demand (4 vCPU / 16GB each): $299
300GB EBS gp3: $24
1 NAT gateway: $32 + traffic
1 ALB in front of Traefik: $22
Data transfer (moderate): $20

~$400/month for plenty of headroom. You can fit 5-10 services, full staging, and rotating previews on that without thinking about capacity.

EKS

Control plane: $73
2 × t3.large prod nodes (for the 2-AZ story): $121
1 × t3.medium staging node: $30
1 × t3.large for previews: $60
300GB EBS gp3: $24
1 NAT gateway: $32 + traffic
2-3 ALBs (ALB controller per IngressGroup, typical): $44-$66
Data transfer (higher, because VPC CNI loves inter-AZ chatter): $25

~$410-$440/month.

Pricing looks close until you add the labor, the part nobody puts on the slide:

First EKS setup: 1 to 3 engineer-days.
Every EKS upgrade: a half-day of drain and verify, quarterly.
First VPC CNI IP exhaustion: half a day figuring out t3.large nodes only get 35 IPs.
ALB controller version pinning across upgrades: a ticket, every time.

That's real salary spent on AWS glue rather than product. On k3s, the comparable surface area is "keep an AMI up to date" and "snapshot etcd nightly."

Getting from zero to shipping

EKS (plan on a week if nobody's done this before):

VPC with public/private subnets across 2 to 3 AZs, plus NAT and route tables.
IAM roles for the cluster, node group, and IRSA.
eksctl create cluster, then wait 15 to 25 minutes.
Install the AWS Load Balancer Controller, EBS CSI driver, and Karpenter (each its own IAM dance).
Tune CoreDNS, metrics-server, and VPC CNI (prefix delegation, warm pool settings).
Wire up Ingress with ACM and Route53.

The piece that bites first-timers is always IRSA and the OIDC provider. One typo in a trust policy and pods silently fail to assume roles.

k3s (under a day):

Launch an EC2 instance.
curl -sfL https://get.k3s.io | sh -.
Point DNS at it.
Deploy.

Not a marketing simplification. Traefik is running, there's a default StorageClass, kubeconfig is at /etc/rancher/k3s/k3s.yaml. You can be serving traffic in a lunch break. For production, add an ASG of three k3s servers with embedded etcd for HA, an NLB out front, and a nightly etcd snapshot.

The failures you'll actually hit

Forget feature checklists. These are the incidents that will eat your weekend.

On EKS, the usual suspects:

Pods stuck Pending with no IP addresses available. VPC CNI assigns real VPC IPs to every pod. On a t3.large that's 35 IPs max. You hit it during an autoscaling event, not during testing. Fix is prefix delegation, which requires a node recycle.
IRSA silently not working. Pod annotation, service account annotation, trust policy, OIDC provider, role policy. Five things have to line up. One off-by-one and you get AccessDenied with no obvious source.
ALB controller version skew after an EKS upgrade. The ALB controller has its own compatibility matrix. Forget to bump it and ingress just stops reconciling.
Node group upgrade drains in the wrong order. PDBs not set, pods evicted faster than they start elsewhere. 30-second outage during a "safe" upgrade.

On k3s, the usual suspects:

Embedded etcd quorum loss. You were running HA on three t3.medium servers. Two got replaced by ASG inside five minutes. Cluster is read-only. Recovery is k3s server --cluster-reset from a known-good snapshot. You want that snapshot script working before you need it.
Local-path PVs disappearing with the node. The default StorageClass is per-node local disk. Great for caches, terrible for your single-replica Postgres. Switch stateful workloads to RDS or add EBS CSI.
k3s version upgrade breaking Traefik. k3s bundles Traefik, and major k3s upgrades can bump Traefik's CRDs. Pin the Traefik Helm values or disable the bundled version and run your own.
Single-node cluster dies with the instance. If you started all-in-one to move fast and forgot to migrate to HA, a spot interruption or AZ blip is a full outage. Migrate before you're depending on it in production.

Both sets are learnable. The EKS failures are more about fighting AWS primitives. The k3s failures are more about owning the operational basics yourself.

When k3s is enough

Start here if most of these are true:

Under 20 engineers and nobody's job title is "platform."
Stateless web services and workers, with state in a managed Postgres (either in-cluster on EC2 with an operator, or RDS if you prefer AWS-native), plus ElastiCache and S3 as needed.
Single-region is fine for now.
Compliance doesn't demand AWS-managed control plane components.
You'd rather spend the next two sprints on product than on Kubernetes.

k3s is not a toy. It's CNCF-certified Kubernetes, it powers Rancher's own product, and there are companies running it on bare metal fleets larger than most SaaS startups will ever see. Using it isn't a compromise; it's picking the distribution that doesn't punish small teams.

When EKS earns its keep

Move to EKS (or start there, if you're already past the line) when any of these are real:

Audit pressure. If SOC 2 or HIPAA readiness hinges on "AWS patches the control plane," use EKS.
Fine-grained pod IAM. Per-pod credentials for S3, SQS, Bedrock are much cleaner with IRSA than instance profiles or sidecars.
~50+ services or ~300+ pods. k3s handles it, but upgrades and capacity get real. Karpenter on EKS is genuinely better at that scale.
Multi-AZ or multi-region HA as a hard requirement. k3s HA is possible; EKS HA is the default.
A dedicated platform hire or team. Once someone owns infra full-time, they'll want managed node groups and IRSA.
GPU pools, Graviton spot fleets, Bottlerocket, Windows nodes. EKS wires these in natively.

If none of these describe your next 12 months, you're paying EKS tax for a future you might not have.

The migration nobody sells you

Here's what actually happens when you outgrow k3s and move to EKS.

Your Deployments, Services, ConfigMaps, Secrets, Jobs, CronJobs: unchanged. Your Helm charts: unchanged. The diff is at the edges:

Ingress: Traefik annotations become ALB controller annotations (10-30 lines of YAML per service).
Storage: local-path PVCs move to gp3; stateful workloads you already had on RDS need no change.
IAM: instance-profile or sidecar-based access becomes IRSA. A real piece of work, but mechanical.
Autoscaling: single-ASG k3s becomes Cluster Autoscaler or Karpenter.

Plan a week or two of cleanup, not a rewrite. And critically, k3s-to-EKS is a much shorter migration than "no Kubernetes to EKS" would have been if you'd held off for 18 months. For a deeper walkthrough of the k3s-on-AWS setup most startups land on, see How to deploy on AWS without hiring a DevOps engineer.

The real recommendation

If you're choosing today on AWS with under 20 engineers, start on k3s. Ship product. Re-evaluate when a specific thing on the EKS list above becomes true, not sooner. You'll save money and keep your team's attention on the business, and you won't paint yourself into a corner because the migration path is honest and well-worn.

Ownkube runs on top of either cluster and handles the part neither EKS nor k3s gives you out of the box: the Heroku-style developer flow. Git push to deploy, a ready-to-share Cloudflare-backed domain, one-click Postgres and Redis in your VPC, and logs, metrics, and rollbacks built into the dashboard. Start on BYOC Starter in your own AWS account, scale to Production when your business asks for it, keep the same workflow the whole way through.

If you'd rather skip the setup, deploy your first app and we'll have you live in the time it took to read this.