Deployment guide

GlobaLeaks

Overview

GlobaLeaks is a free and open source whistleblowing platform that news organisations, NGOs, corporates and public bodies use to receive confidential reports. Reporters submit through a web form without an account and receive a 16-digit access code. They use that code to return to their case, read replies and add more information.

The SecureAnyCloud image serves GlobaLeaks 5.0.98 on a hardened Ubuntu 24.04 LTS base, patched at build time. It is installed from the official upstream package repository, so you keep receiving GlobaLeaks security updates. No administrator account ships in the image: you choose your own administrator username and password in the setup wizard the first time you open the platform.

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 the platform a common choice for EU Whistleblowing Directive compliance programmes.

What you get:

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 platform database, receipt salt, node identity and TLS certificate generated for each instance on first boot
A self-signed TLS certificate 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 installed but switched off, so the image is HTTPS only
globaleaks.service as an enabled systemd unit
24/7 SecureAnyCloud support

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 size. Choose a larger size if you expect large attachments or many concurrent reporters.

Configure the network security group (NSG) to allow inbound 22/tcp from your management network, and 443/tcp and 80/tcp for reporters and recipients. Port 80 is needed only for the HTTP entry point and for ACME certificate issuance. You can close it once you run 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 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:globaleaks-ubuntu-24-04:default:latest
az vm create \
  --resource-group <your-rg> \
  --name globaleaks \
  --image sac1647283583153:globaleaks-ubuntu-24-04:default:latest \
  --size Standard_B2s \
  --admin-username azureuser \
  --generate-ssh-keys \
  --public-ip-sku Standard

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 that 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

The output shows both units active, listeners on 8443 and 8080, and the two REDIRECT rules that publish them on 443 and 80.

Step 4 - Read the first-boot info note

On first boot the image runs globaleaks-firstboot.service. It 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.

Read the note and the first-boot log:

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, which upstream generates when it creates a database, was suppressed. This image publishes nothing to the Tor network.

Step 5 - Run the appliance self check

Run the self check that ships with the image. One command confirms the security posture: 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>/. The platform opens its setup wizard. The image ships with a self-signed certificate, so your browser warns you 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 reads incoming reports, and asks you to accept the GlobaLeaks licence.

When the wizard finishes, open Preferences and save your Account Recovery Key. Report content is encrypted to your account, so this key is what lets you regain access if you forget your password.

Step 7 - Open your public reporting homepage

When the wizard is done, https://<your-vm-ip>/ becomes the page your reporters see. It offers a single Submit a report action. It also has a box where someone who has already reported can enter their access code to return to their case.

Step 8 - Submit a test report

Choose Submit a report to open 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 receives a 16-digit access code. This is the only way back into the report, and the platform deliberately cannot recover it, so the reporter must save it.

With that code, the reporter can read replies from your team and add further information. This is what makes two-way anonymous follow-up possible.

Step 9 - Receive reports as a recipient

Sign in at https://<your-vm-ip>/#/login with the recipient account created in the wizard. Under Reports, you see everything sent to your channels: report number, status, submission date, last update and the expiry date set by your retention policy. The list shows metadata only. Report bodies are encrypted and are decrypted only when a recipient opens them.

Open a report to decrypt it. You see the full questionnaire answers and the assigned recipients. You also get 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

The output shows 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. Reporters get transport encryption from the first visit but see a browser warning. Give the VM a DNS name and install a trusted certificate before you publish the address to reporters.

Point your domain at the VM's public IP. 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 this to work.

If your organisation issues its own certificates, use the same page to upload the private key, certificate and chain instead.

Step 12 - Find where your data lives

Everything that belongs to the platform lives under /var/globaleaks. The directory is owned by the unprivileged globaleaks service user with 0700 permissions. It holds the embedded database, the receipt salt, the node identity, the TLS material and every uploaded attachment.

ls -ld /var/globaleaks du -sh /var/globaleaks

All state sits under one directory, so you can back up the platform by snapshotting the OS disk, or by 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 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 this as a deliberate change of posture rather than a default, and review your own legal and operational position before you enable it.

Security notes

The image ships with no administrator, no recipient and no report data. The platform database, receipt salt, node identity and TLS key pair are 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. The unit has a restricted system call filter, an empty capability bounding set, a read-only system tree and an AppArmor profile. GlobaLeaks never runs as root and 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. Publish the platform on its own DNS name with a trusted certificate before you share it with reporters.

Support

SecureAnyCloud provides 24/7 support for this image. For questions about the image or your deployment, contact SecureAnyCloud support. For GlobaLeaks itself, see the upstream documentation at docs.globaleaks.org.

