Allura

Prerequisites

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

Standard_B2ms (2 vCPU / 8 GiB RAM) is the recommended size for typical use. The forge runs comfortably in less, but a real deployment adds hosted repositories, multiple projects, concurrent users and a growing search index.

Configure the network security group (NSG) to allow inbound 22/tcp from your management network and 80/tcp for the forge, plus 443/tcp if you terminate TLS on the VM. Solr, FerretDB and PostgreSQL are never exposed, so ports 8983, 27017 and 5432 stay off the network.

Step 1 - Deploy from the Azure Marketplace

Sign in to the Azure Portal, choose Create a resource, search the Marketplace for Apache Allura 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), HTTP (80) and HTTPS (443).

Select Review + create, then Create.

Step 2 - Deploy from the Azure CLI

# Accept the Marketplace terms once per subscription (required before the first CLI deploy)
az vm image terms accept --urn sac1647283583153:allura-ubuntu-24-04:default:latest
az vm create \
  --resource-group <your-rg> \
  --name allura1 \
  --image sac1647283583153:allura-ubuntu-24-04:default:latest \
  --size Standard_B2ms \
  --admin-username azureuser \
  --generate-ssh-keys \
  --public-ip-sku Standard

Open ports 80 and 443:

az vm open-port --resource-group <your-rg> --name allura1 --port 80,443

Step 3 - Confirm the services are running

SSH in as azureuser and confirm that all six services are active. The forge is a multi-service stack. nginx fronts gunicorn, allura-taskd performs the asynchronous work, and Solr, FerretDB and PostgreSQL back it.

systemctl is-active postgresql ferretdb solr allura-web allura-taskd nginx

Expected output:

active active active active active active

Only the web front end is reachable from the network. Confirm that search, the datastore and PostgreSQL are bound to loopback:

sudo ss -tlnH | grep -E ':(80|8080|8983|27017|5432) ' | awk '{print $4}' | sort -u

Step 4 - Retrieve the per-VM administrator password

Every VM generates a unique administrator password on its first boot and records it in a root-only file. Read it over SSH:

sudo ls -l /root/allura-credentials.txt

The expected output shows a root-owned file with mode 0600:

-rw------- 1 root root 944 /root/allura-credentials.txt

Read the file itself to get the forge URL, the administrator username and its per-VM password:

sudo cat /root/allura-credentials.txt

There is no shipped default login. The administrator password, the session signing key, the PostgreSQL role password and the field-level encryption key are all regenerated on the first boot of every VM, so no two customer VMs share a secret.

Upstream's bootstrap would otherwise create the well-known admin1, test-user and root accounts, all with the password foo. This image is built with that test data disabled, and the absence of those accounts is verified at build time rather than assumed.

Step 5 - Sign in

Browse to http://<vm-ip>/auth/ and sign in as the admin user with the password from the credentials file.

After you sign in, your dashboard lists the projects you administer alongside your tickets, merge requests and recent activity. On a freshly deployed VM the dashboard starts empty. The screenshot below shows it after a couple of projects have been created.

Step 6 - Register your first project

From the dashboard, choose Add Project. Give the project a display name and a short URL name. Project short names are capped at 15 characters and are rejected inline if longer, so pick a concise name.

The background task worker handles registration, so allow a few seconds for the project's tools to finish provisioning. The new project comes with an activity feed, a wiki, a code repository area, discussion forums, a ticket tracker and an admin section.

Step 7 - Use the wiki and the ticket tracker

Open the project's Wiki tab and choose Create Page. Allura's markdown editor gives you formatting controls, a live preview and attachment support.

Saving renders the page and records you as its author, with a full revision history behind the page.

Open the Tickets tab, the project's issue tracker, and create a ticket with a summary and a markdown description. Each ticket carries a milestone, status, owner, labels, voting and a threaded discussion.

Step 8 - Search across the project

allura-taskd indexes content into Apache Solr asynchronously, so content becomes searchable a few seconds after you save it. Use the project's Search box to search tickets, wiki pages, forum posts and commits together.

You can also confirm the search index directly from the shell. The core reports zero initialisation failures and a real document count, and a query returns real indexed content:

curl -s 'http://127.0.0.1:8983/solr/admin/cores?action=STATUS&wt=json' | head -c 200; echo

Step 9 - What is installed

Confirm the shipped component versions, and confirm that no SSPL-licensed MongoDB package is present:

sudo -u postgres psql -tAc 'show server_version' echo "MongoDB packages installed: $(dpkg -l | grep -Eic 'mongodb-org|percona-server-mongodb' || true)"

Expected output, showing PostgreSQL 17 and a count of zero:

17.10 (Ubuntu 17.10-1.pgdg24.04+1) MongoDB packages installed: 0

Security model

• No default login. No credential is baked into the image. On the first boot of every VM, allura-firstboot.service generates a fresh administrator password, a fresh PostgreSQL role password, a fresh session signing key and a fresh field-level encryption key, and records the administrator credential in /root/allura-credentials.txt (mode 0600, root only).
• Per-VM encryption keys. Allura 1.19.1 encrypts sensitive fields client-side before they reach the datastore, using a local KMS key. That key is regenerated per VM, so one customer's key can never decrypt another customer's data. Upstream ships a default key that this image always replaces.
• No test accounts. The upstream bootstrap creates admin1, test-user and root with the password foo when test data is enabled. This image is built with test data disabled and ships with those accounts absent.
• Loopback-only backends. Apache Solr (8983), FerretDB (27017) and PostgreSQL (5432) all bind to 127.0.0.1 only. Keep those ports closed in your NSG.
• Plain HTTP by default. The forge ships on plain HTTP on port 80 for first contact. Put it behind TLS before you expose it to any untrusted network, and review the new-user registration policy before you open the forge to others.
• Fully patched base. The Ubuntu 24.04 LTS base is fully patched at build time, and unattended security upgrades stay enabled on the running VM.

Where your data lives

Allura's documents live in FerretDB, which stores them in PostgreSQL on the OS disk. Project repositories and uploaded files live under /var/lib/allura, the application itself under /opt/allura, and its Python environment under /opt/allura-venv. The search index lives under Solr's data directory and is rebuilt from the datastore if it is lost.

sudo du -sh /opt/allura /opt/allura-venv /var/lib/allura

Enable HTTPS (optional)

For production, front the appliance with your own domain and a TLS certificate. Point a DNS record at the VM's public IP, then install a certificate with Certbot:

sudo apt-get update && sudo apt-get install -y certbot python3-certbot-nginx
sudo certbot --nginx -d your-domain.example.com

After you change the host name that customers use, update the forge's own base URL so that Allura's redirects and notification links point at the right address. Set base_url and domain in /opt/allura/Allura/production.ini, then restart the application:

sudo systemctl restart allura-web allura-taskd

Troubleshooting

A ticket or wiki page saved but does not appear in search. Indexing is asynchronous. Confirm the task worker is running with systemctl is-active allura-taskd, then re-run the search after a few seconds.

A project appears not to have been created. Project registration is also handed to the task worker. Check journalctl -u allura-taskd -n 50 for the registration task, and confirm the short name was 15 characters or fewer.

The forge redirects to an unexpected address. Allura issues absolute redirects built from the base_url set in /opt/allura/Allura/production.ini. If you reach the VM by a different name or address than the one recorded there, update base_url and domain and restart allura-web.

Support

Every SecureAnyCloud image includes 24/7 support. For questions about deploying or operating Apache Allura on Azure, contact the SecureAnyCloud team.

Deploy on Azure

Launch Apache Allura 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