Netflix Eureka Server on Ubuntu 24.04 on Azure User Guide

Overview

Netflix Eureka is an open source service registry for microservices. Each service instance registers itself with Eureka when it starts, sends a regular heartbeat while it stays healthy, and is removed when it goes away, so the registry always holds a current picture of what is running and where. Other services then look an instance up by its logical name instead of a hard coded address, which is what makes client side load balancing, failover and elastic scaling practical in a distributed system.

Netflix ships Eureka only as a library, with no official standalone server binary, so this cloudimg image provides the standard standalone Eureka server: a minimal Spring Boot application built around spring-cloud-starter-netflix-eureka-server with @EnableEurekaServer, compiled into a self contained executable at build time so nothing is fetched at runtime. It runs as a single node registry with a web dashboard that lists every registered application and the REST registration API that clients talk to, on a hardened, fully patched Ubuntu 24.04 LTS base.

Eureka serves its dashboard and its registration API with no authentication at all by default. This image closes that gap: the server is bound to the loopback interface and reached only through an nginx reverse proxy, and both the dashboard and the /eureka/** registration endpoints sit behind an HTTP Basic authentication wall. A unique administrator password is generated on the first boot of every VM and recorded in a root only file, and the server is held back from serving until that per VM credential exists. Backed by 24/7 cloudimg support.

What is included:

• A standalone Netflix Eureka server (Spring Boot, Spring Cloud 2023.0.x, Netflix eureka-core 2.0.3) served by nginx on port 80
• HTTP Basic authentication protecting both the dashboard and the /eureka/** registration API, enabled by default
• A per VM administrator password generated on first boot and written to a root only file, with no known or blank credential shipped in the image
• The Eureka server bound to 127.0.0.1:8761 only, never exposed to the network except through the nginx reverse proxy
• An unauthenticated /actuator/health liveness endpoint on the loopback port for health checks
• eureka.service and nginx.service as enabled systemd units, gated behind a first boot bootstrap step
• A hardened, fully patched Ubuntu 24.04 LTS base with unattended security upgrades enabled
• 24/7 cloudimg support

Prerequisites

An active Azure subscription, an SSH key pair, and a VNet plus subnet in the target region. Standard_B2s (2 vCPU / 4 GiB RAM) is a sensible starting point and is what the image is tuned for; size up for a larger fleet of registering services. NSG inbound: allow 22/tcp from your management network and 80/tcp for the dashboard and the registration API. Eureka serves plain HTTP on port 80; for production, terminate TLS in front of it with your own domain. The Eureka server itself is never exposed directly: it listens on 127.0.0.1:8761 only, so that port stays off the network.

Step 1 - Deploy the image

Option A: Azure portal

1. In the Azure portal, open Create a resource and search for Netflix Eureka Server on Ubuntu 24.04 LTS by cloudimg.
2. Select the plan and click Create.
3. On the Basics tab, choose your subscription, resource group and region, name the VM, and select Standard_B2s.
4. Set Authentication type to SSH public key, with azureuser as the username, and provide your public key.
5. On the Networking tab, allow inbound 22/tcp (from your IP) and 80/tcp.
6. Review and create. When deployment completes, note the VM's public IP address.

Option B: Azure CLI

az vm create \
  --resource-group my-eureka-rg \
  --name eureka \
  --image cloudimg:eureka-ubuntu-24-04:default:latest \
  --size Standard_B2s \
  --admin-username azureuser \
  --generate-ssh-keys \
  --public-ip-sku Standard
az vm open-port --resource-group my-eureka-rg --name eureka --port 80 --priority 900

Step 2 - Confirm the services are running

SSH in as azureuser and confirm the two systemd units are active. eureka.service is the Spring Boot Eureka server on the loopback port, and nginx.service is the reverse proxy on port 80.

systemctl is-active eureka nginx

Expected output:

active
active

The Eureka server binds 127.0.0.1:8761 only, and nginx is the sole listener on the public port 80. You can confirm this at a glance:

Step 3 - Retrieve the administrator password

The dashboard and the registration API are protected by HTTP Basic authentication. The username is admin and the password is generated uniquely on the first boot of every VM and written to a root only file. Read it over SSH:

sudo cat /root/eureka-credentials.txt

The file is owned by root with mode 600, and records the dashboard URL, the registry URL that clients register against, the admin username and the generated password:

Confirm the server is live with the unauthenticated liveness probe, which is the only endpoint served without a credential:

curl -s http://127.0.0.1:8761/actuator/health

Expected output:

{"status":"UP"}

Step 4 - Sign in to the dashboard

Open http://<public-ip>/ in a browser. The browser prompts for HTTP Basic credentials; enter admin and the password from Step 3. The Eureka dashboard shows the system status, the registered instances and the server's own metadata. With services registered it looks like this:

The Instances currently registered with Eureka table is the heart of the registry: it lists every application that has registered, each with its status and instance identifier. Here a dozen example microservices are all registered and UP:

Scrolling down, the General Info and Instance Info panels report the server's memory, CPU count, uptime and address:

Step 5 - Register a service and explore the registry

Services register with Eureka through the /eureka/** REST API. In a Spring Boot service you normally add the Eureka client starter and point it at this server; because the registry is protected, include the admin credential in the service URL:

eureka:
  client:
    service-url:
      defaultZone: http://admin:PASSWORD@your-eureka-host/eureka/
  instance:
    prefer-ip-address: true

You can confirm the registry contents at any time from the authenticated REST API. This returns the standard Eureka applications document listing every registered instance:

curl -s -u admin:<EUREKA_ADMIN_PASSWORD> -H 'Accept: application/json' http://127.0.0.1/eureka/apps

The dashboard's Last 1000 since startup view lists the recent registration events, which is a quick way to confirm a newly started service reached the registry:

Step 6 - The security model

Eureka is unauthenticated out of the box; this image enables an HTTP Basic authentication wall over both the dashboard and the registration API, with a per VM password. You can prove the wall end to end: an anonymous request and a wrong password are both refused, the open liveness probe answers, and only the correct per VM password is served.

curl -s -o /dev/null -w '%{http_code}\n' http://127.0.0.1/eureka/apps
curl -s -o /dev/null -w '%{http_code}\n' -u admin:wrong-password -H 'Accept: application/json' http://127.0.0.1/eureka/apps
curl -s -o /dev/null -w '%{http_code}\n' -u admin:<EUREKA_ADMIN_PASSWORD> -H 'Accept: application/json' http://127.0.0.1/eureka/apps

Expected output (unauthenticated refused, wrong password refused, correct password served):

401
401
200

Key points of the security model:

• The password is never baked into the image. It is generated with openssl rand on the first boot of every VM and written to /root/eureka-credentials.txt (mode 600, root only).
• The Eureka server is gated behind a first boot bootstrap step, so it never serves before the per VM credential exists. No default or blank login ever authenticates.
• The server binds 127.0.0.1:8761 only; nginx on port 80 is the single external surface. For production, put your own TLS certificate and domain in front of nginx.
• Change the admin password by editing SPRING_SECURITY_USER_PASSWORD in /etc/eureka/eureka.env and restarting the service.

Step 7 - A hardened, current base

The image ships on a fully patched Ubuntu 24.04 LTS base with unattended security upgrades left enabled, so the platform keeps itself current. The Eureka server runs on OpenJDK 17 as an unprivileged eureka service account, and the bundled Netflix registry library is eureka-core 2.0.3.

Scaling and production notes

• Single node registry. This image runs one Eureka node, which is the right shape for most deployments and for getting started. For a highly available registry, run several of these VMs and configure each server's defaultZone to peer with the others.
• Client side use. Eureka is a discovery backbone: your services and gateways read the registry to resolve healthy instances. It does not proxy traffic itself.
• TLS. Terminate HTTPS at nginx or an Azure load balancer in front of the VM, using your own domain and certificate.

Support

Every cloudimg image is backed by 24/7 support. If you have any questions about this deployment, contact the cloudimg team.