Media & Entertainment Azure

Afanasy 3.4.1 on Ubuntu 24.04 on Azure User Guide

| Product: Afanasy 3.4.1 on Ubuntu 24.04 LTS on Azure

Overview

This guide covers the deployment and configuration of Afanasy 3.4.1 on Ubuntu 24.04 on Azure using cloudimg Azure Marketplace images. Afanasy is the render farm manager from CGRU (github.com/CGRU/cgru, LGPL-3.0), an open source computer graphics tools pack. Its afserver is the central coordinator that dispatches rendering work: render nodes connect to it, pull tasks and report progress, while artists and administrators submit jobs and watch the farm through afserver's built-in browser Web Monitor — a live dashboard of jobs, render nodes, pools and users.

This appliance ships the afserver coordinator and its Web Monitor as a secure, standalone, single-VM appliance. It boots ready to run and is provable on its own — the server is live and the Web Monitor renders the farm — and you add your own render nodes (afrender) to it afterwards. The image is built from the official CGRU 3.4.1 source, verified against a sha256 checksum at build time, and compiled server-only (no Qt desktop tools), so it is a lightweight C++ service that fits comfortably on a Standard_B2s.

What is included:

  • Afanasy afserver 3.4.1 (github.com/CGRU/cgru, LGPL-3.0), compiled from a sha256-pinned source tarball, server-only (--nogui --nosql)
  • The Afanasy browser Web Monitor (the render farm dashboard), served by afserver's built-in HTTP server
  • afserver.service systemd unit running the coordinator as a dedicated unprivileged afanasy account
  • cgru-firstboot.service systemd oneshot that mints the per-VM Web Monitor credential, generates a per-VM TLS certificate and starts the server before anything is exposed
  • nginx fronting :443 (per-VM self-signed certificate) with :80 redirecting to :443, reverse proxying the Web Monitor behind HTTP Basic auth
  • An unauthenticated /healthz endpoint (HTTP 200) wired to the server for load balancer / probe checks
  • All render farm state (the afserver store) on a dedicated 30 GiB Azure data disk mounted at /var/lib/cgru
  • Ubuntu 24.04 LTS base with latest security patches applied at build time and unattended security updates enabled
  • Azure Linux Agent for seamless cloud integration and SSH key injection
  • 24/7 cloudimg support with a guaranteed 24 hour response SLA

Architecture

afserver binds 0.0.0.0:51000 — a single port that carries both the binary render-node protocol (how afrender nodes connect) and the built-in HTTP server that serves the Web Monitor. On the shipped image the Azure Network Security Group opens only ports 22, 80 and 443, so :51000 is never reachable from outside the VM. nginx terminates :443 with a per-VM self-signed certificate and reverse proxies the Web Monitor to 127.0.0.1:51000, gated by per-VM HTTP Basic auth; :80 redirects to :443. Because Afanasy has no built-in Web Monitor login, this authenticated front door is what keeps the dashboard private, and the image ships with no credential baked in.

Step 1: Deploy the image

Launch the Afanasy 3.4.1 on Ubuntu 24.04 by cloudimg image from the Azure Marketplace on a Standard_B2s (or larger) VM. Open inbound ports 22 (SSH), 80 (HTTP) and 443 (HTTPS) in the Network Security Group. The 30 GiB data disk that holds the afserver store is provisioned automatically from the image.

Once the VM is running, connect over SSH as azureuser with the SSH key you selected at launch:

ssh azureuser@<public-ip>

Step 2: Confirm the services are running

The Afanasy server and nginx start automatically on boot. Confirm both are active:

systemctl is-active afserver nginx

Each command should print active. For the full status view:

systemctl --no-pager status afserver nginx | grep -E 'afserver.service|nginx.service|Active:' | head

afserver and nginx services both active

Step 3: Retrieve the per-VM Web Monitor credential

The Web Monitor is protected by HTTP Basic auth with a username and password that are unique to your VM and generated on first boot. Read them from the credentials file:

sudo cat /etc/cloudimg-credentials.txt

The AFANASY_WEB_USER and AFANASY_WEB_PASSWORD values are your Web Monitor credential. Keep the password secret — it grants full access to the render farm dashboard.

The per-VM credentials file with the generated Web Monitor username and password

Step 4: Check server health

The /healthz endpoint is unauthenticated and confirms the server is up, so it is safe to use for a load balancer or availability probe. The server's own HTTP port 51000 is only reachable from inside the VM:

curl -ks https://127.0.0.1/healthz
echo
curl -s -o /dev/null -w 'afserver HTTP %{http_code}\n' http://127.0.0.1:51000/

Both should report HTTP 200 — nginx answers /healthz and afserver answers on its own port on the loopback interface.

The unauthenticated health endpoint and afserver responding on port 51000

Step 5: Prove the authenticated front door

The Web Monitor itself requires the per-VM credential. Authenticate with it and you get HTTP 200; without a credential, or with the wrong one, nginx rejects the request with HTTP 401 — the image ships no default login:

WEB_USER=$(sudo grep '^AFANASY_WEB_USER=' /etc/cloudimg-credentials.txt | cut -d= -f2-)
WEB_PASS=$(sudo grep '^AFANASY_WEB_PASSWORD=' /etc/cloudimg-credentials.txt | cut -d= -f2-)
echo "authenticated: $(curl -ks -o /dev/null -w '%{http_code}' -u "$WEB_USER:$WEB_PASS" https://127.0.0.1/)"
echo "no credential: $(curl -ks -o /dev/null -w '%{http_code}' https://127.0.0.1/)"
echo "wrong password: $(curl -ks -o /dev/null -w '%{http_code}' -u "$WEB_USER:wrong" https://127.0.0.1/)"

The authenticated request returns 200; the other two return 401.

The Basic auth round-trip returning 200 authenticated and 401 for no or wrong credential

Step 6: Open the Web Monitor

Browse to https://<public-ip>/ and accept the per-VM self-signed certificate. Your browser prompts for the Basic auth credential — enter the AFANASY_WEB_USER and AFANASY_WEB_PASSWORD from Step 3. The Afanasy Web Monitor opens on its Jobs view, showing the live server and its built-in system jobs (post_commands, wake-on-lan, events) that keep the farm running:

The Afanasy Web Monitor Jobs dashboard showing the live afserver and its system jobs

Step 7: Review the render farm

Select Farm in the top navigation to see the render pool tree. On a fresh appliance the farm is empty — the root pool / is present and ready, and you add render nodes to it. The left-hand panel gives you the full pool controls (create pools, free or heal hosts, manage power and tickets):

The Afanasy Web Monitor Farm view showing the empty render pool ready for nodes

The Users view lists the users the server knows about, with their job and error-solving settings:

The Afanasy Web Monitor Users view

The Monitors view lists the connected Web Monitors, confirming your live dashboard session is registered with the server:

The Afanasy Web Monitor Monitors view showing the connected monitor session

Step 8: Add your own render nodes

The appliance ships the coordinator only; you connect your own render machines to it. On each render machine, install CGRU, point it at this server's address and start afrender so it registers with the farm. Because the server port 51000 is closed at the Network Security Group by default, open it (or a private subset of it) to the machines that will run afrender — treat it as an internal, trusted-network port rather than a public one, since the render protocol is not fronted by the Basic auth that protects the Web Monitor. As nodes come online they appear in the Farm view and start taking tasks from any jobs you submit.

Step 9: Where the data lives

The afserver store — jobs, the render-node registry and the server's working state — lives on the dedicated Azure data disk mounted at /var/lib/cgru. Confirm the store is on the data disk:

mountpoint /var/lib/cgru
ls -la /var/lib/cgru/store

The store directory is /var/lib/cgru/store, so your render farm state survives independently of the OS disk and the volume can be resized on its own.

Managing the service

Restart or check the Afanasy services with systemd:

sudo systemctl restart afserver
sudo systemctl status afserver --no-pager | head

afserver is a lightweight C++ service and idles in a few hundred megabytes, so a Standard_B2s (2 vCPU / 4 GB) comfortably runs the coordinator for a small-to-medium farm. For very large farms with many nodes and heavy job volumes, launch on a larger VM size — the server picks up the additional resources automatically.

Security notes

  • No default credential. The image ships with no Web Monitor password and no TLS certificate; first boot mints a unique Basic auth credential and generates a per-VM certificate. There is no shared login anywhere in the image.
  • Rotate the Web Monitor credential for production use: generate a new entry with sudo htpasswd -B /etc/nginx/.htpasswd afadmin and reload nginx.
  • The Web Monitor is only reachable over :443 (nginx, TLS, Basic auth); afserver's :51000 binds inside the VM and is firewalled by the Network Security Group, which opens only 22, 80 and 443.
  • Treat the render port 51000 as an internal port. Open it only to the trusted machines that run afrender, not to the public internet — the render protocol has no Basic auth.
  • Replace the per-VM self-signed certificate under /etc/nginx/ssl/ with a CA-issued certificate for your DNS name in production.
  • Keep the VM patched — unattended security updates are enabled by default.

Troubleshooting

  • Browser shows a certificate warning: expected — the image generates a per-VM self-signed certificate. Install a CA-issued certificate for production.
  • The Web Monitor prompts for a password again: confirm you are entering the exact AFANASY_WEB_USER and AFANASY_WEB_PASSWORD from /etc/cloudimg-credentials.txt.
  • A render node does not appear in the Farm view: confirm the node can reach the server on port 51000 (open it at the Network Security Group for that machine) and that afrender is pointed at this server's address.
  • Inspect logs: journalctl -u afserver and journalctl -u nginx.

Support

cloudimg images come with 24/7 support and a guaranteed 24 hour response SLA. Contact support through the Azure Marketplace listing or at cloudimg.co.uk.