Deploy on Azure

Launch GlobaLeaks 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

Deploy on Azure

Overview

This image runs GlobaLeaks, the open source platform for receiving confidential reports. Newsrooms, NGOs, regulators, universities and companies use it to run a reporting channel that the public, employees or suppliers can use to raise concerns.

A reporter opens the platform in a browser, answers the questions your organisation configured, optionally attaches files, and receives a randomly generated receipt code. That code is the only handle on the report. It lets the reporter come back later to read replies and continue the conversation without ever creating an account or supplying an email address.

On the receiving side, reports land in an inbox only designated recipients can open. GlobaLeaks separates duties across distinct roles so no single person holds every power: administrators configure the platform, recipients read and work reports, custodians can be required to approve access to a reporter's identity, and analysts see statistics without report content.

GlobaLeaks is published under the GNU Affero General Public License version 3 or later, with additional terms permitted by section 7 of that licence which require the project's attribution notices to be preserved. This image ships the official upstream package unmodified, installed from the project's own signed package repository, so those notices appear exactly as the project publishes them. The repository stays configured on the instance, so you keep receiving upstream security updates, and it is also where the corresponding source is available.

The platform is a single service with an embedded database. There is no separate database server, application server or web server to operate.

Read this before you accept real reports

This image gets you a working platform in minutes. It does not, on its own, make your reporting channel safe for a source who is genuinely at risk. Three things are your decision, and two of them should be settled before you publish the address to anyone.

1. The certificate is self signed until you replace it

The instance generates its own TLS certificate at first boot, so HTTPS works immediately and browsers warn on every visit. A self signed certificate encrypts the connection, but it does not let a reporter verify they reached your platform rather than an impostor. Anyone able to intercept traffic could present their own certificate and a reporter has no way to tell the difference.

Point a DNS name at the instance and install a trusted certificate before you publish the address. Step 7 walks through it; the platform has a built in ACME client that can obtain one automatically.

2. This image is not an anonymity network

By default a reporter connects to your instance directly over the internet. Their network operator, your cloud provider and anyone observing the path can see that a connection to your platform happened, even though its contents are encrypted. For many organisations, running an internal integrity or speak up channel, that is perfectly acceptable. For a source whose safety depends on nobody knowing they contacted you, it is not.

GlobaLeaks can also publish a Tor onion service, which is the mechanism that hides a reporter's network address from observers and from the platform itself. This image publishes no onion service unless you switch it on. That is deliberate: upstream GlobaLeaks generates and publishes one automatically the first time it creates its database, and an image that quietly joined the Tor network and published a hidden service from your account before you had even finished the setup wizard would be making that decision for you. The capability is fully intact and one click away. Step 8 covers it.

The platform tells reporters this itself: the landing page carries a banner advising visitors to use Tor Browser.

3. SecureAnyCloud does not certify this image against any compliance regime

Whether a deployment satisfies a legal obligation depends on how you configure, operate, host and document it. That assessment is yours to make. Nothing in this image or this guide is a statement that it is compliant with any standard or directive.

What the platform does not record

GlobaLeaks does not write reporters' IP addresses to its access log. The log's client address field is a literal - unless the request carries an authenticated session whose role is explicitly not whistleblower, so submissions and reporter logins are never attributed to an address. Optional access logging applies only to signed in staff accounts, which is an accountability feature rather than a reporter one. Step 5 shows you how to confirm this on your own instance.

This is also why the image does not put a reverse proxy in front of GlobaLeaks. A proxy would add a second request log, outside the application's control, that does record reporter addresses.

One upstream behaviour worth knowing about

GlobaLeaks always starts a Tor client process, even when no onion service is configured, and that process makes outbound connections to Tor relays. Nothing is published and nothing extra listens, but if you do not want any Tor traffic leaving your account, restrict the instance's outbound rules. The platform serves normally either way; it simply records in its log that Tor is unavailable.

The security model of this image

Two ports carry your traffic and are the only application ports this image expects to be open:

80: the platform over HTTP, which redirects to HTTPS
443: the platform over HTTPS, which is what reporters and staff use

GlobaLeaks runs unprivileged, so it actually binds the high ports 8080 and 8443, and its own startup helper installs kernel redirect rules that put ports 80 and 443 onto them. You do not need to configure that.

Nothing sensitive is baked into the image. There is no administrator account and no platform database at all. The first person to open the platform completes the setup wizard and chooses the administrator credentials and recovery key on that instance. The database, the receipt salt, the node identity and the TLS key pair are all created on your own instance at first boot, so no two customers ever share a secret.

