Run Tor Hidden Services in Docker Containers
Docker provides an ideal deployment model for Tor hidden services — containers isolate the Tor daemon from your application, simplify updates, and make reproducible deployments trivial. This guide covers building a Dockerized Tor hidden service with Docker Compose, including proper volume management for onion keys and network isolation best practices.
Need this done for your project?
We implement, you ship. Async, documented, done in days.
Dockerfile for Tor Hidden Service
Create a minimal Docker image that runs the Tor daemon with your hidden service configuration:
# Dockerfile.tor
FROM debian:bookworm-slim
RUN apt-get update && apt-get install -y tor && \
rm -rf /var/lib/apt/lists/*
COPY torrc /etc/tor/torrc
RUN chown -R debian-tor:debian-tor /var/lib/tor
USER debian-tor
ENTRYPOINT ["tor", "-f", "/etc/tor/torrc"]The corresponding torrc file should point to volumes for the hidden service directory:
# torrc
SocksPort 0
HiddenServiceDir /var/lib/tor/hidden_service/
HiddenServicePort 80 web:80
HiddenServiceVersion 3
Log notice stdoutNote that HiddenServicePort points to web:80 — this is the Docker Compose service name for your web server container, resolved via Docker internal DNS.
Docker Compose Multi-Service Setup
Use Docker Compose to orchestrate the Tor daemon alongside your web application with proper network isolation:
# docker-compose.yml
version: "3.8"
services:
tor:
build:
context: .
dockerfile: Dockerfile.tor
volumes:
- tor-keys:/var/lib/tor/hidden_service
networks:
- tor-net
restart: unless-stopped
web:
image: nginx:alpine
volumes:
- ./site:/usr/share/nginx/html:ro
- ./nginx.conf:/etc/nginx/conf.d/default.conf:ro
networks:
- tor-net
expose:
- "80"
restart: unless-stopped
volumes:
tor-keys:
driver: local
networks:
tor-net:
driver: bridge
internal: trueThe internal: true flag on the network is critical — it prevents containers from reaching the internet directly, ensuring all outbound traffic must go through Tor. The web service only exposes port 80 within the Docker network, never on the host.
Managing Onion Keys with Docker Volumes
Your .onion address is derived from the cryptographic keys stored in the hidden service directory. These keys must persist across container restarts and upgrades. Docker named volumes handle this automatically, but you should also implement a backup strategy:
# Backup onion keys
docker run --rm -v tor-keys:/keys -v $(pwd)/backup:/backup \
alpine tar czf /backup/onion-keys-$(date +%Y%m%d).tar.gz -C /keys .
# Restore onion keys
docker run --rm -v tor-keys:/keys -v $(pwd)/backup:/backup \
alpine sh -c "cd /keys && tar xzf /backup/onion-keys-20260101.tar.gz"Never store onion private keys in your Docker image or Git repository. The named volume approach keeps keys on the host filesystem, separate from the container lifecycle. For additional security, encrypt the backup archives with GPG before storing them off-server.
AnubizHost — Docker-Ready Tor Hosting
AnubizHost VPS plans come with Docker and Docker Compose pre-installed, making containerized Tor hidden service deployments effortless. Our servers in Iceland, Romania, and Finland provide the privacy-friendly jurisdictions your project needs.
Deploy your Dockerized .onion service on AnubizHost infrastructure with full root access, NVMe SSD storage, and generous bandwidth. Pay with Bitcoin, Monero, or other cryptocurrencies — no KYC, no identity verification required. Our support team can assist with Docker Compose configurations, networking, and Tor optimization for containerized environments.
Related Services
Why Anubiz Labs
Ready to get started?
Skip the research. Tell us what you need, and we'll scope it, implement it, and hand it back — fully documented and production-ready.