GlobaLeaks on Ubuntu 24.04 on Azure User Guide
Overview
GlobaLeaks is a free and open source whistleblowing platform used by news organisations, NGOs, corporates and public bodies to receive confidential reports. Reporters submit through a web form without needing an account, and are given a 16 digit access code they can use to return to their case, read replies and add more information. Reports are encrypted and delivered to named recipients, so only the people you designate can read them. Role separation between administrator, recipient, custodian and analyst, configurable questionnaires and reporting channels, file attachments, per report retention and a full audit log make it a common choice for EU Whistleblowing Directive compliance programmes.
The cloudimg image serves GlobaLeaks 5.0.98 on a hardened, fully patched Ubuntu 24.04 LTS base, installed from the official upstream package repository so you keep receiving GlobaLeaks security updates. It is secure by default: no administrator account ships in the image, so the very first time you open the platform you complete the setup wizard and choose your own administrator username and password. Each instance generates its own platform database, receipt salt, node identity and TLS certificate on first boot. Backed by 24/7 cloudimg support.
What is included:
- GlobaLeaks 5.0.98, a single Python service managed by systemd
- HTTPS on port 443 and HTTP on port 80, served directly by the platform
- No default administrator: you create yours in the first run setup wizard
- An embedded database, so there is no separate database server to run
- A self signed TLS certificate generated per instance, replaceable with your own
- Automatic certificate issuance and renewal through ACME when you add a domain
- Encrypted report delivery to named recipients, with per report access codes
- Configurable questionnaires, reporting channels and retention policies
- The Tor onion service feature present but switched off, so the image is HTTPS only
globaleaks.serviceas an enabled systemd unit- 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 if you expect large attachments or many concurrent reporters. NSG inbound: allow 22/tcp from your management network, and 443/tcp plus 80/tcp for reporters and recipients. Port 80 is only needed for the HTTP entry point and for ACME certificate issuance; you can close it once you are running on your own certificate.
Step 1 - Deploy from the Azure Marketplace
Sign in to the Azure Portal, choose Create a resource, search the Marketplace for GlobaLeaks 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), HTTP (80) and HTTPS (443). Then Review + create and Create.
Step 2 - Deploy from the Azure CLI
az vm create \
--resource-group <your-rg> \
--name globaleaks \
--image <marketplace-image-urn> \
--size Standard_B2s \
--admin-username azureuser \
--generate-ssh-keys \
--public-ip-sku Standard
Then open the reporting ports:
az vm open-port --resource-group <your-rg> --name globaleaks --port 443 --priority 900
az vm open-port --resource-group <your-rg> --name globaleaks --port 80 --priority 910
Step 3 - Confirm the service is running
SSH in as azureuser and confirm GlobaLeaks is active. The platform runs as an unprivileged service user and binds the high ports 8080 and 8443; the kernel redirects the standard ports 80 and 443 onto them, so reporters simply visit https://<your-vm-ip>/.
systemctl is-active globaleaks.service globaleaks-firstboot.service
ss -tln | grep -E ':8080 |:8443 |:8083 '
iptables -t nat -S PREROUTING | grep REDIRECT
You should see both units active, listeners on 8443 and 8080, and the two REDIRECT rules that publish them on 443 and 80.
Step 4 - The first boot info note
On first boot the image runs globaleaks-firstboot.service, which prepares this instance's own platform database, resolves the address reporters will use, and writes a short info note. The note contains no password, because the image ships without any account at all.
grep -v '^#' /root/globaleaks-credentials.txt | grep -v '^$'
journalctl -u globaleaks-firstboot.service --no-pager | sed -n 's/.*globaleaks-firstboot: //p' | tail -6
The first boot log also records that the Tor onion service upstream generates when it creates a database was suppressed, so this image publishes nothing to the Tor network.
Step 5 - Run the appliance self check
The image ships a self check that proves the shipped security posture in one command: the platform answers over HTTPS, the setup wizard is still pending, the database holds zero accounts, no onion service is configured, and the standalone system Tor daemon is masked.
/usr/local/sbin/globaleaks-selfcheck.sh
Step 6 - Complete the first run setup wizard
Browse to https://<your-vm-ip>/ and the platform opens its setup wizard. Because the image ships with a self signed certificate your browser will warn on this first visit; that is expected, and Step 11 shows how to install a trusted certificate.
The wizard asks for your project name, then for the administrator account. This is where the administrator is created: you choose the username and the password. No default credential exists in the image, so nothing is inherited from the build. The wizard then creates your first recipient, the person who will actually read incoming reports, and asks you to accept the GlobaLeaks licence.
After finishing, open Preferences and save your Account Recovery Key. Because report content is encrypted to your account, that key is what lets you regain access if you forget your password.
Step 7 - Your public reporting homepage
Once the wizard is done, https://<your-vm-ip>/ becomes the page your reporters see. It offers a single Submit a report action, and a box where someone who already reported can enter their access code to return to their case.
Step 8 - How a report is submitted
Choosing Submit a report opens the questionnaire. The default questionnaire asks the reporter to summarise and describe the facts, where and when they happened, how the reporter is involved, whether they hold evidence, whether they have reported elsewhere, and what outcome they want. You can change every one of these questions later under Questionnaires.
On submission the reporter is given a 16 digit access code. This is the only way back into their report, and the platform deliberately cannot recover it, so the reporter must save it. With that code they can read replies from your team and add further information, which is what makes two way anonymous follow up possible.
Step 9 - Receiving reports as a recipient
Recipients sign in at https://<your-vm-ip>/#/login with the account created in the wizard. Under Reports they see everything sent to their channels: report number, status, submission date, last update and the expiry date set by your retention policy. The list shows metadata only, because report bodies are encrypted and are decrypted only when a recipient opens them.
Opening the report decrypts it and shows the full questionnaire answers, the assigned recipients, and the controls to reply to the reporter, attach files, apply labels, change the status and export the case.
Step 10 - Verify the stack
dpkg-query -W -f='globaleaks ${Version}\n' globaleaks
systemctl is-enabled globaleaks.service globaleaks-firstboot.service
curl -ks -o /dev/null -w 'https://127.0.0.1:8443/api/health HTTP %{http_code}\n' https://127.0.0.1:8443/api/health
swapon --show | wc -l
Version 5.0.98, both units enabled at boot, the health endpoint returning 200, and zero swap devices, which is what Azure image certification requires.
Step 11 - Install a trusted TLS certificate
The image serves HTTPS immediately using a self signed certificate generated on your VM at first boot, so reporters get transport encryption from the very first visit but will see a browser warning. Before you publish the address to reporters, give the VM a DNS name and install a real certificate.
Point your domain at the VM's public IP, then sign in as the administrator and open Administration then Network then HTTPS. Enter the hostname and let GlobaLeaks request a certificate automatically through Let's Encrypt, which also renews it for you; port 80 must be reachable for that to work. If your organisation issues its own certificates, use the same page to upload the private key, certificate and chain instead.
Step 12 - Where your data lives
Everything belonging to the platform lives under /var/globaleaks, owned by the unprivileged globaleaks service user with 0700 permissions: the embedded database, the receipt salt, the node identity, the TLS material and every uploaded attachment.
ls -ld /var/globaleaks
du -sh /var/globaleaks
Because all state is under one directory, backing the platform up is a matter of snapshotting the OS disk, or stopping the service and archiving that path. GlobaLeaks also ships gl-admin backup and gl-admin restore for a consistent application level backup.
Tor onion service
GlobaLeaks can also publish a Tor onion service so reporters can reach the platform without revealing their network location. This image deliberately ships with that feature switched off: no onion service is created, no onion key is stored, and the standalone system Tor daemon is masked, so the appliance is HTTPS only out of the box.
The capability is still installed. If your threat model calls for it, an administrator can generate an onion address from Administration then Network then Tor, and unmask the system Tor daemon. Treat that as a deliberate change of posture rather than a default, and review your own legal and operational position before enabling it.
Security notes
The image ships with no administrator, no recipient and no report data. The platform database, receipt salt, node identity and TLS keypair are all generated on your VM at first boot, so no two instances share cryptographic material and nothing from the build is inherited.
GlobaLeaks runs as an unprivileged service user under a hardened systemd unit with a restricted system call filter, an empty capability bounding set, a read only system tree and an AppArmor profile. It never runs as root, and it never binds a privileged port directly.
Restrict 22/tcp to your management network. Report content is encrypted to recipient accounts, so make sure every administrator and recipient stores their Account Recovery Key somewhere safe: without it, a forgotten password means unrecoverable reports. Review the retention period under Case management so reports expire on a schedule that matches your policy, and prefer publishing the platform on its own DNS name with a trusted certificate before sharing it with reporters.
Support
cloudimg provides 24/7 support for this image. For GlobaLeaks itself, upstream documentation is at docs.globaleaks.org. For image or deployment questions, contact cloudimg support.