Service discovery and configuration management for microservices, secured on first boot.
Nacos is an easy to use open source platform for dynamic service discovery, configuration management and service management, built for cloud native applications and microservice architectures. Services register themselves and find one another by name, while configuration lives centrally and is pushed to listening clients in near real time, so feature flags, connection strings and tuning parameters can change without a restart or a redeployment.
Rather than running a separate registry and a separate configuration store, it provides both behind one API, one console and one set of credentials, with namespaces and groups keeping development, staging and production settings apart.
The cloudimg image ships with no administrator account and no signing keys at all. On the first boot of every instance a one shot service generates a fresh signing key, a fresh server identity pair and a strong random administrator password unique to that instance, and writes the login to a root only file, so no two instances share a credential and the well known default console login simply does not exist. Server API and gRPC authentication is enabled, so unauthenticated naming and configuration calls are rejected, and the service cannot start before those secrets exist. The datastore and runtime state sit on a dedicated, independently resizable data disk, the console is published over TLS by nginx, and the image is paired with a deploy guide and 24/7 cloudimg support.
Real screenshots taken while testing this image against its deployment guide.
This is a repackaged open source software product wherein additional charges apply for cloudimg support services.
Overview
Nacos is an easy to use platform for dynamic service discovery, configuration management and service management, designed for building cloud native applications and microservice architectures. It gives your services a single place to register themselves and find one another, and a single place to store and push configuration, so instances can be added or replaced without redeploying the clients that depend on them. Configuration changes are delivered to listening clients in near real time, which means feature flags, connection strings and tuning parameters can be changed centrally without a restart.
Service Discovery and Configuration in One Platform
Rather than running a separate service registry and a separate configuration store, Nacos provides both behind one API, one console and one set of credentials. Services register over the naming API and are discovered by name; configuration is organised by namespace, group and data identifier so that development, staging and production settings live side by side without colliding. Health checking removes unhealthy instances from discovery results automatically.
Client Ecosystem
Nacos is the registry and configuration source that Spring Cloud Alibaba and Apache Dubbo applications are built to talk to, so Java microservices can register and read configuration through their existing starters rather than bespoke code. Clients use the naming and configuration API on port 8848 and the gRPC client port on 9848, and the image runs on Amazon EC2 inside your own VPC.
Application Stack
The Nacos server runs standalone with its built in embedded datastore, so there is no external database to provision before the platform is usable. The server exposes its OpenAPI and gRPC base on port 8848 and the gRPC client port on 9848 for software development kit clients, while nginx terminates TLS and publishes the web console on the standard HTTPS port. The datastore and the naming and configuration runtime state live on a dedicated, independently resizable data disk rather than on the operating system disk.
Secure First Boot
Stock Nacos deployments are widely exposed because they are left on a well known default console login. This image ships with no administrator account and no signing keys at all. On the first boot of your instance a one shot service generates a fresh JSON Web Token signing key, a fresh server identity pair and a strong random administrator password, all unique to that instance, initialises the administrator through the platform's own admin initialisation API, and writes the login to a root only file. Server API and gRPC authentication is enabled, so unauthenticated calls to the naming and configuration interfaces are rejected rather than merely hidden behind the console. The service is gated so that it cannot start at all until those per instance secrets exist, which means there is no window in which the platform serves with empty keys.
Example Use Case
Consider a team running dozens of microservices that needs configuration rollouts without downtime during a traffic peak. The platform team publishes updated rate limits and feature flags to a production namespace, and every listening service picks up the change in near real time without a restart or a redeployment. Health checking removes unhealthy instances from discovery results, so traffic keeps flowing to the instances that are actually serving while the team scales out.
Ready To Use
Read the generated administrator password from the root only credentials file, browse to the console over HTTPS, and register your first service or publish your first configuration. Point your applications at the server address shown in the same file to begin using discovery and configuration from your own code. A built in self test command proves the full authenticated round trip on demand.
cloudimg Support
24/7 technical support by email and chat for deployment, console access, client wiring, namespace design, TLS termination and upgrades. Contact cloudimg support if you would like help designing your namespace layout or wiring your first client.
All product and company names are trademarks or registered trademarks of their respective holders. Use of them does not imply any affiliation with or endorsement by them.