Platform engineering without Kubernetes: a simpler path for small teams

Platform engineering has become the hottest topic in DevOps. Every conference talk, every vendor pitch, every "getting started" guide assumes the same stack: Kubernetes, Backstage, Crossplane, ArgoCD. The message is clear. If you want a real developer platform, you need to go all-in on K8s.

But what if your team has 10 developers and three services? What if you are running a SaaS product that serves thousands of users reliably from a single server? You still deserve a good platform. You just do not need Kubernetes to build one.

This post lays out a practical, battle-tested platform engineering approach for small teams. No K8s. No managed clusters. No $2,000/month infrastructure bill. Just a clean path from code to production that your developers will actually enjoy using.

What platform engineering actually means

Strip away the buzzwords and platform engineering is about one thing: building a paved road from code to production. A road that developers can walk without needing to understand every piece of infrastructure along the way.

Gartner predicts that by 2026, 80% of software engineering organizations will establish platform teams as internal providers of reusable services. But the definition of "platform" is not prescriptive. It does not say Kubernetes anywhere. A platform is whatever system lets your developers ship code confidently without filing tickets or SSH-ing into servers.

The core principles are consistent regardless of scale:

• Self-service. Developers push code and it reaches production without manual intervention.
• Automation. Builds, tests, deployments, TLS certificates, monitoring, and backups all happen without human steps.
• Observability. Everyone can see what is deployed, whether it is healthy, and what happened when something broke.
• Reproducibility. Environments are defined in code. Nothing is hand-crafted or tribal knowledge.

The specific tools are secondary. What matters is that those principles are met. And for a team of 2-30 developers, you can meet every single one of them without touching Kubernetes.

The K8s-free platform stack

Here is a complete platform stack that delivers the same developer experience as a K8s-based platform, at a fraction of the cost and complexity. Every component is production-proven and widely adopted.

Container runtime: Docker (or Podman)

Docker remains the industry standard for containerization. Every developer knows it, every CI system supports it, and it runs identically on laptops and servers. For teams that prefer a daemonless, rootless alternative, Podman is a drop-in replacement. Either works. The important thing is that your apps run in containers, which gives you portability, isolation, and reproducible builds.

Orchestration: Docker Compose

Docker Compose is not just for local development. It is a perfectly valid production orchestration tool for teams running a handful of services. A single docker-compose.yml file defines your entire application stack: services, networks, volumes, health checks, restart policies, and resource limits. It is version-controlled, reviewable, and easy to reason about. For most teams under 30 developers, Compose does everything K8s does, just with less ceremony.

CI/CD: GitHub Actions, GitLab CI, or Woodpecker

Continuous integration and continuous delivery are the backbone of any platform. The choice depends on where your code lives. GitHub Actions is excellent for teams already on GitHub, with generous free tiers and a massive marketplace. GitLab CI is tightly integrated if you are on GitLab. Woodpecker is a lightweight, self-hosted option if you want full control over your build infrastructure. We have compared all three in detail. The pipeline pattern is the same: push code, run tests, build an image, tag it, push it to a registry.

Reverse proxy: Traefik with auto-TLS

Traefik is purpose-built for containerized environments. It discovers services automatically through Docker labels, handles TLS certificate generation via Let's Encrypt, and manages routing without manual configuration files. Add a new service to your Compose file with the right labels, and Traefik picks it up. HTTPS just works. No Nginx config files to maintain, no manual certbot renewals. We compared Traefik, Nginx, and HAProxy, and for Docker-based platforms Traefik wins on simplicity every time.

Deployment: Komodo, Watchtower, or custom CD

This is the layer that ties CI to your running infrastructure. Komodo is an open-source deployment tool that watches your Docker registry and manages container deployments across servers. Watchtower is simpler: it monitors running containers and automatically pulls new images when they appear. For teams that want full control, a custom CD script triggered by a webhook works too. The key is that deployments happen automatically when a new image is tagged. We compared CD tools including ArgoCD, Flux, and Watchtower if you want to explore the options.

Monitoring: Prometheus + Grafana + alerting

Prometheus scrapes metrics from your containers and infrastructure. Grafana turns those metrics into dashboards your team can actually use. Together they give you CPU, memory, disk, request rates, error rates, response times, and anything custom your application exports. Add alerting rules and you get notified before your users notice a problem. This is the same monitoring stack that companies 100x your size use. The only difference is you are running it on one server instead of a cluster.

Secrets: 1Password, Infisical, or Vault

Secrets management is non-negotiable. We have compared the major options. For small teams, 1Password with its CLI and service accounts is remarkably effective: secrets are injected at deploy time, never stored in git, and rotated through a UI your team already knows. Infisical is a strong open-source alternative with native Docker and CI integrations. HashiCorp Vault is the enterprise standard if you need advanced policies and audit trails. Pick the one that matches your team size and compliance requirements.

Backup: Restic with automated schedules

Backups are the part of the platform nobody thinks about until they need them. Restic is fast, encrypted, and supports multiple backends including S3, Backblaze B2, and local storage. Wrap it in a cron job or a container with a scheduler, and you get daily encrypted backups with retention policies, automatic pruning, and Prometheus metrics so you know when a backup fails. The entire setup is a single Docker container and a config file.

Documentation: README-driven, runbooks in repo

The final piece of a platform is documentation. Not a wiki that nobody updates, but runbooks that live next to the code they describe. How to deploy. How to rollback. How to add a new service. How to respond to an incident. When documentation lives in the repo, it gets reviewed in pull requests and stays current. When it lives in Confluence, it drifts.

What this looks like in practice

Let us walk through a typical deployment on this stack. A developer opens a pull request. CI kicks off automatically: linting, tests, security scans. The PR gets reviewed and merged. CI builds a Docker image, tags it with the git SHA and a semantic version, and pushes it to a private registry.

