Aseptic vs Docker Compose vs local Kubernetes
All three come up in the same conversation —“how do we set up the local environment?”— and they solve different problems. This page says which is which, without pretending the other two are wrong: most teams end up using more than one, and Aseptic in fact leans on Docker for infrastructure.
In one sentence
- Docker Compose declares a set of containers and brings them up together. It is the standard tool for infrastructure, and for systems that run entirely in containers.
- Local Kubernetes (Kind, minikube, k3d) puts a Kubernetes cluster on your machine. Its reason to exist is resembling production: testing manifests, Helm charts, operators and policies.
- Aseptic is a desktop orchestrator for the daily loop: it brings up the services of a flow and, above all, decides where each one calls —another local service, the cloud, or a mock— rewriting the URLs without touching the repositories.
The table
| Criterion | Docker Compose | Local Kubernetes (Kind) | Aseptic |
|---|---|---|---|
| What it is for | Bringing up containers declared together | Reproducing Kubernetes locally | The daily loop with several services calling each other |
| How the system is described | A docker-compose.yml you write |
Manifests or charts, plus the cluster configuration | Autodetected from the repo (stack, ports, infrastructure, dependencies) for you to review |
| Where each service calls | Each repo's configuration, by hand | Cluster discovery; reaching outside is configured separately | Per dependency: local, cloud or mock. The engine rewrites the URL on start |
| Change loop | Rebuild the image; compose watch syncs or rebuilds |
Build, load into the cluster and deploy (Tilt or Skaffold automate it) | The service you are touching runs natively, with hot reload |
| Debugging | Attach the debugger to the container | Port-forward to the pod | Native process: your IDE's debugger, no middlemen |
| Shared infrastructure | Its strong suit | Another container or operator inside the cluster | Managed in Docker, remapping ports when one is taken |
| Faking someone else's service | Another container with a stub server, wired by hand | Same, plus manifests | Built in: set the dependency to mock and define the stub |
| Resemblance to production | Medium | High, and that is the whole point | Low on purpose: it optimises the loop, not fidelity |
| Sharing the setup | The file, versioned | Manifests, versioned | The scenario exports to a self-contained, importable file |
| Interface | Command line (plus Docker Desktop's) | Command line | Window and CLI, with the same logic behind both |
| Licence | Open source | Open source | Proprietary: free for personal use, paid for use inside an organisation |
| Requirements | A Docker engine | Docker and a fair amount of memory | Windows, macOS or Linux, and a Docker engine for the infrastructure |
Stick with Docker Compose if…
-
What you need is the infrastructure: databases, queues, caches.
Nothing beats it there, and Aseptic does not replace it — in fact it
reads your
docker-compose.ymlto know what you have declared, and never writes it. - Your system is two or three stable services you do not touch daily. Bringing them all up in containers and forgetting about them is simpler than anything else.
- You need it to work the same on any machine and in CI, with one tool and nothing else to install.
Stick with local Kubernetes if…
- What you are developing is Kubernetes: manifests, charts, operators, network policies. Testing them outside a cluster proves nothing.
- You need to reproduce behaviour that only shows up in the cluster —the service mesh, an ingress, resource limits—.
- You already have Tilt or Skaffold set up and the build loop does not hurt.
Take Aseptic if…
- The flow you are testing goes through several services, and each one calls others you do not always want to bring up.
- You often change where a dependency points —today at the shared environment, tomorrow at the colleague who has it running, the day after at a mock because there is no VPN— and you are tired of editing configuration in repositories that are not yours.
- You want to change something and see the effect now: the service you are working on running natively with hot reload, and the rest in containers in the background.
-
Everyone who joins the team loses their first day to a
LOCAL_SETUP.mdnobody maintains.
Where Aseptic falls short
A comparison that only says good things about whoever wrote it is worth nothing.
- It does not resemble production, and it does not try to. If your problem is something that only fails in the cluster, this will not reproduce it.
- It does not speak Kubernetes. It reads no manifests or charts, and there are no plans to.
- Windows, macOS and Linux.
- It is in beta, and it shows: it changes often.
- It is not open source, and using it at work requires a paid licence. Compose and Kind are free for any use; this is a product, and that should be said before you run into it.
-
Every service has to be described once. Almost everything is
autodetected, but that first review is work you would not have with a
composefile that already exists.
What usually ends up happening
All three coexist without conflict: compose for the shared
infrastructure —which Aseptic reads and manages—, local Kubernetes for what
really is Kubernetes and for CI, and Aseptic for the stretch where you are
changing code and need the whole flow to answer without assembling it by hand
every time.
One-to-one comparisons
Docker Compose and a local Kubernetes are the two answers you meet first, but they are not the only ones. If a specific tool is on your shortlist:
- Aseptic vs Tilt — a fast inner loop against a cluster, with a UI for builds and logs.
- Aseptic vs Skaffold — build, push and deploy as one command, with profiles.
- Aseptic vs DevSpace — your code running in a development container inside the cluster.
- Aseptic vs Garden — a dependency graph for build, deploy and test, shared with CI.
- Aseptic vs Telepresence — one local process wired into a real cluster.
- Docker Compose alternatives — the whole field on one page, ours included.
- Aseptic vs Docker Compose and Aseptic vs Testcontainers, one to one.
And by stack: Spring Boot, Quarkus and Node.
Frequently asked questions
Docker Compose, local Kubernetes or an orchestrator?
Compose if your system is small and stable; local Kubernetes if what you are testing is the Kubernetes layer itself; a local orchestrator if what weighs is the daily loop of working across several services at once.
Can I use more than one?
It is the norm, and it is not contradictory: they coexist well because they do not solve the same layer. The expensive mistake is using the cluster for the day-to-day loop too.
What does none of them solve on its own?
Deciding, per dependency, whether a call goes to the local service, to the shared environment or to a mock, and applying it without editing the repositories.