Learn how to manage Clojure microservice configuration with Aero while keeping artifacts environment-neutral, secrets externalized, and operational defaults explicit.
Configuration management: The discipline of supplying environment-specific operational values without changing application code or rebuilding the artifact for each environment.
Configuration becomes harder in microservices because the number of moving parts grows quickly: ports, URLs, feature flags, secrets, credentials, rollout toggles, and per-environment infrastructure names. Good configuration design keeps those concerns external, reviewable, and boring.
Aero remains a useful Clojure-native option when you want EDN-based configuration with profiles, references, and environment-variable integration. The deeper rule, though, is not “use Aero.” The deeper rule is “keep the same artifact portable across environments.”
The strongest production habit is to build once and inject environment-specific values later. That means:
Configuration should tell the service where it is and what infrastructure surrounds it. It should not require code changes to express that.
Aero is useful when a service benefits from EDN configuration with:
1{:http {:port #long #or [#env PORT 8080]}
2 :db {:jdbc-url #env JDBC_URL}
3 :auth {:issuer #env AUTH_ISSUER}}
That kind of config is readable and friendly to Clojure teams. The real value is not the syntax itself. It is the discipline of treating operational inputs as data rather than scattering them through namespaces.
Secrets should be delivered through environment variables or secret stores, not committed as plain-text constants. That includes:
If a service uses Aero, that does not change the secret-handling rule. Aero should read secrets, not become the reason they were stored unsafely in the first place.
Good defaults help local development. Bad defaults quietly point a service at the wrong infrastructure or hide missing configuration until production.
Prefer defaults for:
Avoid defaults for:
This often hides drift and makes deployments harder to reason about.
Even one leaked config file can become a long-lived operational problem.
When half the behavior lives in config and half in hidden namespace-level constants, the operational model becomes hard to understand.
Use Aero when EDN-based configuration gives the team clarity, but keep the deeper goal in mind: environment-neutral artifacts, externalized secrets, and explicit operational inputs. Configuration should explain deployment differences, not create mystery about how the service actually behaves.