Pourquoi c'est plus difficile qu'il n'y paraît (et pourquoi la plupart des guides se trompent)
Most "how to host anonymously" guides on the internet stop at "use a VPN and pay in Bitcoin" — and that's the level of guide that gets people deanonymized. Real anonymity is multi-layered, and a single leak at any layer can collapse the whole stack: a registrar that demands a verified email, a deploy tool that sends crash reports keyed to your username, an analytics script that links your visitor traffic to your Google account, a Stripe-pressured CAPTCHA service that fingerprints every visitor.
The failure modes are predictable. The Tor Project's anonymity overview documents the threat model in detail; the EFF's Surveillance Self-Defense guide walks the same ground from a journalist-and-activist angle. This guide assumes you've read those and focuses on the specific operational details of running a website rather than the broader threat-model framework.
Couche 1 — choisir l'hébergeur
The host is the foundation; if the host knows your real identity, no amount of upstream privacy hygiene matters. Three properties are non-negotiable:
No KYC: the host must not require identity verification at signup, must accept crypto, and must not pursue you via your email or phone for verification later. Some hosts say "no KYC" but then send a verification email that fails if it can't reach a working address — pick hosts whose verification is genuinely optional or runs against a randomised email like a SimpleLogin alias.
Outside major intelligence-sharing alliances: avoid hosts incorporated in Five Eyes (US, UK, Canada, Australia, NZ) or Nine Eyes (add Denmark, France, Netherlands, Norway). The 14 Eyes is broader still — see our separate guide on the topic. Iceland, Switzerland and Saint Kitts and Nevis are common picks for hosts that operate outside the broadest intelligence-sharing community.
Documented warrant canary: a regularly-updated public statement that no national security letter, gag order, or sealed warrant has been received. The canary is binary — its absence one week, having been present the week before, is the signal. Hosts that don't publish a canary are not necessarily compromised, but they're harder to reason about.
Privacy Guides' privacy-respecting services maintains a curated list of hosts that meet these criteria. Cryptoservers, Njal.la, FlokiNET, OrangeWebsite and 1984 Hosting are all reasonable picks depending on jurisdiction preference.
Couche 2 — enregistrement du domaine
Domains are the most common deanonymisation vector. Even if the hosting is anonymous, a domain registered with your real WHOIS data, paid for with your credit card, registered through GoDaddy, links the site to you in seconds. The defences are well-known and effective:
Use a registrar that does not require ID. Njal.la is the standard pick — they technically own the domain on your behalf and provide an internal management interface, which sidesteps the WHOIS-publication question entirely. Privacy-respecting alternatives include 1984 Hosting's domain service and a small number of registrars in Iceland and Switzerland.
Pay the registrar in crypto. Same logic as paying the host: any payment that flows through a fiat rail leaves a trail. The good privacy-respecting registrars accept Bitcoin and (often) Monero.
Choose a TLD whose registry operates outside US/EU jurisdiction. .com, .net, .org are all administered through ICANN-accredited registries with US presence; their registries can be compelled to seize domains under US legal process. Country-code TLDs administered outside US/EU (.is for Iceland, .ch for Switzerland) are harder to seize but require some diligence on the country-specific rules.
Lock the domain after registration. Most registrars support a transfer-lock that prevents the domain from being moved without explicit unlock. Set it; an attacker who phishes your registrar credentials should not be able to move the domain to a hostile registrar.
Couche 3 — canal de paiement
Both the host and the registrar must be paid in a way that does not link to your identity. The cleanest path in 2026 is Monero (XMR). Monero's protocol-level privacy obscures sender, receiver and amount on-chain; even a sophisticated chain-analysis adversary cannot reliably deanonymise XMR transactions. The Monero project's technical overview walks through the cryptographic primitives.
If XMR is unavailable, Bitcoin via Lightning is the second-best pick. Lightning payments resolve in seconds, leave minimal on-chain trail (only the channel-funding transaction is on-chain), and can be routed through swap services that decouple the payment from the original UTXO. For pure on-chain Bitcoin, use Wasabi or Sparrow with CoinJoin; the privacy is incomplete but materially better than naive Bitcoin.
The acquisition step matters more than the payment step. If you bought the BTC or XMR through a KYC'd exchange (Coinbase, Kraken, Binance), the exchange's records link your verified identity to the wallet you withdrew to. From that wallet, every subsequent transaction is forensically reachable. Acquire crypto through non-KYC routes: peer-to-peer cash (Bisq, Robosats), mining (slow but realistic on a CPU for XMR), atomic swaps from existing non-KYC holdings, or local-cash trades arranged on community boards.
Couche 4 — accès réseau
Every administrative connection to the server should route through Tor. The default scenario — SSH from your laptop's home internet connection — links your home IP to your server in the host's authentication logs, even if the host doesn't actively analyse those logs. The fix is straightforward.
Configure SSH to use Tor as a SOCKS proxy. The standard pattern is `ProxyCommand /usr/bin/torsocks ssh ...` in `~/.ssh/config`, or directly `ssh -o ProxyCommand="nc -x 127.0.0.1:9050 %h %p" user@host`. Tor adds 100–500 ms of latency but removes the IP correlation entirely.
For host-side admin panels, use Tor Browser exclusively. The browser fingerprint on Tor Browser is uniform across all users; logging into your host's panel from Tor Browser is indistinguishable from any other Tor Browser session.
For DNS, use either the host's resolver (over Tor) or a Tor-friendly DNS service. Avoid DNS-over-HTTPS to a major commercial provider (Cloudflare 1.1.1.1, Google 8.8.8.8) for administrative queries — those are logged and can be correlated.
The Tor Project's official documentation is the canonical reference; Mullvad's no-account VPN is a reasonable supplement if you need consistent IP for some specific purpose, but Tor alone is the standard tool.
Couche 5 — configuration du site
The site itself, once running, can leak identity through its third-party dependencies. The standard culprits:
Google Analytics. Loads from google-analytics.com and cross-links to your Google account if you have one logged in elsewhere. Even "anonymous" GA usage links your site's traffic to a Google ID that may resolve to your real identity. Replace with self-hosted analytics (Plausible, GoatCounter, Umami) or omit analytics entirely.
Cloudflare reverse-proxy with a personal account. Cloudflare's free tier requires a Cloudflare account, and that account's email ties to you. If you use Cloudflare, use a dedicated burner account paid in crypto (some Cloudflare alternatives accept crypto; Cloudflare itself does not).
Third-party fonts loaded from Google Fonts or similar CDN. Each font load fingerprints the visitor. Self-host fonts; the storage cost is trivial.
Commercial CAPTCHA services (reCAPTCHA, hCaptcha). These fingerprint visitors and link them to broader behavioural profiles. If you need anti-bot protection, use a privacy-respecting CAPTCHA (mCaptcha, Anubis) or simple proof-of-work challenges.
Tracking pixels, embedded social-media widgets, third-party comment systems (Disqus). Each one is a separate fingerprinting vector. Self-host comments (Commento, Isso) or omit them.
getmonero.org's merchant guide has a useful checklist for stripping commercial dependencies from a site.
Couche 6 — hygiène de déploiement
Deploying code to the server is the most common late-stage leak. Modern deploy tools phone home extensively, and many of them authenticate against accounts that link to your real identity:
Git push to GitHub from your real account. GitHub knows your real name (most likely), your IP, your commit-author email. Use a dedicated burner GitHub account that has never been logged into from your real IP, or self-host a Git server (Forgejo, Gitea) over Tor.
GitHub Actions. The runner authenticates as your account; the build logs are stored on GitHub's infrastructure under your account name. If you must use Actions, use a separate burner account.
Vercel CLI, Netlify CLI, etc. These authenticate against the platform's account system and send telemetry. Avoid for anonymous workflows.
rsync over SSH (which is itself routed through Tor) is the cleanest deploy path. The deployment command becomes `rsync -avz -e 'ssh -o ProxyCommand="..."' ./build/ user@host:/var/www/`. No third-party telemetry, no platform account, no logs outside your own machine.
Set Git author email to a burner address before any commit you'll push. `git config user.email "[email protected]"` per repository. Default Git client behaviour is to use your system email, which can leak.
Ce contre quoi cette pile ne protège PAS
Operational security failures. If you mention the site by name in a chat that links to your identity, no amount of technical hygiene helps. If you publish writing that has a recognisable stylometric signature linkable to your other writing, an adversary can correlate. If you log into the site's admin panel from Tor and from your home IP just once, the linkage is forever.
Backbone-level traffic analysis. A nation-state adversary with access to internet exchange points can in principle correlate Tor entry and exit nodes through traffic analysis. The Tor Project documents this; for most threat models it's not relevant, but for journalists facing nation-state adversaries it's worth understanding.
Subpoena of your registrar. Even Njal.la can in theory be served with an Icelandic court order. The legal threshold is high (an Icelandic court has to be convinced of a serious matter), but it's not zero. The defence is to compartmentalise — use different registrars and different hosts for different sites — so a single subpoena doesn't expose your whole footprint.
Your own ISP. If you connect to Tor from your home internet, your ISP knows you used Tor (though not what you did with it). For most threat models that's fine; for some it's not. Mullvad VPN over Tor (or Tor over Mullvad) adds another layer at some cost in latency.
Un exemple réaliste de déploiement
Concrete example: Alice wants to publish an investigative blog. She: (1) creates a SimpleLogin alias `[email protected]`; (2) signs up at Cryptoservers using that alias and pays the VPS in XMR acquired via Bisq; (3) registers `aliceblog.is` at Njal.la using the same alias and pays in XMR; (4) sets up SSH on her laptop with a Tor-based ProxyCommand; (5) installs Hugo on the VPS, points the domain via Njal.la's DNS, and pushes content via rsync over Tor; (6) writes posts in a clean text editor without telemetry, commits to a self-hosted Forgejo instance accessed only via Tor.
Total setup time: about 90 minutes. Total monthly cost: roughly $8 hosting + $15 domain (one-time) + minor electricity for Tor traffic. The result is a fully functional blog whose ownership is not technically traceable to Alice without operational-security failures she controls.