Your passphrase never leaves your browser. GlobaLeaks derives an encryption key from it locally and sends only that derived key, and report content is encrypted to account keys derived the same way. An operator with disk access cannot simply read submissions. That also means a lost passphrase and lost recovery key mean lost reports, so store the recovery key the wizard gives you somewhere safe.

Prerequisites

Before you deploy this image you need:

An Amazon Web Services account where you can launch EC2 instances
IAM permissions to launch instances, create security groups, and subscribe to AWS Marketplace products
An EC2 key pair in the target Region for SSH access to the instance
A VPC and subnet in the target Region, with a security group allowing inbound port 22 from your management network, and ports 80 and 443 from wherever your reporters and staff will reach the platform
A DNS name you can point at the instance, if you intend to accept real reports

m5.large is the recommended instance type and is what this listing is priced against.

Launch the instance

From the AWS Marketplace, subscribe to the product, choose Launch through EC2, and pick your Region, instance type, key pair, subnet and security group.

From the AWS CLI, launch it directly. Replace the AMI id with the one shown on the listing for your Region, and the key pair, subnet and security group with your own:

aws ec2 run-instances \
  --image-id ami-xxxxxxxxxxxxxxxxx \
  --instance-type m5.large \
  --key-name your-key-pair \
  --subnet-id subnet-xxxxxxxx \
  --security-group-ids sg-xxxxxxxx \
  --tag-specifications 'ResourceType=instance,Tags=[{Key=Name,Value=globaleaks}]'

The image carries a dedicated 50 GiB data volume for the platform's own state, attached and mounted automatically. You do not need to add one.

Allow a couple of minutes after the instance reaches the running state. First boot creates the platform database, generates the TLS key pair and writes an instance note before the platform starts.

Connect over SSH

ssh -i your-key.pem ubuntu@<public-ip>

The login banner summarises the state of the instance and points at the instance note.

Confirm the platform is up

Everything in this step is read-only, and every command fails loudly rather than quietly, so you can paste each block as it stands.

systemctl is-active globaleaks.service globaleaks-firstboot.service
systemctl is-enabled globaleaks.service

active active enabled

Check the platform answers its health endpoint. GlobaLeaks terminates HTTPS itself and the kernel redirect does not apply to traffic originating on the instance, so on box checks talk to port 8443 directly:

