Apollo (apolloconfig/apollo): a config center you self-host on Java and MySQL

What Apollo solves, and who ends up running it

Configuration drift across environments is the problem Apollo targets. The README describes it as a system that can centrally manage the configurations of different applications and different clusters, and it names microservice configuration management as the intended scenario. That framing matters: this is not a library you drop into one service. It is a service, with its own database, that other services read from.

The unit of organization is the namespace. The README states that with the namespace concept it is easy to support multiple applications sharing the same configurations while also allowing them to customize. So the typical user is a platform or SRE team that owns configuration for many services, not a single developer. The README also calls out authorization management, release approval and operation audit as features, and separates editing from publishing as two operations. That split exists to reduce human error, and it only pays off when more than one person touches production config.

If you have one application and one environment, Apollo adds a database, a portal, an admin service and a config service to your stack. The README's own selling point, that the only external dependency is MySQL, is still one more dependency than a file in your repository.

How the pieces fit: portal, admin service, config service, client

The repository layout shows the split clearly. Top-level modules include apollo-portal, apollo-adminservice, apollo-configservice, apollo-biz, apollo-common, apollo-audit and apollo-assembly. The README says the server side is built on Spring Boot and Spring Cloud and can run without installing an additional application container such as Tomcat, which is why apollo-assembly exists as a packaging path.

The data flow is one-directional for readers. Configuration is written and released through the portal, stored in MySQL, and served to clients. The README states that after a user modifies and releases a configuration, the SDK receives the latest configuration in real time (it gives 1 second) and notifies the application. That is a push notification on top of a poll, which is why the config service and the client SDK are a pair rather than a plain HTTP fetch.

Two features depend on the same storage. Release version management is described as versioning every release, which is what makes rollback possible. Grayscale release is described as taking effect for only some application instances first, then pushing to all after observation. Both require the server to know which instances are running which version, and the README lists client side configuration information monitoring as a feature for exactly that: seeing which instances use the configurations and what versions they use.

For non-Java and non-.Net services, the README states that HTTP APIs are provided so those applications can integrate. There is also an open platform API, and the README explains why it exists: Apollo does not put too many restrictions on configuration modification, so applications with stricter formats, such as XML or JSON that must be validated, are allowed to modify and release configurations through open APIs with their own authorization and permission control.

Installing Apollo locally and a first real use

The README does not inline install commands. It points to two paths: the Quick Start page and the Docker Quick Start page, both under apolloconfig.com. It also states that Apollo can run as long as Java and MySQL are installed, and that a packaging script can generate all required installation packages with one click and supports customization of runtime parameters. The scripts directory and the mvnw wrapper at the repository root are the build entry points visible in the layout.

If you build from source, the Maven wrapper is the entry point present in the repository. Running it from the repository root builds the modules listed in the layout, including apollo-assembly, which is the packaged distribution. The README does not document the exact artifact names or output paths, so read the Quick Start page before assuming where the archives land.

Once a server is running, the client side is where you spend your time. The README says the Java SDK does not rely on any framework and runs in all Java runtime environments, with good support for Spring and Spring Boot. It also states that Spring Placeholder, Annotation and Spring Boot ConfigurationProperties are supported, requiring Spring 3.1.1 or later. The README gives no code sample for these, so the Java SDK User Guide is the place to copy an exact snippet from rather than guessing at annotations.

What you should see after a successful local start is the portal UI, which the README illustrates with a screenshot of the home page and says is available in Chinese and English. Configuration you create there is what the SDK reads.

Where Apollo is the wrong tool

The MySQL dependency is the first boundary. The README presents it as a strength, and for high availability it is: fewer external dependencies means fewer things to keep alive. But it also means Apollo cannot be your configuration store if your platform team will not run a database, or if you are deploying to an environment where a stateful service is not available. There is no documented mode that runs Apollo without MySQL.

Grayscale release is the second place to look carefully. The README describes it as taking effect for some instances, then pushing to all after a period of observation. That is a manual, human-in-the-loop process. If your expectation is automatic progressive delivery driven by health metrics, the README does not describe that, and you should not assume it.

The open platform API has a deliberate trade-off that the README states outright: Apollo will not put too many restrictions on configuration modification, and as long as it conforms to the basic format, it can be saved. That is flexible, and it also means Apollo will happily store a value that your application cannot parse. The README frames validation as the application's job, handled through open APIs, not the config center's.

Finally, language coverage. The README names native SDKs for Java and .Net. Golang, Python, NodeJS, PHP and C are described as rich third party SDKs. Third party means a different maintenance owner and a different release cadence from the server, and the README does not make any compatibility guarantee for them.

Apollo against Spring Cloud Config and Nacos

The nearest comparison in the same ecosystem is Spring Cloud Config, which stores configuration in a Git repository and serves it over HTTP. The difference in approach is where the source of truth lives. Spring Cloud Config keeps it in version control, so review and history come from Git. Apollo keeps it in MySQL and builds its own release versioning, approval flow and audit log on top. If your organization already treats Git as the review surface for everything, Apollo duplicates that machinery; if your config changes come from operators who do not use Git, Apollo's portal is the more direct interface.

Nacos is the other common stop, and the difference is scope. Nacos combines service discovery and configuration in one server. Apollo is a configuration center only, and its README positions it that way. If you already run Nacos for discovery, adding Apollo means a second control plane to operate, and you should weigh that against Apollo's namespace model, grayscale release and audit features. If you want one server for both jobs, Apollo is not trying to be that.

The README also points to apollo-use-cases and a user practices page. Those are the honest places to check whether someone with your topology has already done this, rather than extrapolating from the feature list.

Upgrade cost, licence and what to check before deploying

Apollo is licensed under Apache-2.0, and the repository carries a LICENSE file at the root along with a .licenserc.yaml, which is the usual sign that the project checks licence headers mechanically. Apache-2.0 permits commercial use and modification and includes a patent grant. It also means you receive the software without warranty, so the operational risk of a config center outage sits with your team. This is a description of the licence text, not legal advice; have your own counsel review anything you redistribute.

The release cadence visible here is three releases in roughly five months: v2.5.0 on 2026-02-19, v2.5.1 on 2026-03-14 and v2.5.2 on 2026-07-12. The last push to the repository was on 2026-09-06. Upgrade cost is dominated by the MySQL schema, because the server persists configuration and release history there. The repository contains an apollo-build-sql-converter module, which suggests schema changes are handled as a migration concern rather than a drop-and-recreate. The README does not document a rollback procedure for a server upgrade, so confirm that against CHANGES.md and the release notes for the version you are moving to before you touch production.

On the client side, upgrades are cheaper: the Java SDK is published to Maven Central under com.ctrip.framework.apollo, so a version bump is a dependency change. The risk is behavioural, not structural. If you rely on the 1 second push notification, test it after any server upgrade rather than assuming it.

Editorial conclusion

Adopt Apollo if you run multiple environments and clusters, need per-namespace config with release history and grayscale rollout, and can operate a MySQL-backed service. Do not adopt it if your configuration is a single file in your repo, if you cannot run MySQL, or if you want a hosted control plane. Before committing, verify two things in your own environment: that your MySQL version is supported by the scripts under apollo-buildtools and the docs, and that your client runtime has a maintained SDK, since the README lists Java and .Net as native and points to third-party SDKs for Golang, Python, NodeJS, PHP and C. The last push to the repository was on 2026-09-06, and the most recent release listed is v2.5.2 from 2026-07-12, so the project is still moving; check the release notes for that version against your deployment before you upgrade.

Frequently asked questions

Official sources

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