OnionShare is a desktop application, and for most of its life it is used as one: a journalist opens it, drags in a file or switches on receive mode, hands a source the onion address over an encrypted channel, and closes the laptop when the transfer is done. The service exists only while the application is running. That ephemerality is a feature — nothing persists, nothing is left listening — and it is exactly what an ad-hoc, post-first-contact transfer wants. But a small number of operators need the opposite: a dropbox that stays reachable so a source can submit at a time of their own choosing, without a prior live handshake. That is a persistent receive-mode instance, and it is what OnionShare’s own documentation has in mind when it recommends “a separate, dedicated computer that is always powered on and connected to the internet.” An offshore VPS is that computer.
Where OnionShare fits among the submission systems — SecureDrop, GlobaLeaks, 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 decided a persistent OnionShare dropbox is the right tool at their scale and now needs the specifics of running it on a VPS. Every command below follows the official CLI and the documentation at docs.onionshare.org; where a flag or behaviour is version-dependent, the honest posture is to check the current documentation rather than to trust a guide that will age.
What OnionShare receive mode is, in honest terms
OnionShare’s receive mode is, in the project’s own words, “an anonymous dropbox” — a Tor onion service that presents a web form where anyone with the address can submit files and short messages directly to the machine running it. The documentation describes it plainly as “a lightweight, simpler, not quite as secure version of SecureDrop,” and that phrasing is worth taking at face value rather than reading past. It is the right tool for an individual journalist or a small collective that wants sources to be able to reach them anonymously without the institutional commitment SecureDrop demands, and it is honest about being less than SecureDrop, not a substitute for it.
By default an OnionShare service is protected by a private key — the source needs both the .onion address and a private key string to reach it, which is Tor’s onion-service client authentication. For a dropbox meant to be reachable by any source given only the address, that second secret is friction, and OnionShare’s --public flag turns the private key off so the address alone grants access. That is a deliberate trade-off: a public dropbox is easier for a source to use and easier for anyone who obtains the address to probe. Which posture is correct depends on how the address is distributed and to whom.
Why persist it on a VPS
The ephemeral desktop model breaks the moment a source cannot coordinate a live window. A persistent instance solves that by keeping the same onion address reachable continuously, and OnionShare supports it directly through a saved persistent session: the --persistent flag writes the session to a file, and — the detail that matters most for the threat model — a copy of the onion service’s secret key is stored in that file on disk. The address survives restarts because its private key lives on the host. That is the property that makes a persistent instance possible, and it is also the property that reshapes the security model, which the caveats section returns to.
A VPS is the natural home for this because the workload is genuinely light. Unlike a full whistleblowing platform, a persistent OnionShare dropbox is a single Python process plus the Tor daemon, holding a form open and writing uploads to a directory — not memory-bound, not CPU-bound, and not storage-bound until submissions accumulate. The offshore part is the point: an operator working in an adversarial jurisdiction can keep the dropbox — and the business records that can be compelled about it — under a different legal regime from the one they physically work in.
Choosing a tier and a jurisdiction
Because the process footprint is so small, the light tiers are the right answer. VPS-1 comfortably runs a persistent receive-mode dropbox alongside a Tor daemon; the constraint is never compute but the disk the received corpus lands on, and the discipline is to move triaged submissions off the host promptly rather than to let them pool. An operator who expects larger document sets, who runs the dropbox alongside a published clearnet surface, or who wants headroom for a working corpus before rotation should provision VPS-2 instead. Neither is a heavyweight tier, and that is appropriate — provisioning a large machine for this workload buys nothing the small tier does not already give.
The jurisdiction the host sits in is part of the dropbox’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 any weakening of it would have to clear. For a dropbox that invites sources to trust it, the decision belongs to the durability question — which jurisdiction’s protection is most likely to still hold across the years the service will run. The threat-model framing for activist archives sets out that long-horizon reasoning in full; a dropbox is the front door to an archive of the most sensitive kind, and the same discipline applies.
Installing and configuring receive mode
OnionShare’s command-line interface is distributed as the onionshare-cli package. It needs tor and Python 3 from the distribution’s package manager first, and then installs from PyPI. Provision a fresh VPS-1 or VPS-2 on a current Debian-based system, bring the base system current, create a non-root account to run the service, and install into that account:
# as a non-root service account on a current Debian/Ubuntu host
sudo apt-get update
sudo apt-get install -y tor python3 python3-pip
pip3 install --user onionshare-cli
onionshare-cli --help # confirm the current flags before relying on them
# a persistent, public receive-mode dropbox that writes uploads to ./received
onionshare-cli \
--receive \
--persistent ~/.config/onionshare/dropbox.session \
--public \
--title "Secure document dropbox" \
--data-dir ~/received
The --receive flag selects dropbox mode; --persistent FILENAME saves the session — including the onion secret key — so the same address returns after a restart; --public turns off the private key so a source needs only the address; --title sets the heading a source sees; and --data-dir is the directory received files are written to. Related flags worth reading in --help: --auto-start-timer and --auto-stop-timer schedule the service to start or stop a set number of seconds out, --disable-text and --disable-files narrow what the form accepts, and --webhook-url can notify the operator when a submission arrives. Because the process must outlive the login session, run it under a supervisor — a systemd user service or unit is the conservative choice — rather than a detached shell, so it restarts cleanly and its logs are managed.
Hardening and disk encryption
The persistent session file is the whole game. It holds the onion service’s secret key, and anyone who reads it can impersonate the dropbox or take it over. That single fact reorders the host-hardening priorities.
Beyond the disk, the discipline is the same as for any sensitive single-purpose host: keep the base system, Python packages, and the Tor daemon patched on a documented cadence against the Tor Project’s advisories; run the service as a non-root account with filesystem access restricted to its own session file and data directory; expose no inbound clearnet ports beyond a restricted SSH; and move triaged submissions off the host so what remains to be compelled shrinks over time. Back up the session file and any retained corpus with an encrypted tool such as restic or borgbackup to a destination in a different civil-liberties jurisdiction from the primary — a dropbox in Iceland backed up to Switzerland, or the reverse — and test a restore, because a backup that has never been restored is an untested assumption.
Threat-model caveats
A persistent OnionShare instance is not the ephemeral tool with a longer uptime; it is a different security posture wearing the same interface. On the desktop, the operator is present, the key is in memory, and the window is short. On a VPS, the operator is absent, the key is at rest on a machine in someone else’s data centre, and the service listens indefinitely — so the VPS and its operator now sit in the trust boundary in a way they never did for a laptop transfer. Disk encryption keeps the host operator to ciphertext at rest, but only while the passphrase stays off the machine it protects.
The tool’s own limits carry over unchanged. OnionShare does not protect against a source who deanonymises themselves, who submits from an identifying network, or who leaves metadata inside the documents they upload. It does not protect against the address being communicated insecurely — the documentation is explicit that it must reach the source over an encrypted channel or in person. It does not protect the recipient endpoint: a malicious upload can carry a tracking payload, so received documents should be opened only from a Tails or Qubes workstation, or disarmed with Dangerzone first, never triaged on a daily-driver laptop “just this once.” And a --public dropbox trades access control for reach; where the address might circulate beyond intended sources, the private-key default is the more conservative posture.
Naming these boundaries is the honest register: a persistent dropbox is a strong tool inside a threat model the operator has actually reasoned through, and a false sense of security outside one. The operator who has not written down that threat model should do so — the threat-model framing is the starting point — before publishing an address that invites sources to trust it.
Closing
A persistent OnionShare receive-mode dropbox on a VPS-1 or VPS-2 in Iceland or Switzerland is a tractable deployment for an individual journalist or small collective who needs sources to submit without a live handshake. The install is a few lines, the persistent session keeps the address stable, and the operational weight is patch discipline, endpoint discipline, and above all disk encryption — because persistence is what puts the onion key on disk. For a heavier submission surface, the GlobaLeaks guide covers the next tier of tool; the survey sets the wider context.
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 dropbox is shaped by the person who runs it.