Aseptic vs Docker Compose
Nearly everyone starts here, and rightly so: a docker-compose.yml and one
command bring up Kafka, Redis and Postgres with no argument. The question is not
whether Compose is any good —it is— but what happens when the things inside the
compose file stop being infrastructure and start being your services, the
ones you edit every day.
In one sentence
Docker Compose declares a set of containers and their network in a YAML file, and starts them together. Everything that runs, runs in a container; everything that talks, talks through the service name on that network.
Aseptic uses Docker for the shared infrastructure and starts your services as processes on your machine, resolving each dependency to a local service, to your shared cloud environment or to a mock, and rewriting the URLs between them at startup.
The table
| Docker Compose | Aseptic | |
|---|---|---|
| Brings up shared infrastructure | Yes, it is what it does best | Yes — with Docker, underneath |
| Your services | Containerised, with their image | Native by default; containerised if you want |
| Seeing a code change | Rebuild the image and recreate the container | Your framework's own hot reload |
| Debugger attached | Possible, by wiring ports and options | It is a local process: as always |
| Where each service points | At the service name on the compose network | Per dependency: local, cloud or mock |
| Running only part of the system | up a few of them; the rest by hand | The scenario defines what is in, and the rest resolves itself |
| Configuration | A YAML file, usually inside a repo | Scenarios outside the repos; manifests autodetected |
| Port collisions | You resolve them | Automatic remapping |
| Also works in CI | Yes | No — it is a desktop tool |
| Licence | Open source | Free for personal use, paid for commercial use |
Take Docker Compose if…
- Your system is two or three stable services you do not touch daily. One compose file and one command is hard to beat, and you install nothing new.
- You need the same thing on your machine and in CI. Aseptic is desktop software; Compose runs in both places from the same file.
- The services you bring up belong to other people and only need to be running: if you never edit them, having them containerised is exactly what you want.
- You want an open-source tool, with no licence to review.
Take Aseptic if…
- You want the service you are editing to run natively —hot reload, debugger attached— and the others simply up and quiet. That is a mix a compose file cannot express: inside it, everything is a container.
- You want to run three of the twelve and have the other nine point at your cloud environment or at a mock, deciding it per dependency rather than per environment.
- You are tired of changing a URL in the
application.ymlof a repository that is not yours and remembering not to commit it. - You want the environment shared as a file, not as a forty-step document nobody keeps up to date.
Where Aseptic falls short
It does not run in CI. It is a desktop application with a CLI, built for one person's working loop. If what you need is dependencies inside a continuous integration job, Compose —or Testcontainers— is the answer, and Aseptic does not compete there.
It is not open source either, and Compose has been the de facto standard for years: it is on everyone's machine, there is an answer for every problem, and nobody needs convincing to install it.
And if your system is small, Aseptic is more machinery than you need. The advantage shows up once there are enough services that deciding where each one points becomes a job in itself.
What usually ends up happening
They coexist, because they do not compete at the same layer. The compose file keeps what Compose is good at —the shared infrastructure— and Aseptic in fact uses it as is: you point it at the file you already have. What moves out of the compose file are your services, which is where the build-an-image-per-line-changed cycle hurts.
If you are also weighing Tilt, Skaffold or a local Kubernetes, the Docker Compose alternatives page puts them side by side, and the broad comparison covers the three general approaches. If what you are wondering is whether Testcontainers already solves this, there is the Testcontainers comparison.
Frequently asked questions
Does Aseptic replace Docker Compose?
No, it uses it. Aseptic brings the shared infrastructure up (Kafka, Redis, PostgreSQL) with Docker, exactly as you would. What changes is what happens to your services: instead of building an image of each one on every change, it runs them as processes on your machine —or containerised if you prefer— and rewrites the URLs between them at startup.
Can I keep my existing docker-compose.yml?
Yes. Aseptic points at the compose file you already have for infrastructure; there is nothing to rewrite or migrate to another format.
What does Docker Compose do better than Aseptic?
It is standard, it is open source and anyone can run it without installing anything else: if your system is small and stable, one compose file and one command is hard to beat. It is also the only one of the two that works the same in CI as on your laptop.
What if I only want to run two of my twelve services?
That is exactly where compose runs out: either you bring the other ten up too, or you hand-edit the URLs of the two you actually want. In Aseptic you decide per dependency whether it resolves to the local service, to your cloud environment or to a mock, and it is applied at startup without touching your repositories.
Do I need Docker to use Aseptic?
Yes, for the shared infrastructure. Aseptic manages those containers for you, with automatic port remapping when they collide.