Nacos

Locate the Nacos on Ubuntu 24.04 LTS image in the Azure Marketplace and select Create.

Choose your subscription, resource group and region.

Select a VM size (Standard_B2s or larger). Provide your SSH public key for the azureuser account.

On the Networking tab, allow inbound 443 for the console and 8848 and 9848 for your application clients. Restrict 22 to your management network.

Select Review + create. When the VM is running, browse to https://<your-public-ip>/.

Deploy the same image from the Azure CLI. Replace the resource group, location and image URN as needed:

# Accept the Marketplace terms once per subscription (required before the first CLI deploy)
az vm image terms accept --urn sac1647283583153:nacos-ubuntu-24-04:default:latest
az vm create \
  --resource-group my-nacos-rg \
  --name nacos \
  --image sac1647283583153:nacos-ubuntu-24-04:default:latest \
  --size Standard_B2s \
  --admin-username azureuser \
  --generate-ssh-keys \
  --public-ip-sku Standard
# then open the console and client ports
az vm open-port --resource-group my-nacos-rg --name nacos --port 443 --priority 1001
az vm open-port --resource-group my-nacos-rg --name nacos --port 8848 --priority 1002
az vm open-port --resource-group my-nacos-rg --name nacos --port 9848 --priority 1003

SSH in as azureuser. Confirm that both services are active. Confirm that the server listens on the OpenAPI port 8848, the gRPC client port 9848 and the console port 8080, and that nginx listens on 443 and 80:

sudo systemctl is-active nacos nginx

ss -tln | grep -E ':8848 |:9848 |:8080 |:443 |:80 '

The first command should print nacos + nginx: active active. The Nacos server is bound on 8848, 9848 and 8080, and nginx is public on 80 and 443.

The admin password, console URL and client server address are generated uniquely for this VM on first boot. They are written to a root-only file. Read them with:

sudo cat /root/nacos-credentials.txt

The NACOS_ADMIN_PASSWORD value is unique to this instance. The stock nacos / nacos login is disabled, so this is the only credential that works.

Browse to https://<your-public-ip>/. The certificate is self-signed and generated per VM, so your browser warns about it the first time. Accept the warning, or install your own certificate (see Step 11).

Sign in as nacos with the password from Step 4.

Open Services, then Service List. The list shows every service instance registered with Nacos, with its group, instance count and health status.

This registry is the core of Nacos service discovery. Applications register here on start up and discover each other through it.

Open Configuration, then Configurations. The page lists the configuration items Nacos is serving. Each item has a Data ID, a group and a format.

Nacos pushes changes to subscribed clients in real time, so applications pick up new configuration without a restart.

Select Detail on a configuration item to view its full content, metadata and history. The content editor shows exactly what subscribed applications receive.

The image ships a self test that proves authentication is enforced and that the naming registry round trip works end to end. It confirms three things. An unauthenticated register is rejected. The stock nacos / nacos login is refused. The per-VM admin can register an instance and read it back.

Run it with:

sudo /opt/nacos/nacos-selftest.sh

The expected output reports round-trip OK. This confirms that authentication is enforced and that the registry works.

Server API authentication is enabled, so an unauthenticated call is rejected with 403. Log in with the per-VM admin to obtain an access token. Then use the token to register a service instance and read it back.

Run the whole block in one session so the access token is available to the register and list calls:

PW=$(sudo grep -m1 '^NACOS_ADMIN_PASSWORD=' /root/nacos-credentials.txt | cut -d= -f2-)
TOKEN=$(curl -s -X POST 'http://127.0.0.1:8848/nacos/v3/auth/user/login' \
  --data-urlencode 'username=nacos' --data-urlencode "password=$PW" \
  | python3 -c 'import sys,json; print(json.load(sys.stdin)["accessToken"])')
echo "obtained access token: ${TOKEN:0:24}..." curl -s -X POST "http://127.0.0.1:8848/nacos/v3/admin/ns/instance?accessToken=$TOKEN" \
  --data-urlencode 'serviceName=demo-service' --data-urlencode 'groupName=DEFAULT_GROUP' \
  --data-urlencode 'ip=10.0.0.10' --data-urlencode 'port=8080'
echo curl -s "http://127.0.0.1:8848/nacos/v3/admin/ns/instance/list?serviceName=demo-service&groupName=DEFAULT_GROUP&accessToken=$TOKEN"

The register call returns "data":"ok". The list call returns the instance you just registered.

Point your application's Nacos client at this VM. Use the server address for the OpenAPI. The client uses the gRPC client port for real-time discovery and configuration push.

For authentication, use the per-VM admin credential or a dedicated user that you create in the console under the users section. Authentication is enabled on this image, so every client must supply credentials.

