Nacos Deployment Best Practices

Nacos is a foundational microservice component. In production, it may carry service discovery, configuration management, and AI Registry workloads. A good deployment is not only about starting a cluster. It is also about clear network boundaries, reliable storage, access control, and safe operations.

Attention

• Nacos is an internal microservice component and must run in a trusted internal network. Do not expose it to the public internet.
• The default Nacos authentication implementation is a simple weak-auth system to prevent business misuse. It is not a strong-auth system for defending against malicious attacks.
• If Nacos must run in an untrusted network, or if strong authentication is required, develop a custom plugin based on the official simple implementation. See Auth Plugin.

Recommended Topology

For production, use cluster mode and separate Nacos Server, Nacos Console, database, and client access paths.

Applications / SDKs
      |
Internal VIP or SLB
      |
Nacos Server cluster  ---- External database
      |
Internal management network
      |
Nacos Console

Recommendations:

• Deploy Nacos Server in a trusted internal network and expose only required ports to internal clients.
• Deploy Nacos Console independently and allow access only from operations, platform, or development management networks.
• Allow only Nacos Server to access the database. Do not expose the database to applications or the public internet.
• Allow server-to-server communication ports only between Nacos Server nodes.
• Do not expose any Nacos entry point directly to the public internet. For cross-network access, use VPN, private links, bastion hosts, or enterprise gateways.

Network And Ports

Since Nacos 3.0, the console port is separated from the server main port. Default ports:

When using VIP, SLB, or Nginx, forward 9848 as TCP traffic. Do not proxy it as HTTP or HTTP/2. For details, see Deployment Overview.

Independent Console Deployment

For production, deploy the console independently. This separates the high-privilege management entry from the server runtime path and reduces the impact of console traffic on core server workloads.

Recommended setup:

1. Start Nacos Server with sh startup.sh -d server.
2. Start Nacos Console with sh startup.sh -d console.
3. Point the console cluster.conf to Server nodes or an internal VIP.
4. Keep server identity and token secret settings consistent between Console and Server.
5. Expose the console only to the management network and protect it with enterprise access controls.

For step-by-step instructions, see Independent Console.

Database Storage

For production, use an external database. Embedded Derby is suitable for local development, standalone testing, and temporary validation, but not recommended as production storage.

Nacos currently officially supports four database types:

Recommendations:

• Import the schema of the target Nacos version before startup.
• Use the same database type, schema, and plugin version on all Nacos Server nodes.
• Grant only the required database permissions to the Nacos database account.
• Prepare database backup and restore procedures, and test restore before upgrades.
• Validate compatibility and upgrade paths in a test environment before using community datasource plugins in production. Oracle 11g and earlier versions are no longer maintained by Oracle, and the current Oracle plugin no longer keeps backward compatibility with them.

For details, see Datasource Plugin and System Configurations.

Authentication And Credentials

Unless the deployment is purely local and temporary, enable authentication and explicitly configure server identity and token secret.

Basic configuration:

nacos.core.auth.enabled=true
nacos.core.auth.system.type=nacos
nacos.core.auth.server.identity.key=${your_identity_key}
nacos.core.auth.server.identity.value=${your_identity_value}
nacos.core.auth.plugin.nacos.token.secret.key=${your_token_secret}

Recommendations:

• Do not use default, sample, or short token secrets.
• Use the same server identity settings on all Server nodes and independent Console nodes.
• Choose the right auth plugin for the environment: default Nacos auth, LDAP, OIDC/OAuth2, or a custom plugin.
• Manage SDK, OpenAPI, and console accounts separately. Avoid shared high-privilege accounts.
• After permission changes, remember that local auth caches may introduce a short delay.

For details, see Authorization Manual, Access Credentials, and Auth Plugin.

Visibility And Resource Governance

Authentication answers “can this user access the system”. Visibility answers “which resources can this user see”. If you use AI Registry, evaluate the visibility plugin so different teams, tenants, or users do not see unrelated resources.

Related docs:

• Visibility Plugin
• AI Resource Lifecycle

Traffic Control

When a cluster carries many client connections or sudden traffic spikes on core APIs, enable the traffic control plugin. Start with monitor mode, then switch to intercept after the threshold is validated.

nacos.plugin.control.manager.type=nacos

Pay attention to:

• Client gRPC long connections.
• Config query and listener traffic.
• Service registration, deregistration, and subscription traffic.
• Console and operations API request rate.

For details, see Traffic Control Plugin.

Configuration Encryption

Use the configuration encryption plugin for sensitive configs. It stores selected dataId values as ciphertext and uses encrypted_data_key to store the data key.

cipher-aes-application-prod.yaml

Recommendations:

• Load the same algorithm plugin on the server and on clients that need decryption.
• Before upgrades, confirm that tables contain the encrypted_data_key column.
• Configuration encryption does not replace authentication, network isolation, or TLS.
• In enterprise production environments, connect a custom plugin to KMS or HSM if needed.

For details, see Configuration Encryption Plugin.

Monitoring, Backup, And Upgrade

Prepare these operations capabilities before going online:

• Connect Prometheus and Grafana. Monitor JVM, thread pools, gRPC connections, request volume, database pools, and topN resources.
• Back up the database and key files regularly, such as application.properties, cluster.conf, and the plugin directory.
• Before upgrades, compare the target version schema and test upgrade and rollback in a staging environment.
• When changing auth, datasource, independent console, or plugin configuration, roll out to a small set of nodes first.
• Keep an emergency runbook for disabling traffic rules, rolling back plugins, switching database connections, and restoring console access.

Related docs:

• Monitor Manual
• Upgrading Manual
• System Configurations

Go-Live Checklist