Infrastructure that isn’t tied to your name
For a reporter on a sensitive story, an NGO operating in a hostile environment, or a researcher handling risky material, the problem is rarely a shortage of tools — it’s that most tools leave a trail. A hosting account opened with your email and paid with your card is a durable record that ties your identity to whatever runs on that server, and that record can be requested from the host or the payment processor later.
TLDBunker removes that first link. You order with a randomly generated 32-character ID — no name, email or phone — and pay in Monero, so renting the machine creates no card or bank entry pointing back to you. We never collect an identity to begin with, which means there is no account recovery inbox and no billing profile for anyone to subpoena. This is the same anonymous VPS product we sell to everyone; the difference on this page is only in how you might use it.
Being honest about scope matters here more than anywhere. Removing the host relationship closes one identifier. Your device, your network path, the services you log into from the server, and the people you communicate with are all still part of the chain. Read this as one layer of an operational-security posture, not as a solution. If your threat model is serious, get training from people who do this professionally.
A server you actually control
The value of a VPS over a consumer cloud account is control: root on a machine whose provider does not know who you are. A few things people in this position run on one:
- A secure file drop. Reputable, self-hosted tools such as OnionShare let a source send you a file over a Tor onion service without either side revealing an IP address. You host the endpoint; nothing routes through a third-party company’s servers.
- A static site or mirror. A plain HTML site or a mirror of published work, served from infrastructure that isn’t registered to your name, is resilient to pressure applied to a personal account.
- Comms and collaboration tooling. Self-hosted encrypted storage or document tools (for example a hardened Nextcloud or CryptPad instance) keep a team’s working files off consumer platforms — provided you configure and update them properly.
We point to these tools generically because they are well-regarded, not because running them guarantees any outcome. Their security depends on how you deploy them, and none of them make a poorly secured workstation safe.
Reaching the machine over Tor
You can order, pay for and administer the server entirely through our .onion
panel mirror, so managing it doesn’t require leaving Tor. On the server side, a
Tor onion service lets a site or drop be reached without publishing an IP. The
minimal shape looks like this:
# on the VPS (Debian/Ubuntu)
sudo apt update && sudo apt install -y tor
# expose a local service (e.g. a drop listening on 127.0.0.1:8080) as onion
sudo tee -a /etc/tor/torrc >/dev/null <<'EOF'
HiddenServiceDir /var/lib/tor/drop/
HiddenServicePort 80 127.0.0.1:8080
EOF
sudo systemctl restart tor
# your .onion address:
sudo cat /var/lib/tor/drop/hostnameBind the application to 127.0.0.1 so it is reachable only through the onion
service, never on a public port. An onion service reduces metadata exposure; it
does not fix an application that logs too much, leaks in error pages, or is left
unpatched. Those are your responsibility on a server you control.
No-logs and transparency, in writing
Claims are worth nothing here unless they are checkable. Our no-logs policy is versioned in Git, so you can read exactly what we do and don’t retain and see when it last changed. Our transparency report publishes the number of authority requests we have received and how many we were able to act on. If a claim on this page can’t be verified against one of those documents, treat it as marketing and discount it.
We are also a privacy host with a published acceptable-use policy and a working abuse desk. We are explicit about that because it is the honest position: we protect lawful private infrastructure, and we respond to abuse reports on a stated timeline. We do not offer, and cannot promise, immunity from lawful process.
This is one layer
If you take one thing from this page: a server that isn’t linked to your name is useful, but it is a component, not a strategy. Pair it with a threat model, hardened endpoints, careful key management, and — for genuinely high-risk work — guidance from an operational-security professional. We give you the private infrastructure layer and put every privacy claim in writing so you can check it. The rest of the chain is yours to secure.