The Early-Stage Infrastructure Playbook: Kubernetes Before Your First DevOps Hire

There is a piece of advice every technical founder has heard, usually delivered with the weary confidence of someone who has seen things: “Do not touch Kubernetes until you can afford a platform team. Use a PaaS, ship your product, worry about infrastructure later.”

I want to take that advice seriously, because it was correct when it was coined. Around 2019, adopting Kubernetes as a three-person startup meant one founder becoming a part-time YAML archaeologist: hand-rolling cluster provisioning, assembling ingress and cert-manager and monitoring from blog posts, debugging CrashLoopBackOffs at midnight with nobody to ask. The tax was real, the product suffered, and the PaaS alternative was genuinely the better trade.

But advice is a compressed conclusion, and conclusions rot when their premises change. Every load-bearing premise under “not yet” has changed. This post is the updated playbook: what an early-stage team should actually set up, what it should refuse to set up, and the math on what it costs, which rounds to zero.

What the old advice was really about

Strip the meme away and the 2019 advice encoded three true statements:

1. Kubernetes itself was expensive to operate. Control planes, upgrades, networking, certificates: a standing job before your first deploy.
2. The ecosystem around it was assembly required. Fifteen Helm charts, in the right order, with values nobody documented, glued together by the one person who understood them.
3. Operating it required expertise you could not afford. The person who could run it well cost six figures and was better spent building product, if you could hire them at all.

Notice that none of these statements is about Kubernetes being wrong for small workloads. Kubernetes was always a fine way to run a web app, a database, and a queue. The objection was never the destination; it was the price of the road. So the honest question in 2026 is not “is Kubernetes overkill,” it is “what does the road cost now.”

What changed

The cluster became a commodity. Managed control planes are table stakes on every cloud, and after the Hetzner repricing we did the math on this blog: a production-shaped cluster on European cloud, three workers, a control plane, ingress, runs about €65 a month. Ankra provisions one on Hetzner, OVHcloud, or UpCloud in minutes, or imports whatever you already have, including the k3s cluster on the OrbStack instance of your laptop. Premise one is gone.

The assembly became a product. The fifteen-chart scavenger hunt is what Stacks exist to kill: addons, manifests, and your applications wired into a dependency graph, deployed in order, versioned in Git. Describe the stack once, in the builder or by asking the AI for it, and clone it to every environment you will ever have. Premise two is gone.

The expertise became software. This is the one people have not internalized yet. The judgment you were hiring for, which values are load-bearing, why the pod is crashlooping, what that OOM trend means, is exactly what an AI operator with full cluster context does now: root-cause analysis delivered to Slack, proactive insights before things page you, plain-language explanations of anything on the graph. And because every AI change lands as a draft a human approves and Git records, you get the senior engineer’s output without handing production to an intern with root. Premise three is the reason this post exists.

The advice was “not yet” because the road was expensive. The road is now paved, and the toll for a team your size is literally zero: Ankra’s free plan includes 30 worker vCPUs, unlimited clusters, unlimited team members, and the AI, which covers a seed-stage company’s entire footprint with room to spare.

But why not just stay on a PaaS?

Because the PaaS trade has a shape, and early-stage teams keep rediscovering its edges at the worst possible moments.

The PaaS deal is: pay a premium per compute unit in exchange for not thinking about infrastructure. At day one the premium is small and the not-thinking is priceless, which is why it is a fine place to start and I will not pretend otherwise. The edges show up later, on a schedule you do not control. The pricing curve bends steeply exactly when your usage grows, which is exactly when you have the least time to re-platform. The features you eventually need, a VPC peering, a compliance requirement, a background worker with weird resource needs, a customer who demands EU-only data residency, sit on the other side of a wall the PaaS did not build doors into. And the migration off, when it comes, lands as an unplanned quarter of engineering during your growth phase. Ask anyone who was on Heroku’s free tier in November 2022 how much notice you get when a platform changes its mind.

Kubernetes through a platform inverts the shape: slightly more thinking on day three, and no wall, ever. The same stack that runs your MVP on one Hetzner node runs your Series B fleet across providers, because the abstraction underneath is the industry’s, not a vendor’s. There is no cliff where you outgrow it, and, as we argued in the cost post, portability is also the only durable defense against every vendor’s future pricing decisions, PaaS and cloud alike.

The old model made you choose: PaaS simplicity now and a migration later, or Kubernetes power now and a platform tax later. The entire point of the current generation of tooling is that this fork is gone.

The week-one playbook

