Leaving AWS: the open-source equivalent for every managed service
TL;DR. Every AWS managed service has a mature open-source equivalent you can run yourself — ECS → Kamal or Nomad, ECR → Harbor, WAF → Coraza + OWASP CRS, Terraform → OpenTofu. But the more useful truth is that most small and scale-up businesses need far less of this than AWS sold them. The cloud’s managed catalog is priced and designed for the largest tenants; replicating all of it off-cloud is usually a mistake. The honest move is to map only the parts you actually use, replace them with boring open-source tools, and keep the one thing the cloud genuinely does better — true elastic autoscaling (servers added and removed automatically as traffic rises and falls) — only if your load really needs it.
The objection this page answers
If you leave AWS, the fear isn’t the servers — it’s the services. ECS runs your containers, ECR stores your images, Auto Scaling handles spikes, WAF blocks attacks, Terraform builds it all. Give those up and you’re back to bare metal in 2009, right?
No. Each has an open-source equivalent that’s owned, portable, and free of per-request metering. The catch isn’t availability — it’s that the cloud trained you to assume you need all of them. You usually don’t.
The mapping — one open-source equivalent per service
All genuinely open-source unless noted. Prices and licenses mid-2026 — verify before relying on them.
| AWS service | What it does | Open-source / owned equivalent | The honest note |
|---|---|---|---|
| ECS / Fargate | Run & schedule containers | Kamal, Docker Compose (single node), Nomad, Docker Swarm, k3s / k0s | Most SMBs are one or two boxes → Kamal or Compose. An orchestrator is often the thing you were escaping. |
| ECR | Container registry | Harbor, Zot, plain registry:2, or the registry built into Gitea / Forgejo / GitLab | A registry is a small, boring service with near-zero ops. |
| Auto Scaling | Add/remove capacity with load | k8s HPA + cluster-autoscaler, Nomad Autoscaler, Hetzner hcloud autoscaler | ⚠️ The honest one — see the dedicated section below. |
| WAF / Shield | Block attacks & bad traffic | Coraza (Go, the ModSecurity successor) + OWASP Core Rule Set, BunkerWeb, SafeLine, NAXSI | Cloudflare’s free WAF at the edge covers most cases with zero self-hosting. |
| Terraform | Infrastructure as code | OpenTofu (drop-in open fork), Pulumi, Ansible, Crossplane | Terraform itself is now source-available (BUSL), not open. OpenTofu is the truly-open fork — see Terraform vs OpenTofu. |
| CloudFormation | AWS-native IaC | OpenTofu / Pulumi (multi-cloud, portable) | Leaving CloudFormation behind is a feature — it locks you to AWS. |
| Secrets Manager / SSM | Secrets storage | Infisical, OpenBao (the open Vault fork), HashiCorp Vault, SOPS + age | A small encrypted store + an env file covers most teams. |
| CloudWatch | Metrics, logs, alerts | Prometheus + Grafana + Loki | See the CloudWatch cost page — this is one of the easiest, highest-margin moves. |
| S3 | Object storage | MinIO → SeaweedFS, Garage, or Cloudflare R2 | See Migrate off MinIO and S3 egress cost. |
| RDS | Managed Postgres/MySQL | Self-run Postgres + pgBackRest, or a flat-rate managed DB (OVH/Hetzner) | The one many teams should keep managed — the labor saved is real. Price it honestly. See RDS backups + EBS snapshots without AWS. |
The hero: Kamal — the tool built to leave the cloud
If you remember one name, make it Kamal. It’s the open-source deploy tool 37signals (Basecamp / HEY) wrote specifically to run their apps on owned hardware after leaving the cloud — the same move behind the ~$2M/year they reported saving. Kamal does zero-downtime container deploys onto any Linux box you can SSH into, works with any registry, and bundles a reverse proxy and health checks. For a business running a handful of services it replaces ECS, the deploy pipeline, and most of the orchestration layer in one boring tool. Compose for a single node, Kamal across a few, Nomad or k3s only when you genuinely outgrow them — that’s the whole ladder.
The honest exception: Auto Scaling
This is the one place where “there’s an open-source equivalent” deserves an asterisk. Tools like the Kubernetes cluster-autoscaler and Nomad Autoscaler do exist and do work — on a provider with an instance API (Hetzner Cloud, OVH, etc.) you can add and remove nodes automatically. But true elastic scale-to-zero for spiky, unpredictable load is the single thing the hyperscalers (AWS, Azure, Google) genuinely do better, and it’s the real reason some workloads should stay.
The honest answer for most flat-rate setups isn’t “reimplement Fargate” — it’s provision for your peak and it’s still cheaper than the autoscaled cloud bill. A flat box you rent 24/7 sounds wasteful next to scale-to-zero, until you do the math: a server sized for peak on OVH/Hetzner routinely costs less per month than the autoscaled AWS bill for the same peak, because you’re not also paying egress and per-request fees on every request the autoscaler served. Autoscaling saves money against on-demand cloud pricing; it rarely beats a flat box on price.
When the cloud’s autoscaling genuinely wins (and you should keep that workload there):
- Load is truly spiky and unpredictable — idle most of the time, with sharp, irregular bursts.
- You benefit from scale-to-zero — you’d pay for capacity you don’t use the rest of the time.
- Traffic is global and latency-sensitive in a way a CDN in front of a flat box can’t satisfy.
That’s not a cop-out; it’s the same “do NOT move this” honesty as the rest of these guides. If autoscaling is the only AWS service you truly depend on, leaving may not be worth it — and a good assessment says so.
What you can usually delete entirely
A chunk of the AWS catalog exists to manage complexity that only exists because you’re on AWS. Leaving doesn’t require replacing it — it makes it disappear:
- NAT Gateways, VPC peering, PrivateLink, Transit Gateway — networking plumbing (and metered fees) you mostly don’t have on one or a few owned boxes.
- CloudFormation / heavy IaC — useful at fleet scale; for a handful of services, OpenTofu plus a few scripts, or even documented Compose files, is enough.
- Service mesh, API Gateway, sidecars — frequently introduced to tame a sprawl of microservices that a smaller, simpler deployment never needed in the first place.
The goal isn’t to rebuild AWS on Hetzner. It’s to run the actual workload with the least moving parts that still meets your reliability needs.
How to do this without rebuilding AWS
- List what you actually use. Open the bill and the architecture diagram and write down the managed services that are genuinely load-bearing. Most teams are surprised how short the list is.
- Map only those. Use the table above. Ignore everything you don’t use.
- Pick the lowest rung that works. Compose → Kamal → Nomad/k3s. Don’t adopt Kubernetes to leave Kubernetes.
- Put a free edge in front. Cloudflare (free WAF + cache) removes the WAF and a lot of egress at once.
- Keep what’s genuinely worth managing. Often the database, sometimes truly spiky compute. Price the labor honestly and leave those where they win.
The bottom line
There is an open-source equivalent for essentially every AWS managed service, and for the ones that matter to a small business they’re mature and boring: Kamal/Nomad, Harbor, Coraza, OpenTofu, Prometheus/Grafana. The discipline isn’t finding replacements — it’s resisting the urge to replace everything. Leave behind the services that only existed to manage AWS’s own complexity, keep the one or two the cloud does better, and own the rest.
Which of these you actually need — and which you can delete — is exactly what a Cloud-Exit Assessment maps out, with a target design on owned or flat-rate infrastructure and honest numbers. Or send me your cloud bill and I’ll tell you, free, in 24 hours, which managed services are worth keeping and which are just AWS tax. Read by me, never shared.
Sources
- Kamal (open-source, MIT) — kamal-deploy.org; built by 37signals to deploy onto owned servers.
- 37signals ~$2M/year cloud-exit saving — David Heinemeier Hansson’s “leaving the cloud” write-ups (world.hey.com).
- Nomad, Vault (HashiCorp, BUSL) and OpenTofu / OpenBao (the open forks under the Linux Foundation) — opentofu.org, openbao.org.
- Harbor (CNCF graduated) and Zot — goharbor.io, zotregistry.dev.
- Coraza (OWASP, Apache-2.0) + OWASP Core Rule Set, BunkerWeb, SafeLine — coraza.io, coreruleset.org.
- Cloudflare free WAF / CDN — cloudflare.com plans (free tier).
- Terraform BUSL relicense (why OpenTofu exists) — HashiCorp’s 2023 license-change announcement.
- k8s cluster-autoscaler / HPA and Nomad Autoscaler — the respective project docs.