Dragonfly 2.5.3

In the AWS Marketplace listing, choose Continue to Subscribe, then Continue to Configuration. Select Dragonfly 2.5.3 on Ubuntu 24.04 as the software version, choose your Region, and select Launch through EC2.

Choose m5.large, your key pair, the security group described above and a subnet. The AMI has an 8 GiB root volume, and the dfdaemon piece cache lives on it (/var/lib/dragonfly/storage). Raise the root volume under Configure storage to fit the files you plan to cache.

Alternatively, launch with the AWS CLI. Replace the values in angle brackets. This command sets the root volume to 100 GiB:

aws ec2 run-instances --region <region> --image-id <ami-id-from-the-listing> \
  --instance-type m5.large --key-name <your-key-pair> \
  --security-group-ids <your-security-group> --subnet-id <your-subnet> \
  --metadata-options HttpTokens=required,HttpEndpoint=enabled \
  --block-device-mappings 'DeviceName=/dev/sda1,Ebs={VolumeSize=100,VolumeType=gp3}' \
  --tag-specifications 'ResourceType=instance,Tags=[{Key=Name,Value=dragonfly}]'

Version SSH user

Dragonfly 2.5.3 on Ubuntu 24.04 ubuntu

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

On first boot, the instance creates the database, the secrets, the configuration and the console account, then starts Dragonfly and publishes the console. This takes about half a minute. Confirm that all services are active:

systemctl is-active dragonfly-firstboot mariadb redis-server dragonfly-manager dragonfly-scheduler dragonfly-dfdaemon nginx

active active active active active active active

Only SSH (22) and nginx (80, 443) listen on the network. Everything else listens on 127.0.0.1: MariaDB (3306), Redis (6379), the manager (8080 console and REST API, 65003 gRPC), the scheduler (8002) and the dfdaemon (4000 to 4005, and UDP 4006). The two port 53 entries are Ubuntu's local DNS resolver.

sudo ss -lntu | awk 'NR>1 {print $1, $5}' | sort -u

tcp 0.0.0.0:22 tcp 0.0.0.0:443 tcp 0.0.0.0:80 tcp 127.0.0.1:3306 tcp 127.0.0.1:4000 tcp 127.0.0.1:4001 tcp 127.0.0.1:4002 tcp 127.0.0.1:4003 tcp 127.0.0.1:4004 tcp 127.0.0.1:4005 tcp 127.0.0.1:6379 tcp 127.0.0.1:65003 tcp 127.0.0.1:8002 tcp 127.0.0.1:8080 tcp 127.0.0.53%lo:53 tcp 127.0.0.54:53 tcp [::]:22 tcp [::]:443 tcp [::]:80 udp 127.0.0.1:4006 ...

The manager's health endpoint needs no sign-in, and the programs report their versions:

curl -sk https://127.0.0.1/healthy; echo /opt/dragonfly/bin/manager version | grep GitVersion dfget --version

"OK" GitVersion: v2.5.3 dfget 1.5.10 (024c6e9c7, 2026-10-26)

If nginx serves nothing, first boot has not finished, or it failed. In that case nothing is published and Dragonfly does not start. Check systemctl status dragonfly-firstboot and journalctl -u dragonfly-firstboot.

sudo cat /root/dragonfly-credentials.txt

The file is readable by root only. It holds the address, the Basic authentication credential, the console sign-in and the passwords the Dragonfly services use for MariaDB and Redis:

# Dragonfly on Ubuntu 24.04 (sac AWS Marketplace image) - this instance's sign-in. ... DRAGONFLY_CONSOLE_URL=https://ec2-203-0-113-10.compute-1.amazonaws.com/ CONSOLE_BASIC_AUTH_USER=admin CONSOLE_BASIC_AUTH_PASSWORD=<CONSOLE_BASIC_AUTH_PASSWORD> MANAGER_ADMIN_USER=root MANAGER_ADMIN_PASSWORD=<MANAGER_ADMIN_PASSWORD> MANAGER_DB_USER=dragonfly MANAGER_DB_PASSWORD=... REDIS_PASSWORD=...

You can verify the whole setup from the instance itself. The helper goes through nginx and checks that the console refuses a missing or wrong Basic credential. It checks that self-registration, root/dragonfly and a wrong password are refused, and that your root password signs in. It then pulls a 6 MiB test file through the dfdaemon seed peer and compares its checksum. On success it prints DRAGONFLY_ROUNDTRIP_OK:

sudo /usr/local/sbin/dragonfly-verify.sh | tail -1

DRAGONFLY_ROUNDTRIP_OK

The certificate is self-signed until you install your own (Step 8). Before you accept it in the browser, compare its SHA-256 fingerprint with the one the browser shows:

sudo openssl x509 -in /etc/ssl/dragonfly/dragonfly.crt -noout -fingerprint -sha256

sha256 Fingerprint=3F:A1:...:7C

Open the DRAGONFLY_CONSOLE_URL address in your browser and accept the certificate once, after comparing the fingerprint. When the browser asks for a user name and password, enter admin and the CONSOLE_BASIC_AUTH_PASSWORD. On the console sign-in page that follows, enter root and the MANAGER_ADMIN_PASSWORD.

The sign-in page offers Create an account, but self-registration is switched off on this image and nginx refuses it. A self-registered account could read every cluster, job and audit record. Add people from the console (User) or connect an OAuth provider instead.