For a Spring Cloud Alibaba application, set the server address <your-ip>:8848 and the username and password.

The image ships a self-signed certificate so the console is encrypted out of the box, but browsers warn about it. For production, point a DNS name at the VM and install a CA-signed certificate.

Inspect the current per-VM certificate with:

sudo openssl x509 -in /etc/nginx/tls/nacos.crt -noout -subject -ext subjectAltName

With your own domain, obtain a free certificate from Let's Encrypt:

sudo apt-get update && sudo apt-get install -y certbot python3-certbot-nginx
sudo certbot --nginx -d <your-domain>

Certbot installs the certificate into nginx and sets up automatic renewal.

Nacos server: nacos.service runs as the unprivileged nacos user from /opt/nacos. It runs in standalone mode with the embedded datastore. It exposes the OpenAPI on 8848 and the gRPC client port on 9848. The heap is sized for a Standard_B2s VM.

Console: the Nacos web console runs on 127.0.0.1:8080. It is published to the network only through nginx.

nginx: nginx.service terminates TLS on :443 and reverse proxies to the console. It redirects :80 to HTTPS. It also serves an unauthenticated /healthz for load balancer probes.

First boot: nacos-firstboot.service runs once on first boot. It does the following:

• Generates the per-VM JWT signing key, server identity and admin password, and renders them into the configuration
• Starts Nacos and initialises the admin user
• Proves the authentication round trip
• Regenerates the per-VM TLS certificate
• Writes /root/nacos-credentials.txt

The nacos.service unit is gated, so it can never start before the per-VM secrets are rendered.

sudo systemctl restart nacos

sudo journalctl -u nacos.service --no-pager | tail -20

Server settings live in /opt/nacos/conf/application.properties. After you change a setting, run sudo systemctl restart nacos.

• Restrict SSH. Allow inbound 22 only from your management network.
• Scope the client ports. Open 8848 and 9848 only to the application subnets that need service discovery and configuration. Keep the 443 console open to your operators.
• Install a trusted certificate. Replace the self-signed certificate with a CA-signed one (Step 11), so operators are not trained to click through warnings.
• Create per-application users. In the console, add a dedicated user and role for each application instead of sharing the admin credential. Keep the admin password safe.
• Keep the image updated. Unattended security upgrades remain enabled, so the OS keeps receiving patches.

Nacos is open-source software distributed under the Apache License 2.0. This image bundles the upstream Nacos 3.2.3 release. The license file is retained on the image under /opt/nacos/. SecureAnyCloud provides the packaging, hardening and support.

Deploy on Azure

Find this image on the Azure Marketplace and deploy it in minutes. See secureanycloud.com for the full catalog.

Need Help?

SecureAnyCloud provides 24/7 support with a guaranteed 24 hour response SLA. Contact us through secureanycloud.com for deployment assistance, configuration help or questions about this image.

Deploy on Azure

Launch Nacos on Ubuntu 24.04 LTS on Azure with 24/7 support from SecureAnyCloud.

View this image

Need Help?

Our support team is available 24/7.

sales@secureanycloud.com

Sign in to the AWS Management Console and open the EC2 service. Select Launch instance.

Under Application and OS Images, choose AWS Marketplace AMIs and search for Nacos. Select the SecureAnyCloud listing, choose Select, then choose Continue on the subscription summary.

Pick an instance type of m5.large or larger. Choose your EC2 key pair under Key pair (login).

Under Network settings, select your VPC and subnet. Create or select a security group that opens port 22 from your management network, port 443 for the console, and ports 8848 and 9848 from your application networks. Leave the root volume at the default size or larger.

Select Launch instance. First-boot initialization takes a short time after the instance state becomes Running and the status checks pass. During this time, the image generates the per-instance secrets, initializes the administrator account and issues the instance's TLS certificate.

The following command launches an instance from the SecureAnyCloud Nacos Marketplace AMI into an existing subnet and security group. Replace the values in angle brackets as follows:

• Replace <ami-id> with the AMI ID shown on the Marketplace listing.
• Replace <key-name> with your EC2 key pair name.
• Replace <subnet-id> with your subnet ID.
• Replace <security-group-id> with a security group that opens ports 22, 443, 8848 and 9848 as described above.

aws ec2 run-instances \
  --image-id <ami-id> \
  --instance-type m5.large \
  --key-name <key-name> \
  --subnet-id <subnet-id> \
  --security-group-ids <security-group-id> \
  --tag-specifications 'ResourceType=instance,Tags=[{Key=Name,Value=nacos}]'

Wait until the instance reaches the Running state and its status checks pass. Then note its public IP address or DNS name from the EC2 console or with aws ec2 describe-instances.

Connect over SSH with your key pair and the login user for your operating system variant.