The CD tool detects the new image. It pulls it, stops the old container, starts the new one, and verifies the health check passes. Traefik automatically routes traffic to the new container. Grafana shows the deploy as an annotation on the dashboard. If response times spike or error rates jump, the alert fires.

If something breaks, you roll back by deploying the previous image tag. One command or one click, depending on your CD tool. The entire flow is automated. No SSH. No manual Docker commands. No copying files to a server. The developer's experience is identical to what they would get on a K8s-based platform: push code, see it live.

Zero downtime deployments? Achievable with Docker Compose and Traefik through rolling restarts and health checks. Blue-green deployments? Spin up the new version, switch the Traefik route, tear down the old one. You do not need K8s primitives to get deployment safety.

Cost comparison

Numbers make the case better than arguments. Here is what each approach costs for a typical small team running 3-10 services.

K8s-based platform: Managed EKS/GKE at $73/month for the control plane, plus 3 worker nodes at $150-$400/month each, plus a load balancer at $20/month, plus Backstage hosting, plus ArgoCD, plus the time to operate it all. Realistic monthly cost: $1,000-$2,000 in infrastructure alone. Add a dedicated platform engineer at $120K-$180K/year to keep it running.

Docker-based platform: A single VPS at $20-$80/month handles most small team workloads. A second server for redundancy brings it to $40-$160/month. Traefik, Prometheus, Grafana, and your CD tool all run on the same infrastructure. GitHub Actions CI is free for public repos and $4/month for private repos on the Team plan. Total infrastructure cost: $40-$160/month. Operations time: a few hours per month once the platform is set up.

That is a 10-20x difference in infrastructure costs. And the developer experience, the thing that actually affects your team's velocity, is equivalent. Your developers push code and see it deployed. They check dashboards for metrics. They get alerts when things break. The underlying machinery is different, but the interface is the same.

For a deeper breakdown of DevOps costs across different team sizes, read our full cost analysis.

When you actually need Kubernetes

This is not an anti-Kubernetes post. K8s is excellent software that solves real problems. The issue is that those problems do not match most small teams. Here are the concrete signals that you have outgrown a Docker-based platform:

• 30+ microservices. When you have dozens of services with complex interdependencies, K8s service discovery, health checking, and orchestration start earning their complexity.
• Multi-region deployments. If you need to run the same workloads in US-East, EU-West, and APAC, Kubernetes federation and managed services simplify what would be very manual otherwise.
• Auto-scaling requirements. If your traffic is spiky and you need to scale from 2 replicas to 20 within minutes, K8s HPA (Horizontal Pod Autoscaler) is purpose-built for this. Docker Compose does not have an equivalent.
• Compliance and audit requirements. SOC 2, HIPAA, or PCI compliance at scale often requires the kind of namespace isolation, RBAC, and network policies that K8s provides natively.
• Multiple teams deploying independently. When 5+ teams need to deploy to shared infrastructure without stepping on each other, K8s namespaces and resource quotas provide guardrails that are hard to replicate with Compose.

If none of those describe your situation, Kubernetes adds complexity without adding value. And complexity has a cost: longer onboarding times for new developers, more things that can break, more specialized knowledge required to debug production issues. For teams where the CTO is also writing code, that cost is especially steep.

How to get started

The best platform strategy starts with what you already have and adds layers incrementally. Each step delivers value on its own, so you do not need to build the entire stack before seeing results.

Step 1: Containerize your applications. Write Dockerfiles for every service. Use multi-stage builds to keep images small. Make sure each service starts with docker compose up locally. This alone eliminates "works on my machine" problems and cuts onboarding time from days to hours.

Step 2: Add CI/CD. Set up a pipeline that runs tests on every push and builds a Docker image on merge to main. Use semantic versioning or git SHA-based tags. Push images to a private registry. This step eliminates manual build processes and catches bugs before they reach production.

Step 3: Automate deployments. Connect your CI pipeline to your production server. When a new image is built, deploy it automatically. Add health checks so bad deployments are caught immediately. This is where your team stops doing manual deployments and starts shipping with confidence.

Step 4: Add monitoring and alerting. Deploy Prometheus and Grafana. Set up dashboards for each service. Configure alerts for high error rates, slow response times, and resource exhaustion. Your team starts seeing production as a dashboard instead of a black box.

Step 5: Secure secrets and backups. Move all secrets out of environment files and into a proper secrets manager. Set up automated, encrypted backups with tested restores. These two steps are what separate a "we have containers" setup from a production-grade platform.

Step 6: Document everything. Write runbooks for common operations: deploying, rolling back, adding a new service, responding to incidents. Put them in the repo, not a wiki. Review them in PRs. A platform without documentation is just infrastructure that one person understands.

This entire journey can take 2-4 weeks with focused effort, or be done in a few days with experienced help. The important thing is that you start. Every step forward reduces risk and gives your developers time back.

Start with what fits your team

Platform engineering is not about using the most sophisticated tools. It is about giving your developers a reliable, automated path from code to production. For teams with 2-30 developers, a Docker-based platform delivers everything you need at a cost and complexity level that actually makes sense.

The goal is not to avoid Kubernetes forever. It is to avoid adopting it before you need it, which is a mistake that has sunk countless small engineering teams. Build the platform that fits your team today. If you outgrow it, migrating to K8s from a well-containerized, well-monitored Docker setup is straightforward. Migrating from chaos to K8s is not.

If you want help building a platform for your team, take a look at our platform engineering service. If you already have infrastructure and want to know where the gaps are, our infrastructure audit is a good starting point. And if you need someone to manage the platform after it is built, that is what managed DevOps is for.

Related reading

• Internal developer platforms for small teams
• Why your team does not need Kubernetes