Change the console password now. Open the account menu at the bottom left, choose Profile, and set a password of your own (8 to 16 characters, with at least one lower case letter and one digit). nginx allows two sign-in attempts a second per address, with a short burst, so a script hammering the sign-in is slowed down with HTTP 429.

The console opens on the cluster list. The single cluster cluster-1 holds this instance's scheduler and its seed peer:

dfget asks the local dfdaemon to download a URL. The dfdaemon fetches the file from its origin in pieces, or from its cache, or from other peers when you run a cluster, and writes it to the output path. The following example downloads the Dragonfly licence file and checks its published checksum:

F=/tmp/dragonfly-LICENSE-$$
sudo dfget https://raw.githubusercontent.com/dragonflyoss/dragonfly/v2.5.3/LICENSE -O "$F" >/dev/null
sudo sha256sum "$F" | cut -c1-64

c71d239df91726fc519c6eb72d318ec65820627232b2f796219e87dcf35d0ab4

Keep these points in mind when you use dfget on this image:

• The dfdaemon writes the output file as the dragonfly account (mode 0640, group dragonfly). The output directory must therefore be writable by dragonfly, for example /tmp or a directory you create and give to dragonfly.
• Only root and members of the dragonfly group can use dfget, because the dfdaemon's socket directory is closed to everyone else. Add a user with sudo usermod -aG dragonfly <user>.
• The origin must support HTTP range requests, which most web servers, S3 and CDNs do. dfget --help lists the object storage schemes (s3://, gs:// and others) and options such as --digest sha256:<hash>, which makes dfget verify the file's checksum.

Preheat loads files or container images into the cache before anyone asks for them. In the console, open Job, then Preheat, and choose Add preheat. Enter a file URL (or an image reference and its registry credentials), pick the cluster and create the job. The list shows each run:

The console marks a preheat run as finished even when its download failed, so open the run to see which peers succeeded. For automation, create a personal access token under Developer and call the open API (https://<your-host>/oapi/v1/jobs) with Authorization: Bearer <token>. The open API does not use the Basic credential.

The dfdaemon also runs an HTTP proxy on 127.0.0.1:4001. A container runtime on this instance can use it as a registry mirror (Docker Hub by default), so image layers travel through the P2P cache. Point containerd or Docker on the instance at http://127.0.0.1:4001, as described in the Dragonfly documentation. The proxy listens on localhost only, so it is not an open proxy.

Point a DNS record at the instance. An Elastic IP keeps the address across stop and start. Then tell the instance its name. This command mints a new self-signed certificate for that name and updates the nginx host rule, the origin and cross-site guards and the address in the credentials file. It also keeps the name across reboots:

sudo dragonfly-set-hostname dragonfly.example.com

To use a certificate from a public authority instead, replace /etc/ssl/dragonfly/dragonfly.crt (full chain) and /etc/ssl/dragonfly/dragonfly.key (mode 0600, owned by root) with your own, then run sudo systemctl reload nginx. If you run dragonfly-set-hostname again later, it replaces them with a new self-signed pair.

To change the Basic authentication password, write a new hash and reload nginx. openssl asks for the new password twice:

sudo sh -c 'printf "admin:%s\n" "$(openssl passwd -6)" > /etc/nginx/dragonfly.htpasswd'
sudo chown root:www-data /etc/nginx/dragonfly.htpasswd && sudo chmod 0640 /etc/nginx/dragonfly.htpasswd
sudo systemctl reload nginx

This image is a closed single node. To let dfdaemons on other machines use it as their manager, scheduler and seed peer, make the manager's gRPC port (65003), the scheduler (8002) and the dfdaemon's upload and piece ports (4000, 4005, 4006/udp) listen on the instance's private address. Set listenIP and advertiseIP in /etc/dragonfly/manager.yaml and scheduler.yaml, and the ip fields in dfdaemon.yaml. Then open those ports in the security group.

The Dragonfly gRPC services have no authentication of their own. Open them only to the private address ranges of your own peers, never to the internet, and consider Dragonfly's mutual TLS options. The Dragonfly documentation describes multi-node deployments.

Every service is enabled, so Dragonfly returns after a reboot or a stop and start. If the public address changes, the next boot re-issues the certificate and the address for the new name, unless you set your own name in Step 8. Unattended security upgrades keep the operating system, MariaDB, Redis and nginx patched:

systemctl is-enabled mariadb redis-server dragonfly-manager dragonfly-scheduler dragonfly-dfdaemon dragonfly-set-host nginx unattended-upgrades

enabled enabled enabled enabled enabled enabled enabled enabled

SecureAnyCloud builds the manager and scheduler from the 2.5.3 source, and /usr/share/doc/sac/dragonfly/BUILD-PROVENANCE.txt records how. SecureAnyCloud publishes a new version of this image for new Dragonfly releases.

To move to a newer release yourself, back up first (Step 11). Then replace the programs in /opt/dragonfly/bin with the new releases from the Dragonfly releases page and the client releases page, and restart the three dragonfly-* services. Read the release notes first, because a new manager may migrate its database.

The manager's state (clusters, jobs, users, tokens) is in the MariaDB database manager, and the configuration is in /etc/dragonfly. The dfdaemon cache in /var/lib/dragonfly/storage can always be rebuilt from the origins. An EBS snapshot of the root volume, or AWS Backup on the instance, captures everything. To take a database dump, run:

sudo mariadb-dump --single-transaction manager | gzip > dragonfly-manager.sql.gz