Beyond Kubernetes: 5 Simpler Alternatives for Small Teams

Kubernetes is an extraordinary piece of engineering. It is also overbuilt for most small teams. Under about fifteen engineers, without hundreds of services, you are paying a complexity tax that buys very little: etcd, RBAC policies, ingress controllers, CRDs, and the hours those consume every month.

The alternatives got genuinely viable somewhere in the last two years. Not toy-grade, production options that trade infinite flexibility for the thing that is actually scarce at small scale.

Checked on 21 August 2026, and one of these five changed status since this was written.

Pick the lowest rung that holds

Docker Swarm, the one you already know

If your team uses Compose locally, and it probably does, Swarm is the shortest path to multi-node production. It extends concepts you already have, services and networks and compose files, across a cluster. Initialize on one node, join workers with a token, docker stack deploy your existing file. Rolling updates, health checks, service discovery all included. No Helm, no kubectl.

The catch is that Swarm is in maintenance mode. It still ships with every Engine release and is supported into the next decade, but feature development effectively stopped. What is there is what you get.

There is also a practical ceiling. Dozens of services across a handful of nodes is comfortable. Past that you start feeling the missing pieces: sophisticated scheduling, autoscaling, real observability.

Best when production looks like a few backend services, a database, a cache, and a worker queue.

Nomad, the quiet workhorse

Nomad solves many of the same problems with dramatically less apparatus. It is a single binary. No etcd, no separate API server, no controller manager; one process schedules and orchestrates and manages the cluster.

The job spec is HCL, which is more readable than the YAML equivalent, and that is not a small thing when you are reading a deployment at 2am. A typical web service job is maybe thirty lines against a Deployment plus Service plus Ingress plus ConfigMap that runs well past a hundred.

What actually distinguishes it is workload flexibility. Kubernetes is about containers. Nomad runs containers, and also standalone binaries, Java applications, VMs, and batch jobs. A mixed estate with a containerized API next to a legacy service running directly on the host fits without contortion.

Where it falls short is everything built around it. Kubernetes has an enormous supply of third-party tooling for monitoring, meshes, GitOps, policy. With Nomad you lean on HashiCorp’s own stack, and if you are not already there that is more to learn. The community is thinner too, so you spend more time in documentation and less time finding that someone already hit your exact problem.

Best when you want real orchestration without the operational weight, especially if Terraform is already in the building.

Cloud Run, containers without a cluster

Orchestration stripped to its minimum surface. Hand over an image, say how much CPU and memory, and scaling and load balancing and TLS and networking are handled. There is no cluster to manage because there is no cluster.

The billing model suits small teams: per request and per vCPU-second of actual compute, so variable traffic costs near nothing during the quiet hours instead of keeping nodes warm. The free tier genuinely covers a low-traffic service indefinitely.

The constraints are real and architectural. Services are stateless and ephemeral, scale to zero means cold starts, WebSocket support exists with limits, and background processing is possible rather than natural. It is built for HTTP services, not long-running workers or anything needing persistent connections. Debugging happens through a logging console rather than by reading a file on a box, which some people find fine and others find maddening.

And you are on Google Cloud. If portability matters, that is the whole conversation.

Kamal, deploy anywhere you can SSH

The most refreshingly small tool here. It deploys containers to any server you can reach over SSH. No control plane, no cloud account required. Point it at a box, bare metal or a cheap VPS or an EC2 instance, and it builds the image, pushes it to a registry, pulls it on the server, and swaps traffic with no downtime.

Kamal 2 replaced Traefik with its own proxy, which simplified the stack again, and it is now past version 2.12. Configuration is one readable YAML file. It ships as the default deployment tool in Rails 8 and there is nothing Rails-specific about it.

The mental model is Capistrano for Docker. If you have ever deployed by SSHing in and pulling, this is that, automated, with zero-downtime swaps.

What you give up is orchestration. You can deploy to several servers but there is no service discovery, no failover between hosts, no cluster-aware scheduling, and load balancing across boxes is something you set up yourself. Scaling is manual: provision a server, add it to the config. That is not a limitation for a lot of teams, it is the entire point, but if you need containers to reschedule themselves when a node dies, this is not trying to do that.

Best for teams on their own boxes who want repeatable deployments and no lock-in.

ECS, and the thing that changed

If you are on AWS, ECS with Fargate is the natural alternative. Task definitions instead of pod specs, services on top, and no EC2 instances to manage.

The update since this was written: AWS App Runner stopped accepting new customers on 30 April 2026. Existing services keep running, and AWS points new users at ECS Express Mode instead. If a comparison post recommends App Runner to you today, it was written before that.

Express Mode is the interesting part. One API call with a container image and two IAM roles provisions the whole stack in your account: an ECS service on Fargate, an Application Load Balancer, autoscaling, networking. There is no additional charge for Express Mode itself; you pay for the resources it creates. It reached GovCloud regions in June, which is usually the sign a service is considered finished rather than experimental.

That is App Runner’s simplicity on ECS’s foundation, and it tells you where AWS consolidated. The Copilot CLI is also winding down, which is the same story from another direction.

Standard ECS with Fargate is more verbose to set up than Cloud Run or Kamal, and in exchange you get real autoscaling, tight integration with the rest of AWS, and a path to more complex setups without changing platforms. It is also deeply AWS-specific in a way that makes leaving a rewrite rather than a migration.

Choosing

One or two services on boxes you already pay for: Kamal.

A compose file you want on more than one machine: Swarm, accepting that it will not grow much past that.

HTTP services with spiky traffic and a Google account: Cloud Run.

HTTP services and an AWS account: ECS Express Mode, not App Runner.

Mixed workloads, real scheduling, no appetite for a control plane: Nomad.

And Kubernetes when you have many services, several teams touching them, and someone whose actual job is the platform. That last condition is the one people skip. Kubernetes is not expensive because of the cluster. It is expensive because it assumes a person who owns it, and on a small team that person is also the one supposed to be shipping.