Apollo vs Nacos: Which Config Center Is Safer and Simpler?

Introduction

The author previously analyzed Ctrip's Apollo configuration center and now turns to Alibaba's Nacos. Both are configuration centers that support centralized configuration management, environment segregation, and immediate effect, but Nacos also provides service discovery.

Analysis Approach

When studying Apollo, four questions were used: why use a configuration center, how to design one, how Apollo is designed, and how to use Apollo. For Nacos, the first two questions are identical, the fourth is covered by official documentation, so the focus is on design differences between Apollo and Nacos.

The comparison is based on Apollo 1.8.0 and Nacos 2.1.0.

Security Differences

Security here refers to the client reading configuration data. Sharing a single config center across all environments creates a risk: developers with test‑environment access could also retrieve production configurations.

Two common mitigation strategies are:

Separate config centers per environment – Apollo adopts this approach. Production clients connect to a dedicated config server whose address must never be exposed.

Single config center with environment isolation – Nacos uses namespaces combined with authentication. Clients must provide a username and password, and the namespace identifies the target environment.

In Apollo, the namespace represents a concrete configuration file; in Nacos, it represents an entire environment.

The data models differ as illustrated in the accompanying diagrams (images retained).

Conclusion: To ensure security, Apollo requires protecting the production config server address, while Nacos requires safeguarding the production namespace credentials. The author judges Nacos slightly more secure because credentials are less likely to be leaked than server addresses.

System Complexity Differences

Apollo’s architecture is considered heavyweight. It splits the config center into Config Service, Admin Service, and Portal, and adds components such as SLB, Meta Server, and Eureka for load balancing, which the author finds unnecessary.

In contrast, Nacos keeps the architecture simple: a single service with a straightforward SLB for load balancing, despite also maintaining long‑lived client connections.

The author prefers Nacos for small‑to‑medium systems due to its simplicity, while acknowledging that Apollo’s extra components were introduced to reduce SLB load from long connections, a rationale that may hold for large‑scale deployments.

The article ends with an open question about real‑world SLB bottlenecks when using Nacos in large systems and invites readers to point out any mistakes.