Here is the concrete setup we would give any two-to-six person team, and roughly an afternoon of work.

One cluster, boring shape. Three CX43 workers and a small control plane on Hetzner through Ankra (about €65 a month), or import the managed cluster your cloud credits pay for. Do not agonize over this choice; the whole point of what follows is that it is cheap to change later.

One GitOps repo from minute one. Connect it when you import the cluster. Every change you ever make, from the UI, the CLI, or the AI, becomes a commit. You are two people today and you think you will remember why you changed that value. You will not. In eighteen months, when you hire, the repo is the onboarding doc; in three years, when a customer’s auditor asks, it is the audit trail. This costs nothing to start and cannot be retrofitted.

One production stack. Ingress-nginx, cert-manager, your app, its database, a monitoring addon. Ask the AI to draft it (Cmd+J, “a production stack for a web app with Postgres, Redis, and TLS on this domain”), review the graph it proposes, deploy. Pin every chart version. Put every secret through SOPS encryption from day one, because day one is when it is free and day four hundred is when the plaintext password in Git becomes an incident report.

Alerts to the Slack you already live in. Wire the webhook so that when something breaks, the message contains a root cause, not a red X. For a team with no on-call rotation, because the rotation is “both of you,” an alert that arrives pre-investigated is the difference between a five-minute fix and a lost evening.

Environments by cloning, not by ceremony. When you need staging, or a demo environment for that enterprise prospect, clone the production stack and let variables resolve the domains and sizes. The five-person team in that post ran laptop-to-production on this pattern; at your size it is even simpler.

That is the whole thing. No service mesh, no multi-cluster topology, no platform team, no hire.

The anti-playbook: what to refuse to build

Early-stage infrastructure fails in two directions, and the second is underrated. Under-engineering gives you the plaintext secret and the untracked hotfix. Over-engineering gives you a three-person company operating a service mesh. Refuse, specifically:

• A second cluster you do not need. Environments are stacks with different variables, not more control planes. Scale to zero what idles; deleting the Kubernetes layer keeps the config and stops the bill.
• A self-hosted observability empire. One monitoring addon in the stack. You do not need a Thanos deployment; you barely need the Prometheus-vs-VictoriaMetrics decision yet, and when you do, it is a values change, not a project.
• A DevOps hire whose job is the platform. The moment infrastructure becomes someone’s whole job at a six-person company, a founder has quietly decided to build a platform company inside their product company. Hire when there is product-shaped work for the person, and let the AI hold the pager until then.
• A migration you are saving up for. The most expensive infrastructure pattern in startups is “we will fix it after the fundraise.” You will not; you will be busier. Start on the thing that does not need leaving.

The runway math, said out loud

Infrastructure decisions at seed stage are runway decisions wearing overalls. The comparison that matters is not €65 versus €0; it is the fully loaded alternatives:

• The DevOps hire you defer is six figures a year in most markets, your single largest line item after founders, spent on someone whose output your customers never see.
• The founder-time tax of DIY is worse: every hour a technical founder spends debugging ingress annotations at midnight is an hour of the most expensive labor your company will ever employ, spent below its pay grade.
• The PaaS premium plus eventual migration is the quiet third option, fine until the invoice bends or the wall appears, both on someone else’s schedule.

Against those: a €65 cluster, a platform whose free tier covers your whole footprint, and an AI that does the investigating. The startup advice canon says do things that do not scale. Your infrastructure is the one place where the same effort now buys you the thing that does.

The unfair advantage nobody mentions

One more thing, and it is the one I would actually lead with if this were a pitch instead of a playbook. Early-stage companies do not lose to incumbents on product ideas. They lose on capacity: five people cannot cover product, sales, and a 3 AM pager the way fifty people can. Every hour of operational toil you delete is transferred directly to the only work that differentiates you.

A five-person team with a senior DevOps agent on call, boring GitOps rails underneath, and infrastructure that clones instead of being rebuilt is not “doing Kubernetes early.” It is competing with a thirty-person company’s operational capacity on a five-person payroll. That is the actual reason the 2019 advice needs retiring: not because Kubernetes got fashionable, but because the leverage flipped sides.

Start it this weekend. Create a free account, import or provision one cluster, ask the AI for your first stack, and connect the Git repo before you deploy anything. Thirty free vCPUs is more infrastructure than most companies need before their Series A, and the setup fits in the afternoon between two customer calls.

---

Get started: Create a free account on Ankra.

Join our community: Slack

Follow us on: LinkedIn | GitHub

Contact us: [email protected]