What’s New in Nacos 3.0 Alpha? Security, API Overhaul, and Cloud‑Native Enhancements

Release Overview

Nacos 3.0‑Alpha has been launched, targeting further optimisation of security, usability and standardisation compared with the 2.0 series.

1. Refined API Classification

Previously Nacos grouped APIs into two broad categories – OpenAPI for clients and AdminAPI for operators – which caused contradictions in real‑world scenarios (e.g., data‑sync APIs vs. console query APIs) and could not satisfy diverse authentication needs. Nacos 3.0 now defines four distinct API groups: OpenAPI (client‑oriented), AdminAPI (operations), ConsoleAPI (UI), and InnerAPI (engine‑to‑engine). This multi‑dimensional classification enables scenario‑specific data access and lays the groundwork for tailored security mechanisms.

2. Default Security per API Type

In earlier versions all APIs shared a single security switch, which was unsuitable for internal‑only APIs such as InnerAPI and AdminAPI and prevented enabling authentication before client identity was set. Nacos 3.0 adopts the following defaults: InnerAPI and AdminAPI use ServerIdentity verification; ConsoleAPI requires username/password authentication; OpenAPI retains the 2.0 behaviour (security disabled by default, user‑controlled).

3. Consistent Default Namespace Handling

The public namespace ID inconsistency (empty string in configuration module vs. "public" in service‑discovery) caused confusion and permission issues, especially after auth plugins began depending on the namespace ID (since v1.2.0). The roadmap (see ISSUE#9846) states that the default namespace ID will be changed to "public" and that an empty ID will be automatically mapped to "public" for backward compatibility.

4. Native xDS Support

Nacos 2.0 obtained xDS data via Istio’s MCP, adding complexity and stability risk. Nacos 3.0 directly implements the xDS protocols – EDS, LDS, RDS and CDS – eliminating the Istio dependency and simplifying service‑mesh integration.

5. New Admin API and Flexible Console/Engine Deployment

The legacy AdminAPI was loosely defined and lacked standardisation, hindering reuse by custom consoles. Nacos 3.0 will redesign AdminAPI with explicit request/response schemas and error codes, enable authentication by default, and provide a Maintainer‑SDK for developers. Additionally, the console will run in an independent web container with its own port, allowing fine‑grained ACL configuration and decoupled deployment from the engine, thereby improving security and operational flexibility.

6. Experimental Distributed‑Lock Feature

Community surveys identified distributed‑lock support as a top request. Nacos 3.0 plans to introduce an experimental lightweight lock mechanism, reducing reliance on external systems such as Zookeeper or Redis.

7. Spring Boot 3 and JDK 17 Upgrade

Spring Boot 2 has reached end‑of‑life, exposing security vulnerabilities. Nacos 3.0 intends to upgrade to Spring Boot 3 (requiring JDK 17+) and leverage Java native‑image support for performance gains.

8. Roadmap and Community Voting

Future work includes fuzzy subscription for services/configuration, DNS protocol support, decoupled health‑check mechanisms, integration of mature plugins (PostgreSQL, AES encryption) into the main repository, Kubernetes controller for cloud‑native sync, and AI‑model integrations. The community is invited to vote on several proposals: EOL of Nacos 1.x (ISSUE#12921), dropping 1.x client support in 3.x (ISSUE#12922), and the JDK 17/Boot 3 upgrade (ISSUE#12923). Additional discussions are tracked in issues #3525, #8774, #9773, #9783, #9846, #9129, etc.