High-Availability Tor Hosting — Redundant .onion Infrastructure

OnionBalance is the foundation of our high-availability Tor hosting. It allows multiple backend servers to share a single .onion address, distributing incoming Tor connections across the server pool. To visitors, your service appears as a single hidden service, but behind the scenes, multiple independent servers handle requests, providing both load distribution and fault tolerance.

Our standard HA configuration uses three backend servers in two data centers. Each backend runs an independent instance of your application, database replica, and Tor process. OnionBalance publishes descriptors for all backends, and Tor's routing layer distributes connections among them. If any backend becomes unavailable, connections automatically route to healthy backends with no user-visible interruption.

For the highest availability requirements, we deploy five or more backends across three or more data centers in different countries. This configuration withstands the loss of an entire data center — whether from hardware failure, network outage, natural disaster, or legal action — while maintaining uninterrupted service for your visitors.

Our monitoring system checks each backend's health via Tor circuits every 30 seconds. Health checks verify Tor process responsiveness, web server availability, application health endpoints, and database connectivity. A backend that fails two consecutive checks is marked unhealthy and removed from the OnionBalance descriptor within 60 seconds.

When a backend is removed from rotation, our automation system immediately begins diagnosis and recovery. Common issues like Tor process hangs, web server crashes, or disk space exhaustion are automatically resolved. For hardware failures, a replacement server is provisioned from our standby pool, your application is deployed from the latest backup, and the new backend is added to OnionBalance — typically within 15 minutes.

Database failover uses streaming replication with automatic promotion. One backend hosts the primary database, while others host synchronized replicas. If the primary fails, a replica is automatically promoted to primary, and the remaining replicas repoint to the new primary. Write availability is restored within two minutes of primary failure detection.

High availability requires keeping data synchronized across multiple servers. For database-backed applications, we use PostgreSQL streaming replication with synchronous commit to a minimum of one replica, ensuring that committed transactions are never lost. Read queries are distributed across all replicas, while writes go to the primary.

File synchronization between backends uses real-time replication via Syncthing over Tor. User uploads, application-generated files, and configuration changes propagate to all backends within seconds. Conflict resolution follows a last-writer-wins policy with full version history, so no data is lost even if simultaneous modifications occur on different backends.

Session management is handled through Redis Sentinel with automatic failover. User sessions are stored in a Redis cluster accessible to all backends, so a user's session remains valid regardless of which backend handles their next request. This is transparent to the application — sessions work exactly as they would on a single-server deployment.

Our high-availability Tor hosting plans include a 99.99% uptime SLA, allowing a maximum of 52 minutes of downtime per year. Uptime is measured by our monitoring probes that connect to your .onion address from diverse Tor circuits every 60 seconds. If any probe successfully connects and receives a valid response, the service is considered available.

Service credits are applied automatically when SLA targets are missed. For each hour of downtime beyond the SLA allowance, you receive credit equal to 10% of your monthly fee, up to 100% of that month's charges. Credits are applied to your next billing cycle without requiring a support request — our monitoring data automatically triggers the credit calculation.

We publish real-time and historical availability data for our infrastructure through a Tor-accessible status page. You can independently verify our uptime claims and compare them against our SLA commitments. This transparency is essential for customers making critical infrastructure decisions based on our availability guarantees.