Central Dogma puts version control around service configuration

A configuration service with a version history

Central Dogma is described as a highly-available and version-controlled service configuration repository based on Git, ZooKeeper and HTTP/2. That phrase packs three decisions into one line, and each one changes what you are adopting.

Git supplies the history. Configurations are stored in a repository with commits, so a change to a service setting is a reviewable, revertible event rather than a row in a database table that somebody edited. ZooKeeper supplies coordination, which is what allows several server processes to agree on state and to keep serving when one of them dies. HTTP/2 supplies the transport, so clients read configuration over a multiplexed protocol instead of pulling files from a shared disk.

The project is open source under the Apache License 2.0 and was released by LINE Corporation, which states that it uses the system in production. That last point matters for expectations. Central Dogma is not a weekend experiment from a single author. It is infrastructure that a large messaging company runs, and the API surface, the failure handling and the mirroring are shaped by that use.

For the intended user, the appeal is that configuration stops being a set of files that each service reads at startup. Services become clients that fetch configuration through an API, the system decides when to push a change, and every state a client has seen can be traced back to a commit. The cost is that you are now running a service instead of shipping a properties file.

What the source tree says about the architecture

The repository listing is more informative here than the short README, and it shows a project split into a client and a server with several supporting pieces.

At the top level there are server, client and common directories, plus a common-legacy directory that suggests compatibility code kept for older callers. Two sibling modules stand out: server-mirror-git and server-mirror-dogma. Read against the project description, the natural reading is that the storage layer is pluggable, with one mirror backed by Git and another backed by the Dogma store, the in-memory replicated store that gives ZooKeeper-backed availability. A user can therefore keep the Git repository as the durable source of truth while serving reads from the faster store, or run purely against Git.

There is also an xds directory and an xds-api directory. Those names point to support for an xDS style configuration protocol alongside the native API, which is how service meshes and sidecars usually receive configuration. If your fleet already consumes configuration through xDS, that directory pairing is the reason to look at Central Dogma at all.

The remaining entries describe the ordinary machinery of a Java project of this size: a webapp directory for the administration interface, dist for packaging, bom for the bill of materials, benchmarks for performance measurement, settings for configuration defaults, javadoc, and both site and site-new for documentation. There are also security and governance files, SECURITY.md and CODE_OF_CONDUCT.md, and a .agents and .claude pair of directories that suggest the project has been adapted for AI assisted development workflows.

Building the project with the Gradle wrapper

Central Dogma is built with Gradle, and the repository carries its own wrapper, with gradlew and gradlew.bat checked in at the top level. That means a build does not require a preinstalled Gradle of a matching version. The documented command compiles the project and produces JARs, a tarball and the web site:

$ ./gradlew build

Running that from a clone on a machine with a JDK and network access to the Gradle distribution and dependency repositories is the whole documented build step. Expect the build to be long the first time, since a Java server of this size pulls in a dependency graph managed through dependencies.toml and the bom module, and the webapp and site steps add more.

Two practical consequences follow from the module layout. The client library is a separate module, so a consumer that only reads configuration does not need the server modules, and the build can be pointed at the client alone. The distribution module is separate from the server modules too, which is where the tarball that the README mentions as a build output is assembled.

What the README does not give you is any deployment recipe. There is no documented service unit, no configuration file example, no port list, and no instruction for running ZooKeeper or for pointing the server at it. Anyone evaluating the project has to take that from the official site, and the README's only pointer is a link to the web site at line.github.io/centraldogma.

Git as the durable record, a mirror in front of it

The reason the storage layer is split in two is availability, and it is worth being precise about what each half does.

Git is the system of record. Configuration content lives in a repository with commits and history, which gives auditability and rollback, and it makes the stored configuration reviewable with tools a team already knows. Reading configuration directly from Git on every request would be slow, and it would tie the read path to the availability of the Git host, so the mirror exists to serve reads.

The Dogma store, with ZooKeeper providing coordination, is the serving side. It is an in-memory replicated store, and ZooKeeper is what lets the set of server processes agree on which copy is current and who takes over when a node dies. That is where the highly-available part of the description comes from. It is also the part with the operational cost: ZooKeeper is another clustered system to deploy and monitor, and the project does not document how it is configured.

For an operator, this is the central trade-off. You get a fast read path with a durable history behind it, at the price of running two systems. A team that wants the history and the HTTP/2 API but not the coordination layer can look at the Git mirror path, though the README does not describe the trade-off, and the naming of the two mirror modules is all the guidance the repository itself offers on the choice.

Against a plain Git repository of config files

The honest alternative to Central Dogma is not another product but a pattern most teams already have: keep configuration files in a Git repository, have each service read them at startup, and redeploy when they change. The differences are concrete rather than marketing claims.

That pattern needs no server process, no JVM to keep alive and no coordination cluster. Its weaknesses are equally concrete. A service only sees a change when it restarts, so a credential rotation or a feature flag flip means a deployment, and there is no way to ask a running service what configuration it currently holds. Every service needs its own copy of the files, so distribution is part of the deployment pipeline, and the read path depends on whatever mechanism moves the files around.

Central Dogma replaces that with a pull model. Clients fetch configuration over HTTP/2, which means a service can learn about a change without a restart, and the history of every value lives in Git commits rather than in whatever the deployment pipeline happened to do. The xDS style API modules are the reason this comparison is not one-sided, since a mesh already speaks that protocol.

The cost of the pull model is the running infrastructure. A team with five services and twelve configuration values is paying for a clustered configuration service to solve a problem that a directory of files solves, and Central Dogma's own documentation, not its README, is where you will find out what that costs in configuration.

Releases, licence and how to get an answer

Central Dogma is versioned by numbered releases, with 0.87.1 on 2026-10-14, 0.87.0 on 2026-10-07 and 0.86.1 on 2026-09-02 in the recent list. Two releases inside a week followed by a patch is a fast cadence, which is normal for a service the maintainers run themselves but means an upgrade can land between two of your releases. The last push to the repository was on 2026-10-19. Pinning a version and reading the release notes before taking one is the sensible habit here.

The licence is Apache 2.0, published by LINE Corporation, with the licence text in LICENSE.txt and a NOTICE.txt alongside it. That is a permissive licence with the standard attribution and patent grant terms, so there is no copyleft obligation to worry about when embedding the client library in a service you ship. This is a reading of the licence terms rather than legal advice, and any organisation should run its own review.

The project also offers several routes for a question. The README points to creating an issue on GitHub and to browsing the issues already labelled question-answered, mentions a Discord server, and points contributors at CONTRIBUTING.md. A community Discord and a labelled issue tracker are a good sign for a project whose hardest part is not code but operating the service correctly, and they are where to take the questions the README leaves open.

Editorial conclusion

Central Dogma fits teams that already run Java services and want configuration delivered through an API with a change history, with Git as the durable record and ZooKeeper or the in-memory Dogma store standing in front of it for availability. It is the wrong choice for a single service with a handful of static settings, since the README documents no packaging or deployment steps and the operational weight of ZooKeeper plus a JVM server has to be taken on for a problem a config directory solves. Before adopting it, read the documentation site rather than the README, since the README covers only the Gradle build, and check which of the two mirrors your deployment expects before wiring a client to it. The last push was on 2026-10-19 and release 0.87.1 came out on 2026-10-14.

Frequently asked questions

Official sources

1. License: Apache-2.0
2. line/centraldogma on GitHub
3. Project website
4. README
5. Releases