Security and System Complexity Comparison Between Nacos and Apollo Configuration Centers

Hello everyone, I am Chen (the author).

My video tutorial series "Spring Cloud Alibaba Practical Project" is now complete, covering various Alibaba middleware, OAuth2 microservice authentication and authorization, full‑link gray release, and distributed transaction practice. You can subscribe to the video series Spring Cloud Alibaba Practical Video Column – Open Subscription .

The previous two articles introduced Nacos and Apollo respectively:

"Fifty‑five pictures tell you how powerful the soul‑shuttle of microservices Nacos really is"

"Talking about the distributed configuration center Apollo"

Today this article focuses on the design differences between Nacos and Apollo, based on Apollo 1.8.0 and Nacos 2.1.0.

Security Differences

Here, "security" refers to the client side reading the configuration center, not the console.

If all environments share a single configuration center, developers can obtain test‑environment configurations and, consequently, production configurations, which is a security risk.

Two typical solutions exist:

① Use different configuration centers for different environments.

Apollo adopts this approach; when a client needs production configuration, the operator must specify the production‑environment config server in the startup parameters.

For this method to be reliable, the production config‑server address must never be leaked. I have even seen cases where the config server was registered on a public Eureka instance.

② Use the same configuration center but enforce environment isolation.

Nacos follows this approach; isolation is achieved via namespace + authentication .

Unlike Apollo, a client must provide a username and password to read from Nacos. When production configuration is required, the operator must also specify the production namespace and its credentials in the startup parameters.

Both Apollo and Nacos have the concept of a namespace, but in Apollo a namespace corresponds to a specific configuration file, whereas in Nacos a namespace represents an entire environment.

Their data models are illustrated below:

Apollo distinguishes environments by connecting to different config servers; Nacos distinguishes them by specifying a namespace.

In summary, to ensure security you must not expose the production config‑server address when using Apollo, and you must not expose the production namespace credentials when using Nacos.

If I had to pick the safer solution, I would lean toward Nacos because usernames/passwords are harder to leak than server addresses.

System Complexity Differences

When discussing Apollo’s design, I have complained that its architecture is overly heavy.

First, Apollo splits the configuration center into Config Service, Admin Service, and Portal, which I can accept.

What I cannot accept is the excessive components introduced to achieve client‑to‑config‑service load balancing, such as SLB, Meta Server, and Eureka. A simple SLB would suffice.

The official explanation is that this design avoids overloading the SLB with long connections between clients and the config service, which is not entirely unreasonable.

One positive aspect is that Apollo packages Config Service, Eureka, and Meta Server together for deployment.

Now look at Nacos: it does not split the configuration center into many services, and its load‑balancing solution is simple—a single SLB can handle it, even though Nacos also maintains long connections with clients.

Which architecture is better? I would prefer Nacos, especially for small‑ to medium‑size systems, because it is simpler.

Final Note (Please Support)

Each of my articles is carefully crafted. I have written three columns and compiled them into PDFs. You can obtain them as follows:

"Spring Cloud Advanced" PDF: Follow the public account Java Backend Interviewer and reply with the keyword Spring Cloud Advanced to receive it.

"Spring Boot Advanced" PDF: Follow the public account Java Backend Interviewer and reply with the keyword Spring Boot Advanced to receive it.

"MyBatis Advanced" PDF: Follow the public account Java Backend Interviewer and reply with the keyword MyBatis Advanced to receive it.

If this article helped or inspired you, please like, watch, share, and bookmark it – your support is the greatest motivation for me to keep going!

Everyone is liking, sharing, and watching