The platform engineer req didn't make the cut this year. The budget conversation happened, the headcount went to product engineering, and the decision felt reasonable in the room. But the Kubernetes maintenance work that justified the req did not go anywhere. It landed back where it always lands: on your two most senior engineers, who now split their weeks between the roadmap they were hired for and a cluster that keeps asking for attention. Every hour they spend on node upgrades and ingress debugging is an hour of your most expensive engineering capacity spent on work that ships no feature and closes no deal.
The choice is usually framed as binary: hire a platform engineer or keep suffering. That framing is wrong, and it is expensive. A platform hire is a significant salary plus months of ramp before they are productive, and once hired, that person needs a platform-sized backlog to justify the role. There is a third option that this post lays out in detail: keep your AWS account, keep Kubernetes under the hood, and hand the cluster operations workload to a tool instead of a person. That lets you defer the hiring decision until your team genuinely needs a human platform engineer, rather than making the hire because the YAML got out of hand.
Almost nobody searching for Kubernetes alternatives dislikes what Kubernetes does. Rolling deploys, health-checked rollouts, autoscaling, service discovery, declarative infrastructure: these are exactly what a growing engineering team wants. What they are actually trying to escape is the standing operational workload of running Kubernetes themselves. It helps to name that workload concretely, because it is the evidence behind the hiring pressure you are feeling.
First, cluster version upgrades. Kubernetes moves on a fixed release cadence, and managed control planes like EKS enforce it: stay too far behind and you are forced into upgrades on AWS's schedule, not yours. Each upgrade means reading changelogs for deprecated APIs, testing workloads against the new version, and sequencing control plane and node group updates so nothing breaks mid-flight. Second, node management: choosing instance types, sizing node groups, handling the autoscaler's edge cases, patching AMIs, and draining nodes without dropping traffic. Third, ingress and TLS: an ingress controller to install and upgrade, certificate issuance and renewal to automate, and DNS wiring that has to be right in every environment.
Then there is the application-facing layer. Autoscaler configuration means writing and tuning HorizontalPodAutoscaler resources per service, and installing metrics infrastructure for anything beyond basic CPU. Helm chart maintenance means someone owns a growing pile of charts and values files that drift between staging and production. CI/CD plumbing means building and maintaining the pipeline that turns a git push into a safe, observable rollout with a working rollback path. None of these tasks is individually hard for a strong engineer. Collectively, they are a part-time job that never finishes, distributed across people who were hired to do something else. That is the real search intent behind "kubernetes alternatives": the capabilities without the standing job.
Once you frame the problem as "shed the operational workload, keep the capabilities," the market sorts into three categories. Each makes a different trade on the two things an engineering leader at your stage cares about most: where the infrastructure lives, and how much operational surface area your team still owns.
Path one: a fully managed PaaS off your cloud. Platforms in the Heroku lineage run your containers on their infrastructure, in their cloud accounts. Day-one experience is genuinely fast, and for a prototype that speed is the whole point. The cost shows up later, and it shows up in exactly the scenarios that keep you up at night: an enterprise prospect asks for VPC peering to your environment, and you cannot offer it because the environment is not yours. A customer contract requires data residency guarantees or a security review of the account hosting their data, and the honest answer is that a third party controls it. Your AWS spend commitments and credits do nothing for a bill paid to someone else. Migrating off AWS is a one-way door that looks cheap until the first customer asks you to walk back through it.
Path two: serverless containers. Services like AWS Fargate or Google Cloud Run keep you on your cloud and remove node management entirely, which is real progress. The constraints are architectural. These platforms are shaped around request-driven, stateless workloads. Long-running background workers, scheduled jobs with complex dependencies, services that need persistent attachment to data, and anything that assumes it can hold state between requests all require workarounds or companion services. You also still own a meaningful slice of the plumbing yourself: the CI/CD pipeline, the networking configuration, the service-to-service wiring, and the deployment orchestration that Kubernetes would have standardized. For a team running one API, it can be enough. For a team running a web tier, three workers, a cron layer, and a Postgres database, the workarounds accumulate.
Path three: a managed Kubernetes abstraction inside your own account. This category installs and operates a real Kubernetes cluster in your cloud account, then puts a simpler interface in front of it. You keep the account, the VPC, the billing relationship, and the compliance posture of infrastructure you own. The platform absorbs the upgrade, ingress, autoscaling, and deploy workload enumerated above. Several products occupy this category; the rest of this post covers how Convox implements it, because the implementation details are where the category's promise either holds or breaks.
The classic PaaS vs IaaS framing says you pick one: either a platform abstracts infrastructure away entirely, or you get raw infrastructure and build the platform yourself. Path one is pure PaaS, path two is IaaS with the servers hidden, and raw Kubernetes on EKS is IaaS with a very demanding platform layer bolted on. The third path is the interesting one precisely because it refuses the dichotomy. You get PaaS-grade developer experience, a manifest and a deploy command, layered on IaaS you own and pay for directly. The question "paas vs iaas" stops being either-or and becomes a question of which layer your team should operate. For a team of ten to thirty engineers with zero or one ops hires, the defensible answer is usually: operate neither, own both.
Here is what the third path looks like in practice with Convox managed Kubernetes. A Convox Rack installs a production EKS cluster into your AWS account, in your VPC, and then manages it: Kubernetes version upgrades, node groups, the ingress router and TLS certificates, autoscaling infrastructure, rolling deploys, and automatic rollback when a deploy fails health checks. You pay AWS directly for the infrastructure at AWS's own prices, with no Convox markup on that bill, because the resources run in an account Convox never owns. If you ever leave, the cluster and the account are yours; there is no data to repatriate and no environment to rebuild from scratch.
Your developers never touch the Kubernetes layer. They describe the application in a single manifest, convox.yml, that reads like a description of the app rather than a description of the cluster:
resources:
database:
type: postgres
services:
web:
build: .
port: 3000
health: /health
scale:
count: 1-3
targets:
cpu: 70
resources:
- database
worker:
build: .
command: bin/worker
resources:
- databaseWalk through what this fifteen-line file replaces. The web service with a port gets a load balancer, ingress routing, and a TLS certificate without anyone installing an ingress controller or cert-manager. The scale: count: 1-3 with a CPU target gives you autoscaling between one and three replicas without writing an HPA manifest or deploying a metrics server; the full options are in the scaling docs. The database entry under resources provisions Postgres and injects DATABASE_URL into every linked service, and the same manifest entry can later point at managed RDS without a code change. The worker service with no port runs as a background process with no load balancer, which is the part serverless container platforms make you work for.
Deploying is one command:
$ convox deploy -a myappThat builds the images, creates a release, and promotes it as a rolling update: start a new process, verify it passes its health check, stop an old one, repeat. If a new process fails to start or fails its health check, the rollout reverses automatically and the previous release stays live. Changing a replica count is equally direct:
$ convox scale web --count 3 -a myappTo make the surface-area difference concrete, here is the same set of concerns expressed in raw Kubernetes and in Convox:
| Concern | Raw Kubernetes on EKS | Convox Rack |
|---|---|---|
| HTTPS routing | Install and upgrade an ingress controller, configure Ingress resources, install cert-manager, manage issuers |
port: 3000 in convox.yml |
| Autoscaling | Deploy metrics-server, write HPA manifests per service, tune thresholds | scale: count: 1-3 with a CPU target |
| Deploys | Build CI pipeline, write Deployment manifests or Helm charts, script promotion and rollback | convox deploy with automatic rollback |
| Secrets | Base64-encode values, manage Secret manifests, wire envFrom per workload | convox env set KEY=val |
| Cluster upgrades | Track EKS release calendar, test API deprecations, sequence control plane and node upgrades | convox rack update |
| Who owns it | Your senior engineers, part time, forever | The platform, in your account |
A note for the team that already has one ops person: this is not a replacement for them. The solo infrastructure engineer at a company your size is usually the single point of failure for deploys, the only person who can safely touch the cluster, and the one who cannot take a real vacation. Moving the undifferentiated cluster toil to a managed Rack turns that person into the owner of the platform rather than its full-time janitor. They keep the AWS expertise, the account access, and the architectural decisions; they stop being the bottleneck between a developer and a deploy. Developers push with convox deploy, environment changes go through convox env, and every service deploys the same way, which makes releases reproducible instead of tribal knowledge.
An honest comparison names what the middle path costs, because an abstraction is a set of conventions and you are agreeing to live inside them. Convox has opinions about how services are built (from a Dockerfile), how they are exposed (through the Rack's managed router), and how they scale. For the large majority of web services, APIs, background workers, and scheduled jobs, those conventions are exactly what a platform engineer would have standardized anyway. But if your architecture genuinely requires a service mesh, bespoke Kubernetes operators, custom admission controllers, or unusual networking topologies, you have requirements the abstraction was not built to express. Convox does provide direct kubectl access to the underlying cluster for inspection and edge cases, but if your default workflow is kubectl, you are fighting the tool rather than using it.
The second honest limit is scale. At some size, a dedicated platform team becomes worth hiring: when you have enough services, enough engineers, and enough genuinely custom infrastructure requirements that platform work is a full-time differentiated function rather than toil. The argument of this post is not that you will never make that hire. It is that making it now, because the cluster is on fire, means hiring under duress to do work a tool can absorb. Deferring the hire until the need is a person-shaped problem rather than a maintenance-shaped one is simply better capital allocation. And because a Rack runs on standard EKS in your own account, adopting it does not foreclose the future: the cluster a platform team would eventually inherit is already there, in your VPC, under your billing.
There is also a smaller, practical trade: you are adding a vendor to your stack, and the platform's release cadence becomes something you track instead of the Kubernetes release calendar. The difference is that Rack updates are a command your team runs during a quiet window, not a multi-week upgrade project with API deprecation audits.
Three categories: fully managed PaaS platforms that host your apps on their infrastructure, serverless container services like Fargate or Cloud Run that remove node management but constrain workload shapes, and managed Kubernetes abstractions like Convox that run a real cluster inside your own cloud account while absorbing upgrades, ingress, autoscaling, and deploys.
Yes. The benefits teams actually want, rolling deploys, health checks, autoscaling, and rollback, do not require operating the cluster yourself. A managed Kubernetes abstraction delivers them through a simple manifest and a deploy command, so a team with zero or one ops hires ships on production Kubernetes without anyone owning cluster maintenance as a job.
No, and for most companies they should not. Fully managed PaaS options do move your workloads and data into the vendor's account, which breaks VPC peering, data residency, and AWS spend commitments. A Convox Rack installs into your existing AWS account and VPC, and you keep paying AWS directly with no Convox markup on that infrastructure.
For a team of five to thirty engineers, the best answer is usually both layered together: PaaS-style developer experience on IaaS you own. Pure PaaS trades away account ownership; pure IaaS hands your team a standing operations job. A managed abstraction in your own account gives developers push-to-deploy while the infrastructure, billing, and compliance posture stay yours.
Before the next planning cycle, run the decision framework against your own team's week. Add up the hours currently going to cluster upgrades, ingress and certificate issues, autoscaler tuning, Helm maintenance, and deploy pipeline care, and note whose hours they are. Then ask two questions: does the AWS account need to stay (customer contracts, VPC peering, data residency, spend commitments), and does your workload fit standard web services, workers, and scheduled jobs? If the hours are real, the account must stay, and the workload fits, the middle path is worth a pilot before a hire is worth a req.
The pilot is low stakes: install a Rack in a sandbox AWS account, deploy one real service with a convox.yml, and let a developer who has never touched the cluster ship a change end to end. Review how Convox manages Kubernetes in your account and what the platform costs next to the fully loaded cost of the hire you just deferred.
Create a free account and stand up your first Rack this week. If you want to talk through whether your workload fits before you pilot, reach out to our team.