code=$(curl -ks -o /dev/null -w '%{http_code}' --max-time 10 https://127.0.0.1:8443/api/health)
echo "GlobaLeaks /api/health -> HTTP ${code}" [ "${code}" = "200" ] || {
echo "platform is not healthy"; exit 1; }

GlobaLeaks /api/health -> HTTP 200

Confirm the installed version:

dpkg-query -W -f='${Package} ${Version}\n' globaleaks

globaleaks 5.0.99

Check what is listening, and what is not

A whistleblowing platform should not be exposing anything you did not ask for. Only three sockets on this image accept traffic from outside the instance: SSH, and the platform's two ports behind the kernel redirect.

sudo ss -tlnH | awk '{print $4}' | sort

*:8080 *:8443 0.0.0.0:22 127.0.0.1:8083 127.0.0.53%lo:53 127.0.0.54:53 [::]:22

127.0.0.1:8083 is the platform's own backend for the Tor onion service. It is bound to the loopback address, so it is unreachable from outside the instance whether or not you ever enable that feature. The two entries on port 53 are the operating system's local DNS resolver. Nothing is listening on port 9050: the standalone system Tor service is masked in this image, because GlobaLeaks manages its own Tor process when you enable the onion service and does not use the system one.

The kernel rules that put the standard ports onto the platform:

sudo iptables -t nat -S PREROUTING | grep globaleaks

-A PREROUTING -p tcp -m comment --comment globaleaks -m tcp --dport 80 -j REDIRECT --to-ports 8080 -A PREROUTING -p tcp -m comment --comment globaleaks -m tcp --dport 443 -j REDIRECT --to-ports 8443

Verify the image shipped clean

This is the check worth running before you trust the instance with anything. It asserts, against the live platform, that the image shipped with no completed wizard, no account, no onion service and no reporter address in the access log, and it exits non zero if any of those is untrue.

sudo /usr/local/sbin/globaleaks-selfcheck.sh

OK: health 200, setup wizard pending, 0 user accounts, no onion service, outgoing anonymisation off, system Tor masked, no client IP in the access log

The two facts that matter most, on their own:

users=$(sudo sqlite3 -readonly /var/globaleaks/globaleaks.db 'select count(*) from user;') wiz=$(curl -ks --max-time 10 https://127.0.0.1:8443/api/public | jq -r '.node.wizard_done')
echo "accounts on this platform: ${users}"
echo "setup wizard completed: ${wiz}" [ "${users}" = "0" ] || {
echo "this platform already holds accounts"; exit 1; } [ "${wiz}" = "false" ] || {
echo "the setup wizard has already been completed"; exit 1; }

accounts on this platform: 0 setup wizard completed: false

Administrative endpoints refuse anonymous callers. GlobaLeaks answers with HTTP 412 and the message Not Authenticated, so this block treats anything else as a failure:

code=$(curl -ks -o /dev/null -w '%{http_code}' --max-time 10 https://127.0.0.1:8443/api/admin/users)
echo "unauthenticated GET /api/admin/users -> HTTP ${code}" [ "${code}" = "412" ] || {
echo "an admin endpoint answered an anonymous caller with ${code}"; exit 1; }
echo "refused as expected"

unauthenticated GET /api/admin/users -> HTTP 412 refused as expected

And no reporter address has been recorded. The access log's second field is the client address, and on this platform it is always -:

sudo awk '$2 != "-" {bad++} END {print "lines:", NR+0, "with a client IP recorded:", bad+0; exit (bad+0)>0}' /var/globaleaks/log/access.log

lines: 14 with a client IP recorded: 0

The number of lines will differ on your instance. The number with a client address recorded should always be zero.

The instance note first boot wrote for you carries this instance's URL and the same warnings as this guide. It holds no secret, because there is no secret to hold:

sudo grep '^GLOBALEAKS_URL=' /root/globaleaks-credentials.txt
sudo stat -c '%a %U:%G' /root/globaleaks-credentials.txt

GLOBALEAKS_URL=https://44.204.74.241/ 600 root:root

The URL will show your own instance's address.

Complete the first-run setup wizard

Browse to https://<public-ip>/. Your browser warns about the certificate because the instance generated its own. Accept the warning for now. Step 7 replaces the certificate.

Because no account exists yet, the platform takes you straight to its setup wizard.

Work through the wizard:

Language, then Project name, which is what reporters see at the top of your channel.
Admin account: username, name, email address and password. This is created on your instance at this moment and nowhere else.
Recipient account: the person who will read reports. You can add more later, and you can skip this if your administrator will also be the recipient.
Licence: read and accept the GNU Affero General Public License. Leave Notify developers of software problems unticked unless you actively want to send diagnostics upstream.

The wizard then shows you an account recovery key. Store it somewhere safe and offline. Report content is encrypted to keys derived from account passphrases, so if you lose both the passphrase and the recovery key, the reports cannot be recovered by anyone, including us.

Once the wizard is done, the administration console is at https://<public-ip>/#/login.

Under Users, you can see the role separation the platform is built around and add recipients, custodians and analysts.

Install a trusted certificate for a real domain

Do this before you publish the address.

Create a DNS A record pointing your chosen name at the instance's public address, and confirm it resolves.
Make sure ports 80 and 443 are open inbound in the security group. The ACME challenge needs port 80.
In the console go to Network, then the HTTPS tab, enter your hostname and save.
Follow the ACME option to have the platform request and install a certificate automatically, or upload your own key, certificate and chain if your organisation issues its own.

The platform renews ACME certificates itself. You do not need certbot on this instance, and you should not install a separate web server to terminate TLS: doing so adds a request log outside the application's control.

Verify what is being presented at any point with:

echo | openssl s_client -connect 127.0.0.1:8443 2>/dev/null | openssl x509 -noout -subject -issuer -dates

On a freshly launched instance, before you have configured anything, the subject and issuer are the same, which is exactly what a self signed certificate looks like:

subject=CN = 127.0.0.1 issuer=CN = 127.0.0.1 notBefore=Jul 26 21:53:26 2026 GMT notAfter=Jan 1 00:00:00 3000 GMT

After a trusted certificate is installed, the issuer will be your certificate authority instead.

Decide about anonymous reporting

Go to Network, then the Tor tab. On a fresh instance the Tor Onion Service field is empty, because this image publishes none until you ask:

If your reporters need genuine anonymity, use Regenerate to create and publish an onion service, then publish the .onion address alongside your normal one and tell reporters to reach it with Tor Browser. This is the only configuration in which a reporter's network address is hidden from observers and from your platform.
If your channel is an internal speak up line where the identity of the network a report came from is not the risk you are managing, leaving it off is a reasonable choice. Say so plainly on your reporting page so nobody assumes protection they are not getting.

Anonymize outgoing connections routes the platform's own outbound traffic, such as email notifications, over Tor. Let the platform be reachable without Tor controls, per role, whether people may use the ordinary address at all; you can require staff to use Tor while leaving the clearnet path open for reporters, or the reverse.

Configure your channel and test it end to end

Under Questionnaires and Channels, adapt the default questionnaire to what your organisation actually needs to ask. Under Notifications, point the platform at your SMTP server so recipients are told when a report arrives.

Send yourself a test report before you go live. Open https://<public-ip>/ in a private browser window, choose Submit a report, and fill in the form.

Save the receipt code the platform gives you at the end. Then:

Sign in as the recipient and confirm the report is in the inbox and readable.
Reply to it from the recipient view.
Return to the landing page, enter the receipt code in the Have you already submitted a report? box, and confirm you can read the reply as the reporter would.
Delete the test report when you are done. Deleting reports is a permission an administrator grants to a recipient under Users; a new recipient does not have it by default.

If all four work, your channel is functioning.

The data volume

All platform state, the report database, the receipt salt, the node identity, the TLS key pair, encrypted attachments and the logs, lives on a dedicated EBS volume mounted at /var/globaleaks. It is separate from the operating system disk, so you can resize, snapshot and encrypt the report store on its own.

findmnt -no SOURCE,TARGET,FSTYPE,SIZE /var/globaleaks grep ' /var/globaleaks ' /etc/fstab df -h /var/globaleaks | tail -1

/dev/nvme1n1 /var/globaleaks ext4 48.9G UUID=30488071-4e77-463c-a95e-e03533110cbc /var/globaleaks ext4 defaults,nofail 0 2 /dev/nvme1n1 49G 780K 47G 1% /var/globaleaks

The mount is recorded by filesystem UUID, so it survives reboots and instance replacement. To grow it, modify the EBS volume in the EC2 console, then run sudo resize2fs /dev/nvme1n1 on the instance.

Backups

Everything worth backing up is under /var/globaleaks. An EBS snapshot of that volume is the simplest complete backup, and because the report content is encrypted to account keys, the snapshot is not readable without those credentials.

If you prefer a file level backup, stop the platform first so the database is quiescent:

sudo systemctl stop globaleaks
sudo tar -czf /var/tmp/globaleaks-backup.tar.gz -C /var globaleaks
sudo systemctl start globaleaks

Store backups somewhere at least as protected as the instance itself. Remember that restoring a backup restores the reports inside it.

Updates

The official GlobaLeaks package repository stays configured on this instance, so security updates come from the project itself:

sudo apt-get update
sudo apt-get install --only-upgrade globaleaks
sudo systemctl restart globaleaks

Take a snapshot of the data volume before a major version upgrade. GlobaLeaks migrates its database on first start after an upgrade, and that migration is not reversible.

Troubleshooting

The platform does not answer. Check the service and, if it is not running, read its log:

systemctl is-active globaleaks.service

active

sudo journalctl -u globaleaks.service --no-pager | tail -40 sudo tail -40 /var/globaleaks/log/globaleaks.log

The platform never started after launch and the service reports a condition failure. The platform is deliberately gated behind first boot completing, so it will not start against an unprepared instance. Check first boot ran:

test -f /var/lib/sac/data/globaleaks-firstboot.done && echo "first boot completed" || { echo "first boot has not completed"; exit 1; }

first boot completed

If it has not, inspect sudo journalctl -u globaleaks-firstboot.service.

The browser warns about the certificate. That is expected until you complete Step 7. It is a warning about trust, not a fault.

Reporters say the site is slow to load the first time. The platform starts a Tor client at startup regardless of whether an onion service is configured, and that has no bearing on the ordinary HTTPS path. If your outbound rules block Tor, the platform logs that Tor is unavailable and continues serving normally.

I forgot the administrator passphrase. Use the account recovery key from the wizard. Without either, the encrypted report content cannot be recovered by anyone.

Support

SecureAnyCloud provides 24/7 technical support for this image by email at sales@secureanycloud.com and by live chat, covering deployment, TLS and ACME setup, the optional Tor onion service, SMTP notifications, recipient and role configuration, data volume resizing and hardening.

For questions about GlobaLeaks itself, the project maintains documentation at docs.globaleaks.org and a community forum at forum.globaleaks.org.

Deploy on AWS

Launch GlobaLeaks on AWS with 24/7 support from SecureAnyCloud.

View on Marketplace

Need Help?

Our support team is available 24/7.

sales@secureanycloud.com

Deploy on AWS