Tor Hidden Service Hosting — Deploy .onion Sites in Minutes

A Tor hidden service is a server that is only accessible through the Tor network. Instead of a traditional domain name, it uses a .onion address — a 56-character string derived from the service's cryptographic key. This architecture means the server's real IP address is never exposed to visitors, and visitors' IP addresses are never exposed to the server. Both parties communicate through encrypted Tor circuits.

Version 3 onion addresses, the current standard, use Ed25519 cryptography and provide significantly stronger security than the deprecated v2 addresses. They are resistant to enumeration attacks, making it impossible for adversaries to discover hidden services by brute force. AnubizHost exclusively deploys v3 hidden services.

Hidden services are not just for anonymity — they also provide built-in end-to-end encryption without needing a TLS certificate from a certificate authority. The .onion address itself serves as the cryptographic identity of the server, so visitors know they are connecting to the authentic service without relying on third-party trust.

AnubizHost's hidden service hosting runs on dedicated hardware isolated from our clearnet infrastructure. Each server features NVMe SSD storage for fast response times, ECC RAM for data integrity, and full-disk encryption using LUKS with keys held only in memory. If a server loses power, all data becomes cryptographically inaccessible.

We configure Tor with optimized settings for hidden service performance, including vanguard protections against guard discovery attacks, connection padding to resist traffic analysis, and carefully tuned circuit-build timeouts. These settings are based on the latest recommendations from the Tor Project's security team and our own operational experience.

Network isolation is enforced at the firewall level. Hidden service servers cannot make clearnet connections unless you explicitly configure them to do so. DNS resolution is disabled by default, and all outbound traffic is routed through Tor. This prevents accidental IP leaks even if an application is misconfigured.

Every hidden service deployment includes our baseline security hardening. The operating system is stripped to essential packages only, reducing the attack surface. AppArmor profiles confine the Tor process and your web server to their minimum required permissions. Kernel hardening parameters are applied following CIS benchmark recommendations.

We deploy automated intrusion detection using AIDE for file integrity monitoring and custom rules that watch for unauthorized modifications to your Tor configuration and onion service keys. Any unexpected changes trigger immediate alerts to our security team. We also run regular vulnerability scans against the local service stack.

Tor hidden service keys are stored in a dedicated encrypted partition with restricted filesystem permissions. Only the Tor process can read them, and they are never included in standard backups unless you explicitly request it. This ensures that even if a backup is compromised, your .onion address cannot be impersonated.

We support multiple deployment methods for your hidden service. Upload your site via SFTP over Tor, push from a Git repository through our Tor-accessible GitLab instance, or use our API to automate deployments from your CI/CD pipeline. For static sites, simply drop your HTML files into the web root and they are instantly served over your .onion address.

Dynamic applications are fully supported. We provide pre-configured environments for PHP, Python, Node.js, Ruby, and Go. Database servers including PostgreSQL, MySQL, and MongoDB can be deployed alongside your application, all accessible only through Tor. We also support containerized deployments using Docker for complex multi-service architectures.

If you need multiple hidden services, our multi-onion hosting plans let you run several .onion addresses from a single server, each with its own isolated web root and configuration. This is ideal for organizations that operate separate services for different purposes — such as a public information site alongside a secure document submission system.