Hubzilla on Ubuntu 24.04 on Azure User Guide

Overview

Hubzilla is an open source decentralized platform for building community websites and social networks. It combines a social network, a built in wiki and CMS, cloud file storage and photo albums, and hosted web pages, all organised around channels with a fine grained permission system. Its nomadic identity lets a channel be cloned across multiple hubs so an account survives the loss of any single server, and hubs federate over the Zot and Nomad protocols to connect with the wider fediverse. The cloudimg image ships Hubzilla 11.4 served by Apache with PHP 8.3 on a hardened, fully patched Ubuntu 24.04 LTS base, together with a bundled local MariaDB server so the appliance is complete and useful on its own. Hubzilla ships an empty database with no default account: the first person to register becomes the site administrator, and every per VM secret is generated on first boot. Backed by 24/7 cloudimg support.

What is included:

• Hubzilla 11.4 served by Apache 2 with PHP 8.3 (mod_php), managed by systemd
• A bundled MariaDB server holding the Hubzilla database, already installed and ready
• The Hubzilla hub served on :80 from /var/www/hubzilla, honouring the shipped rewrite rules
• The required background poller wired as a systemd timer (hubzilla-cron.timer), running every 10 minutes for delivery and maintenance
• An empty database with no default login: the first account you register becomes the administrator, and you choose the password
• Per VM secrets generated on first boot: the database password, the site federation salt, and the site RSA keypair, recorded in a root only file
• MariaDB bound to 127.0.0.1 only, never exposed to the network
• apache2.service, mariadb.service, hubzilla-firstboot.service and hubzilla-cron.timer as enabled systemd units
• 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; size up for larger or busier hubs. NSG inbound: allow 22/tcp from your management network and 80/tcp (and 443/tcp once you add TLS) for the hub. Hubzilla serves plain HTTP on port 80 out of the box; for production, front it with your own domain and a TLS certificate. The bundled MariaDB is never exposed: it listens on 127.0.0.1 only, so port 3306 stays off the network.

Step 1 - Deploy from the Azure Marketplace

Sign in to the Azure Portal, choose Create a resource, search the Marketplace for Hubzilla by cloudimg, and select Create. On Basics pick your subscription, resource group, region and size; under Administrator account choose SSH public key and paste your key; under Inbound port rules allow SSH (22) and HTTP (80). Then Review + create then Create.

Step 2 - Deploy from the Azure CLI

az vm create \
  --resource-group <your-rg> \
  --name hubzilla \
  --image <marketplace-image-urn> \
  --size Standard_B2s \
  --admin-username azureuser \
  --generate-ssh-keys \
  --public-ip-sku Standard

Then open port 80 to the hub:

az vm open-port --resource-group <your-rg> --name hubzilla --port 80

Step 3 - Confirm the services are running

SSH in as azureuser and confirm Apache, MariaDB, the first boot service and the poller timer are all active. Note that MariaDB listens only on 127.0.0.1:3306 while Apache serves the hub on port 80.

systemctl is-active apache2 mariadb hubzilla-firstboot hubzilla-cron.timer

ss -tlnp | grep -E ':80 |:3306 ' | sed 's/  */ /g'

Step 4 - Retrieve the per VM details

Every VM generates its own database password, site federation salt and site keypair on first boot, and writes the hub URL, the registration URL and the administrator email to a root only file. Read it with sudo:

sudo cat /root/hubzilla-credentials.txt

The database ships empty, so there is no preset login. The file records the email the first registrant should use to become the administrator. On the box itself you can also run sudo mariadb to reach the database directly over the local socket without a password.

Step 5 - Register the first account and become the administrator

Browse to http:// followed by your VM's public IP address, then open Register. Hubzilla ships an empty database, so the first account you create becomes the site administrator. Enter a name, a short nickname (this becomes your channel address), the administrator email shown in Step 4 (admin@example.com by default), and a strong password of your own choosing, accept the Terms of Service, and select Register. To use your own email instead, edit App::$config['system']['admin_email'] in /var/www/hubzilla/.htconfig.php first, then register with that email.

Step 6 - Your channel home

After registering you are signed in and your first channel is created. The channel home is your hub's stream, with a Start a conversation box to publish to your channel and the New Member Links panel to guide you through setting up your profile, connecting with others and exploring the hub.

Step 7 - Post to your channel stream

Use the Start a conversation box to write a post and share it to your channel. Your post appears immediately in the stream with the like, repeat and react controls and a comment box, so your connections and the wider fediverse can respond.

Step 8 - The administration panel

Because you registered the first account, you hold the administrator role. Open Admin from the app menu, or browse to /admin/site. The Site page sets your hub name, banner, registration policy and more, and the ADMIN menu gives you Accounts, Channels, Security, Features, Addons, Themes, the queue tools and DB updates.

Step 9 - No known or default credentials

Hubzilla ships an empty database, so there is no default login of any kind: the first person to register becomes the administrator and chooses their own password. The cloudimg image also generates the database password, the site federation salt and the site RSA keypair uniquely on first boot. You can prove the shipped image carries no login with the built in round-trip check, which confirms the per VM database password authenticates over loopback, a wrong password is rejected, and no account pre-exists so registration is the only door:

mariadb --protocol=socket -uroot -N -e "SELECT CONCAT(COUNT(*),' login accounts in the shipped database (no default login)') FROM hubzilla.account"

sudo bash /usr/local/sbin/hubzilla-cred-roundtrip.sh

Step 10 - Verify the version, the poller and the footprint

Confirm the running Hubzilla version, that the background poller runs, and the memory footprint. Hubzilla requires a periodic poller for delivery and maintenance, which the image runs every 10 minutes as hubzilla-cron.timer; you can trigger a run on demand through its service unit:

curl -s http://127.0.0.1/siteinfo/json | tr ',' '\n' | grep -iE '"version"|"platform"' | head -3

sudo systemctl start hubzilla-cron.service && systemctl show hubzilla-cron.service -p Result --value

free -m | awk '/^Mem:/{printf "memory: %s MiB used of %s MiB total (%s MiB available)\n",$3,$2,$7}'

Adding your own domain and TLS

The appliance serves plain HTTP on port 80, and Hubzilla bakes its base URL into the pages and links it serves, so for production you should set your own address. Front Hubzilla with your domain and a TLS certificate, then set App::$config['system']['baseurl'] in /var/www/hubzilla/.htconfig.php to https:// followed by your domain. Once you are on HTTPS, enable the shipped hardening flags in the same file by setting ssl_cookie_protection, transport_security_header and content_security_policy to 1. Hubzilla reads this file on every request, so the new address takes effect immediately.

You can terminate TLS with Azure Application Gateway, an nginx or Caddy reverse proxy, or a managed load balancer with a certificate for your domain.

Security notes

• Hubzilla serves plain HTTP on port 80. For anything beyond a trusted network, put it behind your own TLS terminating reverse proxy or Azure Application Gateway with a certificate for your domain, and enable the HTTPS hardening flags described above.
• The bundled MariaDB listens on 127.0.0.1 only and is never reachable from the network. Administer it through Hubzilla or over SSH.
• The database ships empty and no known or blank credential authenticates. The first account to register becomes the administrator; register it promptly after deploying so nobody else can claim it.
• Keep /root/hubzilla-credentials.txt protected, and restrict inbound 80/tcp and 443/tcp in your NSG to the networks that need the hub.

Support

This image is maintained by cloudimg with 24/7 support. If you need help deploying or operating Hubzilla on Azure, contact us at cloudimg.co.uk.