Apollo Config on AWS User Guide

Overview

Apollo (apolloconfig/apollo) is an open source distributed configuration management center. Applications fetch typed, versioned configuration at runtime and receive updates in real time without a redeploy, while operators get per-environment and per-cluster namespaces, release and rollback history, grey-scale (canary) releases, and a complete audit trail. Rather than baking configuration into each application build, teams manage it centrally from one web console and push changes to running clients.

The cloudimg image delivers Apollo as a single-instance appliance: the Apollo config service, admin service, and portal (three Java 17 Spring Boot services) run under systemd, backed by an on-box MySQL 8.0 database holding the two Apollo schemas. Only the portal is reachable from the network, fronted by an nginx TLS reverse proxy; the config service, admin service, and database are bound to localhost. The image is secure by default and installs nothing on first boot except your own credentials. Backed by 24/7 cloudimg support.

What is included:

• Apollo 2.5.2 (Apache-2.0), installed from the official GitHub release artifacts and SHA verified at build time, with the LICENSE baked at /opt/apollo/LICENSE
• The three Apollo services managed by systemd: apollo-configservice (config service and embedded Eureka meta server, 127.0.0.1:8080), apollo-adminservice (internal management API, 127.0.0.1:8090), and apollo-portal (web console, 127.0.0.1:8070)
• MySQL 8.0 holding ApolloConfigDB and ApolloPortalDB, on a dedicated EBS data volume at /var/lib/mysql, listening on 127.0.0.1:3306 only
• OpenJDK 17 from the Ubuntu repositories, so the Java runtime keeps receiving security updates
• An nginx TLS reverse proxy on port 443 in front of the portal, with a self-signed certificate regenerated per instance on first boot
• Per-instance portal administrator, application database, MySQL root, and Debian maintenance passwords, all generated on first boot and written to a root-only file. The well-known upstream apollo / admin portal login is destroyed in the image and is rejected on your instance
• 24/7 cloudimg support

Connecting to your instance

Connect over SSH on port 22 using the private key for the key pair you selected at launch. The login user depends on the operating system variant you launched:

ssh -i /path/to/your-key.pem ubuntu@<instance-public-ip>

Prerequisites

An AWS account, an EC2 key pair, and a VPC subnet. m5.large (2 vCPU, 8 GB RAM) is the recommended instance type and comfortably runs the three Apollo services plus MySQL; move to an m5.xlarge or larger for large configuration estates or many client applications.

In the instance's security group, allow inbound TCP 443 from the addresses that should reach the portal, and TCP 22 for administration. Restricting 443 to your own office or VPN CIDR is strongly recommended. No other ports need to be open: the config service, admin service, and database are bound to localhost.

Step 1 - Launch from AWS Marketplace

In the AWS Marketplace console find Apollo Config by cloudimg and choose Continue to Subscribe, then Continue to Configuration and Continue to Launch. Pick your region, the m5.large instance type, your VPC subnet, your key pair, and a security group that allows inbound 22 and 443.

Step 2 - Launch from the EC2 CLI

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

Step 3 - Confirm the services are running

All five services should report active. The only network-reachable ports are SSH (22) and the TLS portal (443); the config service, admin service, and MySQL are bound to localhost:

for s in mysql nginx apollo-configservice apollo-adminservice apollo-portal; do
  echo "$s -> $(systemctl is-active "$s")"
done
echo "--- network-reachable TCP listeners (expect only :22 and :443) ---"
ss -tlnH | awk '{print $4}' | grep -vE '127\.0\.0\.[0-9]+|\[::1\]' | sort -u

The portal answers over TLS on 443, and also on its loopback port behind the proxy:

curl -sk -o /dev/null -w 'portal via nginx (https 443) -> HTTP %{http_code}\n' https://127.0.0.1/signin
curl -s  -o /dev/null -w 'portal loopback (8070)        -> HTTP %{http_code}\n' http://127.0.0.1:8070/signin

Step 4 - Retrieve the portal password

Every instance generates its own portal administrator password on first boot and writes it, along with the database credentials, to a root-only file. Retrieve it over SSH:

sudo cat /root/apollo-config-credentials.txt

The file contains the portal URL, the portal user (apollo), the generated APOLLO_PORTAL_PASSWORD, and the MySQL application and root passwords. The upstream default apollo / admin login does not work on your instance.

Step 5 - Sign in to the portal

Browse to https://<instance-public-ip>/. The image ships a self-signed certificate regenerated for your instance, so your browser will warn on first visit; accept the warning (or install a trusted certificate, see hardening below). Sign in as user apollo with the password from Step 4.

After signing in you land on the project list, where every configured application appears with its owner and department.

Step 6 - Create your first application and configuration

Choose Create project, give it an AppId (the identifier your client application uses to fetch configuration, for example order-service), a name, and an owner, then create it. Open the project and use Add Configuration to add typed key/value items to the application namespace.

Nothing is delivered to clients until you publish. Choose Release to publish the namespace; each release is recorded with its author and comment. Open Release History to see every version, compare changes, and roll back to a previous release with one click.

Step 7 - Consume configuration from a client application

Client applications fetch configuration from the config service. For security the config service is bound to localhost by default, so a client running on the same instance reads it directly:

curl "http://127.0.0.1:8080/configs/order-service/default/application"

The response is the released key/value set for that application, cluster, and namespace. Apollo publishes official clients for Java and .NET, and any language can use the HTTP API above. Point the client at the config service address and set the app.id to the AppId you created.

Step 8 - Expose the config service to your application subnet

When your client applications run on other hosts, expose the config service (port 8080) deliberately and safely rather than opening it to the world:

1. In the Apollo portal, open Manage AccessKey for the application and enable an access key, so clients must authenticate to read configuration.
2. Bind the config service to the instance's private address instead of loopback by editing its systemd unit override, or place it behind an internal load balancer, and open port 8080 only to your application subnet in the security group.

Leaving the config service on localhost with no access key, as shipped, is the safe default: only workloads on the instance itself can read configuration until you choose to widen access.

Security and hardening

• Restrict the security group. Allow 443 only from trusted CIDRs and 22 only from your administration network.
• Install a trusted certificate. The image ships a self-signed certificate at /etc/nginx/ssl/apollo.crt. For production, replace it with a certificate for your own domain, or terminate TLS at an AWS load balancer with a certificate from AWS Certificate Manager and point the portal behind it.
• Enable EBS encryption for data at rest on the root and MySQL data volumes.
• The database is private. MySQL and the internal Apollo services listen only on localhost; do not change this unless you have a specific need, and use access keys if you do.
• Migrate to Amazon RDS if you want managed backups and Multi-AZ failover for the configuration database.

Maintenance

Check status and logs of any service with systemd and the journal:

systemctl status apollo-portal --no-pager | head -5

Operating-system security updates are delivered by Ubuntu's unattended-upgrades, and the OpenJDK runtime is apt-managed so it keeps receiving updates. The Apollo services restart automatically on failure and on reboot.

Support

Every subscription includes 24/7 cloudimg technical support via email (support@cloudimg.co.uk) and live chat, covering deployment, upgrades, performance tuning, database administration, and integrating Apollo with your applications.