Hubzilla

Prerequisites

You need an active Azure subscription, an SSH key pair, and a VNet with a subnet in the target region.

Standard_B2s (2 vCPU / 4 GiB RAM) is a sensible starting point. Size up for larger or busier hubs.

For NSG inbound rules, allow 22/tcp from your management network. Allow 80/tcp for the hub, and 443/tcp once you add TLS. 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 SecureAnyCloud, and select Create.

On the Basics tab, 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 click Review + create, followed by 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 that Apache, MariaDB, the first boot service and the poller timer are all active. 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. It also writes the hub URL, the registration URL and the administrator email to a root-only file. Read the file with sudo:

sudo cat /root/hubzilla-credentials.txt

The database ships empty, so there is no preset login. The file records the email that the first registrant should use to become the administrator.

On the VM 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 the public IP address of your VM, 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, first edit App::$config['system']['admin_email'] in /var/www/hubzilla/.htconfig.php. Then register with that email.

Step 6 - Open your channel home

After you register, you are signed in and your first channel is created. The channel home is the stream of your hub. It has a Start a conversation box to publish to your channel, and a New Member Links panel that guides 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. Your connections and the wider fediverse can then respond.

Step 8 - Open 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. The ADMIN menu gives you Accounts, Channels, Security, Features, Addons, Themes, the queue tools and DB updates.

Step 9 - Verify there are 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 SecureAnyCloud image also generates the database password, the site federation salt and the site RSA keypair uniquely on first boot.

You can prove that the shipped image carries no login with the built-in round-trip check. It confirms that the per-VM database password authenticates over loopback, that a wrong password is rejected, and that no account pre-exists, so registration is the only door:

sudo 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. The image runs it every 10 minutes as hubzilla-cron.timer, and 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. 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. Set 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, so 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

SecureAnyCloud maintains this image and provides 24/7 support. If you need help deploying or operating Hubzilla on Azure, contact us at secureanycloud.com.

Deploy on Azure

Launch Hubzilla on Ubuntu 24.04 LTS on Azure with 24/7 support from SecureAnyCloud.

View this image

Need Help?

Our support team is available 24/7.

sales@secureanycloud.com