How to Host a .onion Site in 2026: The Hard Way and the One-Flag Way

There are good reasons to put a site on Tor that have nothing to do with the dark web’s reputation. A newsroom that needs a tip line its sources can reach without exposing their location. A blog in a country that blocks it on the open internet. A status page, a documentation site, or an internal tool you want reachable without putting it on a public IP at all. An onion service hides the server’s location from visitors and the visitors’ location from the server, and for censorship resistance and source protection that property is the whole point.

The catch has always been that setting one up is fiddly, and getting it wrong leaks the very thing you were trying to protect. This guide walks the manual way in full, because it is worth understanding, and then shows the shortcut that collapses it into a single option.

The hard way

Here is the real process on a Linux server. None of it is unfamilliar, but every step has a way to go wrong.

Install Tor and a local web server. Your site is served by something ordinary, Nginx or Apache, bound to localhost so it never faces the public internet directly. Tor sits in front of it.

server {
    listen 127.0.0.1:80;
    root /var/www/onion;
    index index.html;
}

Bind to 127.0.0.1, not 0.0.0.0. If the local server is reachable on a public IP as well as through Tor, you have given anyone a way to correlate the two and defeat the anonymity before you started.

Configure the hidden service. You add two directives to your torrc:

HiddenServiceDir /var/lib/tor/onion_service/
HiddenServicePort 80 127.0.0.1:80

Restart Tor. On first start it generates the service, creating the directory you named and, inside it, two things that matter: a hostname file with your new .onion address, and the private key that controls that address.

Get your address.

sudo cat /var/lib/tor/onion_service/hostname

That string ending in .onion is your site. Open it in Tor Browser and you should see your page.

Protect your Private Key at all cost

Now the parts the tutorials gloss over, which are the parts that actually matter:

Guard the private key with your life. The key in that directory is your service’s identity. If it leaks, someone else can stand up a service at your address and impersonate you, and visitors have no way to tell. Back it up encrypted, restrict permissions, and never put it somewhere a backup job will quietly copy to a third party.

Watch for leaks. Anonymity from onion routing is easy to undo by accident. A referrer header that points at a clearnet URL, an analytics script that phones home, a server header that reveals your stack, an email link in the page footer. The transport is anonymous. Your application’s habits are not, and they will give you away if you let them.

Keep it patched and keep it up. Tor and your web server need to stay current, and the service is a single process on a single box. If that box goes down, your onion goes with it. There is no managed failover here unless you build it.

Optionally, add TLS inside Tor and SSH over Tor. Encryption inside the onion is belt and suspenders, and routing SSH through the onion lets you shut administrative access off the clearnet entirely. Both are worth doing and both are more configuration.

This works. People run serious, important services exactly this way. But it is a list of sharp edges, and every one of them is a chance to leak the thing you stood the service up to protect.

The one-flag way

The manual process exists because the platform underneath was never designed for it. When the platform is, the entire list above becomes one option at deploy time.

On Impreza Host, any deployment can publish a Tor v3 onion service alongside its normal address by enabling the onion mirror when you deploy. The platform generates and stores the service keys, binds your app correctly so nothing leaks to a public IP by accident, and gives you back the .onion address. The torrc editing, the localhost binding, the key handling, the restart dance: handled, because the infrastructure was built to do it.

It pairs with the rest of the stack rather than sitting beside it. Deploy an app from the catalog or from your own git repo, flip the onion mirror on, and you have a service reachable both ways. If you read the earlier piece on AI driven deploys, this is the step where “deploy this and give me a .onion” is a single sentence to an agent, because the flag is just another argument the MCP tools can set.

And it inherits the rest of what the platform is. The server was signed up with no KYC and paid for in crypto, so the machine hosting your onion service was never tied to your name in the first place. For a use case where location and identity are the point, that closes a gap the manual method leaves wide open: you can hide the server’s location through Tor all you like, but if you rented that server under your legal name with a card, the anonymity stops at the invoice.

What the flag does not do for you

Worth being straight about the limits, because no platform removes these.

The onion mirror handles the transport and the service setup. It does not audit your application. If your app leaks an analytics beacon, exposes a clearnet link in a referrer, or logs visitor data it should not, that is still yours to fix. Anonymity is a property of the whole stack, and the platform owns the bottom of it, not the top.

It also is not a license to host anything. An onion address is a privacy tool, the same as a lock on a door, and the legitimate uses, source protection, censorship resistance, private infrastructure, are what it is built for. The platform’s posture is privacy for people who have a real reason to want it, not anonymity as cover for abuse.

The short version

Hosting an onion service by hand is a dozen steps and several ways to quietly undo your own anonymity. It is worth learning, and the manual way above is complete enough to do it. But in 2026 the reason most people still treat onion hosting as peculiar is that the tooling never caught up, not that the technology is hard.

When the platform handles the keys, the binding, and the leaks, putting your app on Tor stops being a weekend project and becomes a checkbox. And when that same platform was never tied to your identity to begin with, the onion address finally protects what it was always supposed to.

 

---

Read more at Impreza News

In need of a trustworthy Hosting solution? Take a look at our Tor Hosting and start that one Project today!