GlobaLeaks is the whistleblowing platform most small organisations reach for when they have decided an anonymous-submission surface belongs in their infrastructure but do not have the institutional capacity that a SecureDrop deployment demands. It is open-source, written in Python, maintained by the Hermes Center for Transparency and Digital Human Rights, and it installs cleanly on a single Debian or Ubuntu host. The broader question of where GlobaLeaks fits among the submission systems — SecureDrop, OnionShare, the lightweight tip-line family — is treated in the leak-aggregator survey; this article does not re-survey that ground. It is the deep, single-topic how-to for the operator who has already decided GlobaLeaks is the right tool and now needs the specifics of running it on an offshore VPS.
The steps below are the generic shape of a deployment. The canonical reference for every application-layer detail is the official documentation at docs.globaleaks.org; where this guide states a command or a system requirement, it follows the official install path rather than inventing one. Where a claim is version-dependent, the honest posture is to check the current documentation rather than to trust a guide that will age.
What GlobaLeaks is, in honest terms
GlobaLeaks packages a submission portal and a web-based recipient interface into a single application that runs on one host. A source reaches the portal — by default over Tor, as a version-3 onion service — fills in a submission, and optionally attaches files; a recipient logs into the same application through a browser to triage what arrived. There is no separate monitor server and no air-gapped viewing station in the default architecture, which is precisely the trade-off that makes GlobaLeaks lighter to operate than SecureDrop and also the trade-off that shifts more of the processing-side discipline onto the recipient.
The platform bundles Tor and configures the onion service itself during setup, and it can additionally serve a clearnet hostname over HTTPS with an automatically-enrolled Let’s Encrypt certificate. This is the deployment shape that fits an offshore VPS well: the whole application, the onion service, and the optional clearnet surface all live on one machine that the operator controls.
System requirements and choosing a tier
The official minimum hardware, per the GlobaLeaks requirements documentation, is a dual-core 2.0 GHz 64-bit CPU, 1 GB of RAM, 20 GB of disk, and a 10 Mbit/s shared network connection. Those are baseline figures — GlobaLeaks will run on less — and they are the wrong figures to provision against for anything but an evaluation instance. A production submission portal accumulates attachments, holds them encrypted at rest, retains an audit log, and has to stay responsive over Tor while a recipient downloads a multi-gigabyte submission. The sober production floor is more headroom than the bare minimum.
For most deployments, VPS-2 — 2 vCPU, 4 GB of ECC RAM, 60 GB of NVMe storage — is the right starting tier. It clears the CPU and memory minimums with room for the Tor daemon, the application, and the SQLite/attachment working set, and its storage comfortably holds a working corpus of submissions before rotation. An organisation that expects a higher submission volume, larger file attachments, or a longer retention window before triaged material is moved off the host should provision VPS-4 — 4 vCPU, 8 GB of RAM, 120 GB of NVMe — instead. The storage figure is the constraint that most often forces an unplanned migration: attachments dominate the disk, and the discipline is to provision the tier with headroom rather than to plan a move every few months.
GlobaLeaks is not a bandwidth-heavy application in steady state, but attachment transfer over Tor is slower than clearnet transfer, and a portal that receives large document sets will move meaningful transfer volume. VPS-2’s 3 TB monthly allocation fits a low-to-moderate portal; VPS-4’s 6 TB is the safer floor where the portal receives large submissions regularly.
Choosing a jurisdiction
The jurisdiction the host sits in is part of the submission portal’s threat model, not an afterthought to it. The two PressExile jurisdictions are argued at length in their own dossiers: the Iceland dossier sets out the Icelandic Modern Media Initiative and the cross-party durability of its source-protection posture; the Switzerland dossier sets out the constitutional telecommunications-secrecy provision and the referendum threshold that any weakening of it would have to clear.
For a whistleblowing portal, the decision belongs to the durability question rather than the marketing one — which jurisdiction’s protection is most likely to still hold across the years the portal will operate. The threat-model framing for activist archives sets out that long-horizon reasoning in full; a submission portal is an archive of the most sensitive kind, and the same discipline applies. Where the operating organisation is itself in an adversarial jurisdiction, the value of hosting the portal offshore is that the business records that can be compelled about it sit under a different legal regime from the one the organisation’s staff physically work in.
Provisioning the host
Provision a fresh VPS-2 or VPS-4 with a current Debian-based operating system. GlobaLeaks is developed and tested specifically for Debian-based systems; the recommended platforms in the current documentation are recent Debian and Ubuntu LTS releases, with support extending back across the supported Debian and Ubuntu LTS lifecycles. Provision the disk with full-disk encryption at the LUKS layer, with a passphrase the operator holds and the hosting operator does not — the submission corpus is exactly the data that must not be readable from a disk image at rest. Enter the passphrase at boot through the out-of-band console, or configure dropbear-initramfs for unattended remote unlock if the threat model tolerates it.
Before installing anything, bring the base system current, create a non-root administrative account with sudo, and configure the firewall to expose only what the deployment needs. A Tor-only portal needs no inbound clearnet ports beyond SSH (ideally itself restricted or moved behind a bastion); a portal that also serves a clearnet hostname needs 80 and 443 open for the Let’s Encrypt challenge and HTTPS.
Installing GlobaLeaks
GlobaLeaks publishes a signed APT repository at deb.globaleaks.org and an official install script. The conservative way to run it is to download it, read it, and then execute it — rather than piping it straight from the network into a shell:
sudo apt-get update
sudo apt-get install -y curl gnupg net-tools
curl -fsSL https://deb.globaleaks.org/install-globaleaks.sh -o install-globaleaks.sh
# read the script before running it
less install-globaleaks.sh
chmod +x install-globaleaks.sh
sudo ./install-globaleaks.sh
The script adds the GlobaLeaks PGP key to the APT trust store, configures the deb.globaleaks.org repository for the host’s distribution codename, installs the platform’s dependencies, and installs GlobaLeaks itself from the signed repository. It accepts flags including -y to assume yes to prompts, -n to disable autostart, and -v to pin a specific version. Because the platform is installed from a signed APT repository, subsequent updates arrive through the ordinary package-management channel — which is the property that keeps a long-lived portal patchable without a bespoke upgrade dance. Confirm the exact current flags and codename support against the installation documentation before running, since the supported-distribution list moves with each release.
The setup wizard, the onion service, and HTTPS
Once the package is installed, the platform is configured through a first-run web wizard rather than through config files. GlobaLeaks generates a version-3 onion address for the portal during this process; that onion address is the source-facing front door, and sources should be directed to reach it with the Tor Browser. The wizard also offers to enable a clearnet hostname with an automatically-issued Let’s Encrypt certificate — it asks for the public hostname, provisions the certificate, and this step can be skipped if the deployment is Tor-only.
The decision of whether to expose a clearnet surface at all is a threat-model decision, not a convenience one. A Tor-only portal has no clearnet attack surface and no clearnet metadata trail, at the cost of requiring sources to use Tor Browser. A dual-surface portal is easier for sources to find and reach, at the cost of a clearnet presence that can be probed, blocked, or correlated. Many organisations run both — a discoverable clearnet landing page that explains the process and links onward to the onion address for the actual submission — and that is a defensible middle posture provided the clearnet surface never becomes the submission channel itself.
Hardening
The application ships with a hardened default posture — the onion service, the encrypted submission storage, and a TLS configuration tuned to a high grade for the clearnet surface — but the operator still owns the host underneath it. The host-level discipline is the same as for any sensitive single-purpose server: keep the base system and the GlobaLeaks package current on a documented cadence, run the Tor daemon patched against the Tor Project’s advisories, restrict SSH, and keep the LUKS passphrase off the host.
Configure the platform’s data-retention window deliberately: the submissions that no longer need to live on the portal are the submissions that can no longer be compelled from it. Back up the host with an encrypted tool such as restic or borgbackup, pushing to a destination in a different civil-liberties jurisdiction from the primary — a portal in Iceland backed up to Switzerland, or the reverse — so that a legal action against one jurisdiction does not reach both the primary and its backup. Exercise a restore at least quarterly; a backup that has never been restored is an untested assumption.
What GlobaLeaks does and does not protect against
GlobaLeaks protects the source’s network identity by operating the submission portal as a Tor onion service, and it protects the submission contents at rest through the platform’s encryption. It does not protect against a source who deanonymises themselves — who submits from a work network, who leaves identifying metadata inside the documents they upload, or who describes facts only they could know. It does not protect against a compromised recipient endpoint, which is why the recipient-side discipline above is not optional. It does not protect against a host the operator has failed to patch, a LUKS passphrase stored on the same machine it protects, or a clearnet surface that has quietly become the real submission channel.
Naming these boundaries is the honest register: the platform is a strong tool inside a threat model that the operating organisation has actually reasoned through, and it is a false sense of security outside one. The organisation that has not written down its threat model should do that work — the threat-model framing is the starting point — before it publishes a portal that invites sources to trust it.
Closing
A GlobaLeaks portal on a VPS-2 or VPS-4 in Iceland or Switzerland is a tractable deployment for an organisation with modest operational capacity and a real reason to receive anonymous submissions. The install path is short, the onion service is configured for you, and the ongoing work is patch discipline, recipient-side discipline, and backup discipline rather than heroics. The parts that matter most are the parts the software cannot do for you — the jurisdiction choice, the retention policy, the threat model the portal is meant to serve.
Payment in Monero, Lightning, on-chain Bitcoin, or cash by post. The editorial address is the right place to start a conversation about a specific deployment; the runbook above is the generic shape, and every actual portal is shaped by the organisation that runs it.