Host a Tor Onion Service

Ever wanted to host a website that can’t easily be traced back to you? Tor, the anonymizing network, supports a feature called an onion service — essentially, a service (like a web server) that’s only accessible from within the Tor network. The identities/location of both the server operator and the visitors are reasonably well protected.

It’s a fun little project, and in today’s political climate, who knows — it might come in handy someday.

Overview

We’re going to deploy a hidden web server using Docker. Our setup includes two containers:

• web – a lightweight NGINX server to host a static website
• tor – a container running the Tor daemon, configured to expose a hidden service

These containers share a private Docker network, so the only way to reach the web server is through the Tor network.

View this entire project here.

Why NGINX?

NGINX has a few key advantages:

• Minimal resource usage
• Excellent security record
• No outgoing connections or built-in telemetry

This means we’re less likely to leak metadata or create unwanted traffic patterns that could compromise privacy.

Folder Structure

We’ll create a directory (e.g. /docker/mysite) with the following structure:

mysite/
├── data/                 # Runtime state for Tor
├── docker-compose.yml    # Docker Compose config
├── nginx.conf            # NGINX config
├── site/                 # Your website content
│   └── index.html
└── tor/                  # Tor container config
    ├── Dockerfile
    └── torrc

Tor Dockerfile (tor/Dockerfile)

We’ll build our own Docker image instead of using a random one from Docker Hub. This ensures we use a current, official build of Tor in a minimal container:

FROM debian:12-slim

RUN apt-get update && apt-get install -y --no-install-recommends gnupg wget ca-certificates

RUN wget -qO- https://deb.torproject.org/torproject.org/A3C4F0F979CAA22CDBA8F512EE8CBC9E886DDD89.asc \
     | gpg --dearmor -o /usr/share/keyrings/tor-archive-keyring.gpg

RUN echo \
  "deb [signed-by=/usr/share/keyrings/tor-archive-keyring.gpg] \
  https://deb.torproject.org/torproject.org bookworm main" \
  > /etc/apt/sources.list.d/tor.list

