The rise of Claude, Cursor, Gemini, and Codex has created a new kind of infrastructure problem for sysadmins: applications that are built in hours, but arrive in production with architecture decisions made by prompt. And one pattern keeps repeating. Ask an agent to build something “scalable” and “production-ready,” and the answer often includes Docker, Terraform, CI/CD, observability, Helm, and, if nobody intervenes, Kubernetes as well. The README looks polished, but the operational burden often does not match the actual size of the product.
In practice, many small and mid-sized products do not need that level of orchestration to run well in production. Docker Compose remains a valid option beyond local development, Kamal has emerged as a clean middle ground for zero-downtime deploys on your own servers, and Terraform is still the most sensible baseline when you want infrastructure as code and at least some freedom to move across providers later. The real decision is no longer “cloud or no cloud.” It is how much lock-in you should accept, and how much portability is actually worth paying for in advance.
The core rule: partial abstraction, selective lock-in
The most useful answer in 2026 is not especially glamorous, but it works: build for partial abstraction and selective lock-in. Trying to create a perfectly cloud-agnostic platform from day one usually costs more in time, complexity, and operational drag than the theoretical benefit of being able to migrate overnight. Terraform fits this reality well because it lets teams define and version infrastructure such as compute, networking, storage, DNS, and even SaaS integrations using the same infrastructure-as-code approach across different providers. HashiCorp’s own documentation describes Terraform as a tool for building, changing, and versioning infrastructure on cloud and on-prem resources.
That does not mean every layer should be abstracted equally. It makes sense to encapsulate compute, network, DNS, firewalls, variables, and deployment workflows, because moving those later is usually manageable. But accepting some lock-in around managed databases, object storage, CDN, or WAF can be the right trade if it saves weeks of engineering effort. Cloudflare is a good example: it provides DNS, edge proxying, and WAF capabilities that dramatically reduce operational load, even if they also introduce a dependency. That is often a very good bargain for a small team.
Why Docker Compose is still enough more often than people admit
One of the most common mistakes in AI-assisted projects is dismissing Docker Compose too early as “development-only.” Docker’s own documentation says otherwise. Compose defines and runs multi-container applications from a single YAML configuration and works across production, staging, development, testing, and CI workflows. It is not a distributed scheduler like Kubernetes, but for a product that consists of a backend, frontend, database, Redis, workers, and a reverse proxy, it is still a perfectly valid production option if your scale and topology are modest.
Its biggest advantage is operational clarity. A Compose stack is easy to version, easy to reproduce, and easy to understand at a glance. Add a reverse proxy such as Traefik in front, and you get routing and service discovery without jumping into a much heavier platform. For many sysadmins, that combination is enough to carry a product far longer than architecture diagrams tend to suggest.
Kamal: the middle ground that makes more sense every month
Kamal is becoming one of the most compelling responses to infrastructure overkill. Its pitch is straightforward: deploy containerized applications to bare metal or cloud VMs using Docker and SSH, with zero-downtime deploys, rolling restarts, remote builds, and support for accessory services. The official site frames it as a way to deploy web apps anywhere, from bare metal to cloud VMs, without being forced too early into expensive platforms or complex orchestration.
That makes Kamal highly attractive for teams that want more discipline than hand-written shell scripts but less operational overhead than Kubernetes. It is not a universal replacement for a cluster scheduler, but it covers an important middle zone extremely well: your own servers, your own containers, deployments over SSH, and a level of automation that is strong enough for serious production use.
A quick decision table for sysadmins
When choosing a deployment model, the most useful question is rarely “what do the best DevOps teams use?” It is “what will this product actually need over the next 12 to 18 months?”
┌──────────────────────────────┬───────────────────────────────┬────────────────────────────┬──────────────────────────────┐
│ Scenario │ Recommended approach │ Main advantage │ Main risk │
├──────────────────────────────┼───────────────────────────────┼────────────────────────────┼──────────────────────────────┤
│ Fast MVP │ Vercel / Railway / Render │ Fastest path to production │ Less control / more lock-in │
│ Small or midsize SaaS │ Docker + Compose + Terraform │ Simplicity and low cost │ Manual ops grow over time │
│ Small SaaS with better ops │ Kamal + Terraform + Traefik │ Zero-downtime without K8s │ Smaller ecosystem than K8s │
│ Multi-service backend │ Nomad + Terraform │ Simpler scheduler model │ Less standardization │
│ Complex internal platform │ Kubernetes + Helm + IaC │ Scale and standardization │ Heavy operational overhead │
└──────────────────────────────┴───────────────────────────────┴────────────────────────────┴──────────────────────────────┘
And if the question becomes provider-specific, the current landscape looks roughly like this:
| Option | What it gives you | Best fit | Lock-in level |
|---|---|---|---|
| Vercel | Git-based deploys, preview environments, strong web and AI app workflow | Frontend-heavy apps, fast-moving web teams | High |
| Railway | All-in-one platform, CLI, databases, services, domains, environments | Small to midsize teams that want speed | Medium-high |
| Render | Web services, jobs, databases, rollbacks, observability | Teams wanting a broader PaaS model | Medium-high |
| Hetzner Cloud | Cloud servers, private networking, firewalls, API, strong cost profile | Teams that want control and lower cost | Low-medium |
| AWS / Azure / GCP | Broadest service catalogs and enterprise ecosystem | Complex or enterprise workloads | Variable, depending on services used |
Hetzner, Cloudflare, and Traefik: the pragmatic European stack
One combination that keeps showing up in real-world deployments is Hetzner for compute, Cloudflare for DNS, SSL, and WAF, and Traefik as the internal reverse proxy. The appeal is obvious. Hetzner offers cloud servers, private networks, stateful firewalls at no additional cost, and an API suitable for automation. Its own documentation highlights private networking for non-public databases and firewalls that can be assigned to as many cloud servers as needed.
Put Cloudflare on top for edge security and DNS, add Traefik for ingress and routing inside the stack, and you get something that is not fully cloud-agnostic, but is abstracted enough that changing the VPS provider later does not mean redesigning the application itself. For many European teams, especially cost-sensitive ones, that is a very sensible production recipe.
And when does Kubernetes actually make sense?
Kubernetes still matters when you truly need a distributed scheduler, standardized deployment primitives, multiple teams shipping many services, autoscaling, and a stronger operational model for complex workloads. But that power comes with real cost: more observability, more tooling, more learning, more maintenance, and more moving parts. If those needs are not already present, Kubernetes often behaves less like a scaling solution and more like an up-front tax. That is why many teams are better served by Compose, Kamal, or even Nomad until the system genuinely grows into cluster complexity.
The best architecture for an AI-built product is not the one that looks most impressive on a diagram. It is the one that can be deployed cleanly today, rolled back quickly tomorrow, and scaled without turning infrastructure into the real product. In that equation, containerization is no longer the hard part. The hard part is deciding how much orchestration you actually need.
FAQ
Is Docker Compose really suitable for production?
Yes. Docker’s official documentation states that Compose works in production, staging, development, testing, and CI workflows, and it supports running multi-container applications from a single YAML configuration.
Can Kamal replace Kubernetes for a small SaaS product?
In many cases, yes. Kamal provides zero-downtime deploys, rolling restarts, remote builds, and accessory service support using Docker and SSH, which makes it a strong fit for small and midsize products without Kubernetes-level complexity.
What is the practical advantage of Terraform over configuring everything manually?
Terraform lets teams define, change, and version infrastructure as code across cloud and on-prem resources, including compute, storage, networking, DNS, and SaaS features. That makes environments more reproducible and easier to migrate or audit.
Is Hetzner a serious option for staging and production?
Yes. Hetzner Cloud offers cloud servers, private networks, firewalls, API access, and infrastructure features that are fully viable for production workloads, especially for teams that want lower cost and more control.