Change config once.
Every service, every environment gets it right.
50 services in 5 environments means 250 config files that slowly drift apart. With Microconfig
you write shared settings once, in plain YAML or properties, and it builds every file:
application.yaml, Helm values, logback.xml, anything.
No new language, no server, no lock-in.
or get a binary for macOS, Linux, Windows or a Java jar
Open source since 2019
Try it right here: change one line
Two services, two environments. Edit a highlighted value in the sources: on the right, the lines that change in each generated config light up, everything else stays dimmed.
Component: a folder in components/ with a service's configs or a shared part.
Environment: a file in envs/ listing the services it runs; files like
application.prod.yaml override values for one environment.
# shared: included by every service monitoring: base-path: /monitoring endpoints:
#include monitoring, postgres name: payment-backend server: port: 80 context:
#include monitoring name: payment-frontend payment-backend: path: ${payment-backend@server.context}
# prod only #var dbHost:
By hand, every updated file is a separate edit. With 50 services in 5 environments, one shared change means up to 250 files.
Sound familiar?
Everyday configuration pain in a microservice system, and what it looks like with Microconfig.
“Kafka moved. Now 50 services need the new address.”
Keep connection settings in one shared component and #include it. Change one
file, rebuild, and every service gets the new address.
“Backend changed its API path. Frontend found out in production.”
The frontend references the value instead of copying it:
${payment-backend@server.context}. Change it once, both stay in sync.
“Friday release. What exactly changes in prod?”
Every build writes a git-style diff next to the result: added, removed and changed properties for each service. Review it before you deploy, not after the incident.
Use case: reviewing changes before a release →“We need a stage for a client. By tomorrow.”
Describe a new environment in one small file and override only what differs, like a database host. Everything else is inherited from the base config.
Use case: many environments →“Someone renamed a key. Production found out first.”
Every ${service@key} reference is checked during the build. A typo or a
renamed key fails the build in CI with the file and line, before anything is deployed.
“Why is pool-size 50 in prod? Where does it come from?”
The JetBrains plugin resolves any value for every environment right in the editor and jumps to the line where it is defined.
IDE plugin →Who it's for
Microconfig pays off as soon as configuration starts repeating itself.
Platform and DevOps teams
Dozens of services, several environments, one repository of configs that everyone copies from. Turn the copy-paste into shared components your teams include.
Any stack, a perfect fit for Spring Boot
The output is plain YAML, properties or any text file, so services in Go, Node, Python or
anything else can read it. Spring Boot and other JVM services read
application.yaml and .properties natively: drop the files in,
nothing changes in your code.
You probably don't need Microconfig yet if you run a handful of services in a single environment. Plain files are fine there.
Already using something else?
Microconfig is a build step, not a platform: it keeps configuration for many services in one place and builds plain files. So it works alongside the tools you already have.
Helm
Helm packages and releases apps to Kubernetes. It doesn't help when 50
values.yaml files repeat the same blocks.
Keep Helm. Microconfig generates the values (*.helm), Helm deploys them.
Kustomize
Kustomize patches Kubernetes manifests. The application configs inside your pods are still on you.
Use both: feed files built by Microconfig to configMapGenerator.
Spring Cloud Config, Consul
Config servers deliver configuration at runtime. What they serve still has to be stored somewhere, without duplication and with history.
Use both: Microconfig builds what the config server serves.
Jsonnet, CUE, ytt
Config languages are powerful, but everyone who touches config has to learn a new language and toolchain.
Microconfig stays plain YAML or properties plus a few directives:
#include, ${...}, #{...}.
How it fits your pipeline
Microconfig runs as one step in CI, between your config repository and your delivery tools.
-
Sources in Git
One repository with
components/andenvs/for all services. -
Build in CI
microconfig -e prodtakes seconds even for hundreds of services and fails on any broken reference. -
Plain files
build/<service>/with application configs, Helm values, templates. -
Your delivery
Helm, kubectl or Kustomize, a config server, or a plain copy to hosts.
on: [push] jobs: configs: runs-on: ubuntu-latest steps: - uses: actions/checkout@v4 - name: Install Microconfig run: | curl -sSL -o microconfig.zip https://github.com/microconfig/microconfig/releases/latest/download/microconfig-linux.zip unzip -q microconfig.zip - name: Build prod configs run: ./microconfig -e prod -d build - uses: actions/upload-artifact@v4 with: name: prod-configs path: build/
Works the same in GitLab CI, Jenkins or any other runner. In real pipelines,
pin a release instead of latest.
Questions teams ask before trying
Short answers. The documentation has the details.
Where do secrets go?
Neither into Git nor into generated configs. Keep only references in the repository, like a
Vault path or the name of a Kubernetes Secret, and let the secret values be injected at deploy
time or at startup. Microconfig has a separate .secret config type for describing
these references.
Is it only for Java services?
No. Microconfig is written in Java, but it produces plain files: YAML, properties or any text template. Services in any language can read them, and the native binary doesn't need Java installed. Spring Boot is the most natural fit: it reads these files without any glue.
Does it work with Kubernetes and Helm?
Yes. Next to application configs, Microconfig builds Helm values (*.helm) and
Kubernetes configs (*.k8s) for each service and environment. Deploy the result
with the tools you already use.
Do we have to migrate everything at once?
No. Your existing YAML and properties files are valid Microconfig sources as they are. Put them
under components/, list services in an environment file, then move copy-pasted
blocks to shared components one at a time. The output is plain files and nothing runs in
production, so stopping is just as easy as starting.
What do the generated files look like?
Ordinary files your services read as they are. Two things to know: comments from the sources stay in Git and are not copied to the result, and keys in generated YAML come out sorted alphabetically.
Does it reload config in running services?
No. Microconfig runs at build time and produces files. Deliver them with your usual tools, or serve them from a config server that supports refresh.
How does config diff work?
Each build compares the new files with the previous build in the same output folder and writes
diff-application.yaml and similar files next to them: added, removed and changed
properties.
Does it run on Windows?
Yes. There is a native Windows binary, and the executable jar runs anywhere with Java 17+. See Download.
What does it cost?
Nothing. Microconfig is open source under the Apache 2.0 license, developed on GitHub since 2019 with regular releases.
See it on a real example in 2 minutes
Install, clone the example, change one line, see what happens to every service.