OS variant SSH login user

Ubuntu 24.04 ubuntu

ssh -i <key-name>.pem ubuntu@<public-ip>

Two systemd units make up the running product. nacos.service is the platform itself. nginx.service terminates TLS and publishes the console.

Check that both units are active:

systemctl is-active nacos.service nginx.service

Both units report active:

active active

The platform binds its OpenAPI and gRPC base port, its gRPC client port and the console port. nginx binds ports 80 and 443. Check the listeners:

ss -tln | grep -E ':(80|443|8848|9848|8080) '

The ports are used as follows:

• Port 8848 carries the naming and configuration OpenAPI.
• Port 9848 is the gRPC client port used by the software development kits (SDKs).
• Port 8080 is the console, bound for the reverse proxy.
• Ports 80 and 443 are nginx.

The platform runs on a Java 17 runtime:

java -version

The administrator password is generated on the first boot of your instance and written to a root-only file. Read it with sudo:

sudo cat /root/nacos-credentials.txt

The file records the username, the generated password, the console URL and the server address your applications should use:

NACOS_ADMIN_USERNAME=nacos NACOS_ADMIN_PASSWORD=<NACOS_ADMIN_PASSWORD> NACOS_CONSOLE_URL=https://<instance-public-ip>/ NACOS_SERVER_ADDR=<instance-public-ip>:8848

Treat this file as a secret. It is mode 0600 and owned by root, so only the root user can read it.

Browse to https://<instance-public-ip>/. Sign in as nacos with the password from the previous step.

The console is published over HTTPS with a self-signed certificate generated for your instance on first boot. Your browser shows a certificate warning the first time you visit. Step 11 explains how to replace it with a certificate from a certificate authority.

The stock nacos / nacos login that ships with unconfigured Nacos deployments is not present on this image. Only the generated per-instance password works.

Choose Services, then Service List in the left-hand navigation. The page lists every service that has registered with the platform. It shows each service's instance count and how many of those instances are currently healthy.

Select Detail on a service to see its individual instances. Each instance shows its IP address, port, weight and health state. The page also shows the service's protection threshold and cluster configuration.

The Nacos 3.2 console renders a red "Threshold Triggered" tag against every row of the service list, regardless of the real protection state. The authoritative values are the Healthy Instances count on this list and the per-instance Healthy badge on the detail page.

Choose Configuration, then Configurations. The page lists every configuration the platform stores, identified by its data ID and group, with the format of each entry.

Select Detail on an entry to see its full content, its checksum and when it was last modified. From there you can open the edit and history views and roll back to an earlier revision.

Choose New Config to publish a configuration. Give it a data ID that your application will ask for. Leave the group as DEFAULT_GROUP unless you separate environments by group. Pick the format, enter the content and choose Publish.

Clients that listen for that data ID receive the change without a restart.

The image ships a self test that proves the full security posture and the naming round trip in one command. It confirms three things. An unauthenticated registration attempt is rejected. The stock nacos / nacos credential is refused. A login with your generated administrator password returns an access token that can register a service instance and read it back.

Run the self test:

sudo /opt/nacos/nacos-selftest.sh

A healthy instance reports that the round trip succeeded, naming the address it registered and read back.

The load balancer health probe on port 80 is open and unauthenticated. Point an AWS target group at it:

curl -s -o /dev/null -w '%{http_code}\n' http://127.0.0.1/healthz

It answers 200. Any other path on port 80 redirects to HTTPS:

curl -s -o /dev/null -w '%{http_code}\n' http://127.0.0.1/

This answers 301.

Your applications talk to the platform at the server address recorded in the credentials file. This is the instance address with port 8848.

Server API authentication is enabled on this image, so a client must present an access token. Post your administrator username and password to the login endpoint to obtain one. Then pass the returned accessToken on subsequent calls.

For a Spring Cloud Alibaba application, put the server address, username and password into your application configuration. The starter then obtains and refreshes the token for you. For direct API use, request a token, then call the naming or configuration API with it.

Create a dedicated user in the console under the platform's authentication settings. Do not distribute the administrator password to every application.

The gRPC client port 9848 must also be reachable from your application networks. The 2.x and 3.x software development kits use it for service discovery and configuration listening. Discovery silently degrades if only 8848 is open.

The console is served over HTTPS with a self-signed certificate generated for your instance on first boot, which is why browsers show a warning. To present a certificate from a certificate authority, point a DNS name at your instance and obtain a certificate for that name. Then replace the certificate and key that nginx reads:

• Certificate: /etc/nginx/tls/nacos.crt
• Private key: /etc/nginx/tls/nacos.key

Keep the same paths and file permissions, then reload nginx. The private key must remain mode 0600 and owned by root.