RUN apt-get update \
 && apt-get install -y --no-install-recommends tor \
 && rm -rf /var/lib/apt/lists/*

USER debian-tor                      
COPY torrc /etc/tor/torrc
VOLUME ["/var/lib/tor"]
CMD ["tor", "-f", "/etc/tor/torrc"]

Tor Config (tor/torrc)

This config sets up the hidden service directory and maps port 80 on the hidden service to our internal web server:

Log notice stdout

HiddenServiceDir /var/lib/tor/hs_site
HiddenServiceVersion 3
HiddenServicePort 80 web:80

SocksPort 0
ClientOnly 1
ExitRelay 0

Docker Compose (docker-compose.yml)

Here’s the full docker-compose.yml file to wire it all together:

services:
  web:
    image: nginx:alpine
    read_only: true
    volumes:
      - ./site:/usr/share/nginx/html:ro
      - ./nginx.conf:/etc/nginx/nginx.conf:ro   
    tmpfs:
      - /var/cache/nginx
      - /var/cache/nginx/client_temp
      - /var/cache/nginx/proxy_temp
      - /var/cache/nginx/fastcgi_temp
      - /var/cache/nginx/uwsgi_temp
      - /var/cache/nginx/scgi_temp
      - /tmp    
    user: ${NGINX_UID}:${NGINX_GID}
    security_opt: [ no-new-privileges:true ]
    networks: [ hidden ]
    restart: unless-stopped

  tor:
    build: ./tor
    volumes:
      - ./data/tor:/var/lib/tor
    read_only: true
    cap_drop: [ ALL ]
    security_opt: [ no-new-privileges:true ]
    networks: [ hidden, tor_out ]
    depends_on: [ web ]
    healthcheck:
      test: ["CMD-SHELL", "tor --verify-config -f /etc/tor/torrc"]
      interval: 30s
      timeout: 10s
      retries: 3
    restart: unless-stopped

networks:
  hidden:
    internal: true              # private LAN – no Internet
  tor_out:
    driver: bridge              # only Tor joins – outbound TCP allowed

Environment Variables (.env)

Create a .env file with the UID/GID NGINX will run as:

NGINX_UID=101
NGINX_GID=101

Sample Web Page

Create a basic site and adjust permissions so that only our NGINX process can access it (making it harder for other non-root processes on the same box from discovering the content):

mkdir -p site
echo "Hello World!" > site/index.html
. .env && chown -R $NGINX_UID:$NGINX_GID site

Initialize Tor Data Directory

Tor (under Debian) runs as user 100 by default, so we need to create a directory for Tor to store its state that can be R/W by that user.

mkdir -p data/tor
chown 100:100 data/tor

Run It

docker compose up -d

Once it starts, grab your onion address:

cat data/tor/hs_site/hostname

You should see something like:

zwh3yrsq7gqpgx6qj6z3or36dojxj4mvlaefoqg5vljtrlruqk5sz2qd.onion

Visit it using the Tor browser!

And clicking the path icon shows our connectivity to our site bouncing through the Tor network.

Updating Content Remotely

So your onion site is now live in its secret bunker, but how do you update the files without blowing your cover? A direct SSH/SFTP connection from your home IP would leave footprints, and poking inbound holes in firewalls or VPNs defeats the point of “hidden.”

Solution: spin up a second onion service dedicated to SFTP. By giving it its own .onion address (and keeping that URL to yourself), you get a Tor-only file‐transfer tunnel that never touches the public internet—and visitors to the web address won’t even know the SFTP endpoint exists.

Why a separate service?

• Compartmentalization: If attackers discover your public site’s onion URL, they still have no path to your SFTP host.
• Access control: You can lock the SFTP service with strong Tor authentication (v3 client keys) or one-off SSH keys without affecting the web front-end.

In short, treat content management as its own walled-off workflow: same anonymity guarantees and zero IP exposure.

First, let's add a new component to our docker-compose.yml file for SFTPGo and add it as a dependency to our tor container.

  sftp:
    image: drakkan/sftpgo:latest             
    environment:
      - SFTPGO_HTTPD__ENABLED=true
      - SFTPGO_FTPD__ENABLED=false
      - SFTPGO_WEBDAVD__ENABLED=false

      - SFTPGO_DATA_PROVIDER__CREATE_DEFAULT_ADMIN=true
      - SFTPGO_DEFAULT_ADMIN_USERNAME=admin
      - SFTPGO_DEFAULT_ADMIN_PASSWORD=${ADMIN_PASSWORD}

      - SFTPGO_AUTH__PASSWORD_LOGIN_DISABLED=true
    volumes:
      - ./site:/data/site:rw                 
      - ./data/sftp:/var/lib/sftpgo          
    user: ${SFTP_UID}:${SFTP_UID}
    security_opt: [ no-new-privileges:true ]
    networks: [ hidden ]
    restart: unless-stopped

  tor:
    # .....
    depends_on: [ web, sftp ]

Next, let's add some new variables to our .env file:

NGINX_UID=101
NGINX_GID=101

# can finess permissions further to ensure NGINX can read 
# content but not write it.
SFTP_UID=101
SFTP_GID=101

# Admin account for setting up SFTP users on SFTPGo
ADMIN_PASSWORD=changeme 

And finally, update tor/torrc and add another onion service for SFTPGo (exposing SSH and HTTP).

Log notice stdout

HiddenServiceDir /var/lib/tor/hs_site
HiddenServiceVersion 3
HiddenServicePort 80 web:80

HiddenServiceDir /var/lib/tor/hs_sftp
HiddenServiceVersion 3
HiddenServicePort 22 sftp:2022 
HiddenServicePort 80 sftp:8080 

SocksPort 0
ClientOnly 1
ExitRelay 0

Finally, let's create the data/sftp folder with appropriate permissions.

mkdir -p data/sftp
. .env && chown $SFTP_UID:$SFTP_UID data/sftp

Rebuild your docker image with docker compose build and start it back up with docker compose up -d.

From there, we can get the hidden service location:

cat data/tor/hs_sftp/hostname

And when you hit that URL in your Tor Browser, you should see the login page for SFTPGo:

Now click "Go to WebAdmin" and login with "admin" and the password you put in your .env file and from there you can create a new user.

• If anonymity is key, and why wouldn't it be, make sure to use a generic username.
• Don't specify a password. Password-based login is disabled anyways.
• Instead, add an SSH key (make sure it's a fresh one used just for this purpose). It defeats the purposes if you are embedding a cryptographically strong identifier publicly known to identify you into the configuration of your hidden service. (i.e. don't use the same SSH key you use for Github)

❯ ssh-keygen -t ed25519 -f secret
Generating public/private ed25519 key pair.
Enter passphrase for "secret" (empty for no passphrase):
Enter same passphrase again:
Your identification has been saved in secret
Your public key has been saved in secret.pub
The key fingerprint is:
SHA256:A9MM4NVmgmXL91N5m9yRZiqXXj42a8MdH3qX6BmycIE [email protected]
The key's randomart image is:
+--[ED25519 256]--+
|    .+=.         |
|   ..+.=+    .  .|
|    . =++   o .= |
|       + ... o=+.|
|        SEoo ++..|
|         . .= oo |
|         . o o+=*|
|          o oo+*B|
|           ..oo.o|
+----[SHA256]-----+
❯ cat secret.pub
ssh-ed25519 AAAAC3NzaC1lZDI1NTE5AAAAIMaXxhxFilNJxWGhthqZA+/Udyikijw3ZZg6f6aA6pTe [email protected]

And make sure to point it at /data/site so that the SFTP user can only see our page content.

Now we should be able to connect to it using torify or the Tor socks proxy.

torify sftp -i secret content@3evjjf7birgzsyqwt3hekhb3o2tyyjoz4wacbu2g2qvcoi46xl3ioqid.onion

❯ torify sftp -i secret content@3evjjf7birgzsyqwt3hekhb3o2tyyjoz4wacbu2g2qvcoi46xl3ioqid.onion
The authenticity of host '3evjjf7birgzsyqwt3hekhb3o2tyyjoz4wacbu2g2qvcoi46xl3ioqid.onion (127.42.42.0)' can't be established.
ED25519 key fingerprint is SHA256:SFl9klK+GV6H/EI/V2veK0rL1kzbhBJpblbHDj6gnfI.
This key is not known by any other names.
Are you sure you want to continue connecting (yes/no/[fingerprint])? yes
Warning: Permanently added '3evjjf7birgzsyqwt3hekhb3o2tyyjoz4wacbu2g2qvcoi46xl3ioqid.onion' (ED25519) to the list of known hosts.
Connected to 3evjjf7birgzsyqwt3hekhb3o2tyyjoz4wacbu2g2qvcoi46xl3ioqid.onion.
sftp> ls
index.html
sftp> put hello.txt
Uploading hello.txt to /hello.txt
hello.txt                                                       100%    3     0.0KB/s   00:00
sftp>

Oooohhhhh...

At this point, if you aren't managing additional SSH user, it would probably be a good idea to update your torrc file and remove the SFTP HTTP to reduce attack surface.

A Note on Deanonymization Risks

Just because your service is on Tor doesn’t mean you’re bulletproof.

Shared Infrastructure

Running your hidden service on the same hardware or network as other services (e.g., your personal website) can expose you to correlation attacks. For example:

“Hey, both jeff.com and this .onion site go offline at the exact same time... hmm.”

Mitigation: isolate services and use dedicated infrastructure.

Static Content Can Still Give You Away

Static ≠ invisible. Even a simple HTML page can leak clues about who you are or where you are located:

End result: a static site is easier to secure—but only if you audit the assets you publish.

Docker Security

Docker is great for isolating processes and managing deployments, but it’s not a silver bullet for security — especially when you’re relying on it to keep a service truly hidden.

In this configuration, we've taken steps to:

• Run containers as non-root users
• Run containers with read-only filesystem/tmpfs

But Docker doesn't guarantee kernel-level isolation. If there is a vulnerability in the kernel, a compromised container could potentially break out and affect the host, or leak information about it's actual location/network.

Using virtual machines (VMs) provides stronger isolation than containers alone. You can also reduce the risk of information leakage by enforcing strict network and firewall rules — ensuring that only the Tor container can communicate with the web container and nothing else can reach it.

Upgrades

It's always a good idea to stay current. You can update everything with...

# pull latest images for nginx and SFTPGo containers
docker compose pull

# rebuild our custom Tor image
docker compose build --no-cache

# restart all the services on the latest & greatest
docker compose up -d