Quarkus: a local environment for several services
Quarkus already solved the part most frameworks get wrong: dev mode reloads on save and Dev Services will start a container for the database you forgot to run. What it does not solve is the service next door, and the one after that.
Where dev mode stops
- It is per service. Five services means five terminals, five dev modes and remembering which port each one took.
- Dev Services is per service too. Each one that wants a database gets its own container. That is right for isolation and wrong for a flow where three services read the same Kafka topic.
- The URLs between services are still yours. Every
@ConfigPropertyor REST client base URL that points at another service has to be pointed somewhere when you are not running the whole system. - Order still matters. Reload does not help if the dependency was not answering when the caller started.
What Aseptic adds
Aseptic autodetects a Quarkus service from its manifest and starts it as a native
process with your build tool, injecting configuration at startup as -D
properties or environment variables. The URLs between services are rewritten there,
so application.properties stays exactly as it is in git.
A scenario is the flow: the services that take part, the order they need, and where each dependency resolves — a local service, your shared cloud environment, or a mock. Ports that collide are remapped and the new value is what the callers are told.
For shared infrastructure, Aseptic brings up Kafka, Redis and PostgreSQL in Docker once, for the whole scenario, and points every service at the same instance. That is the difference from Dev Services: one broker the flow shares, rather than one per service. If you prefer Dev Services for a given run, nothing stops you — Aseptic starts your service the way you tell it to.
Libraries you are changing at the same time
If the feature spans a service and a library of your own, Aseptic builds the library and links it where Maven and Gradle resolve it, rebuilding and relinking on change. The consumer's build file is never edited, and unlinking undoes only what Aseptic put there.
What it does not do
It does not replace dev mode, and it should not: reload on save is Quarkus's job and it does it better than anything a launcher could add. It does not build native images or run a Kubernetes cluster, so anything you need to verify at that level belongs elsewhere. And it needs Docker installed for the shared infrastructure.
It is in public beta, ships for Windows, macOS and Linux, and it is free for personal use.
Next to the alternatives
If your services are already containerised and deployed by manifests you maintain, Tilt and Skaffold give you a loop shaped like production. The alternatives to Docker Compose page covers the whole field.
There are equivalents of this page for Spring Boot and for Node.
Frequently asked questions
Isn't Quarkus dev mode enough?
For one service it is excellent. What dev mode does not solve is who starts the others, in what order and against what: as soon as the flow crosses three services, that part is still yours.
Does Aseptic break Quarkus live reload?
No. The service is started as a native process with its own command, so live reload is exactly the one you already have.
Can I mix Quarkus with services from another stack?
Yes. The engine carries no logic specific to one technology: each stack has its profile and they can coexist in the same scenario.