Skip to content

Onionsite managers

This pages tracks support for onionsite managers, applications helping to setup and maintain Onion Service sites.

For the core Onion Service implementations, check this other document.

Last updated on 2026-09-01.

Onionspray and Oniongroove

Onionspray and Oniongroove are two tools developed within The Tor Project.

While Onionspray is stable, it supports only the legacy C Tor backend.

Oniongroove, in the other hand, is still a prototype, but aims to support both C Tor and the newer Arti as backends, aiding the migration from the legacy backend to the new one.

Feature Onionspray Oniongroove with C Tor Oniongroove with Arti
Stability ✅ Stable N/A ⚠ Prototype, likely to change
Support coverage While C Tor is supported While C Tor is supported Possibly while Arti is supported
Multi-site1 ✅ Implemented Planned ✅ Implemented
Multi-project2 ✅ Implemented Planned Planned
Load balancing ✅ Implemented Planned Planned
Restricted discovery ❌ Not implemented ❌ Unlikely Considered
Vanguards ❌ Not implemented ❌ Unlikely ✅ Implemented
Single Hop Mode ✅ Implemented Planned Planned
Vanity address generation ✅ Implemented Planned Planned
HTTP-mode3 ❌ Not implemented Planned Planned
HTTPS-mode4 ✅ Implemented Planned ✅ Implemented
HTTP to HTTPS5 ✅ Implemented Planned ✅ Implemented
HTTPS proxy endpoint ✅ Implemented Planned ✅ Implemented
UNIX socket endpoint ❌ Not implemented6 Planned Planned
TCP endpoint ❌ Not implemented Planned Planned
UDP endpoint N/A N/A N/A
Key migration ❌ Not implemented Planned Planned
Restricted key migration ❌ Not implemented ❌ Unlikely ❌ Unlikely
Offline keys7 ❌ Unlikely ❌ Unlikely Planned
Containerization Planned Planned ✅ Implemented
Debian package ❌ Not implemented Considered Considered
Snap package ❌ Not implemented Considered Considered
Flatpak ❌ Not implemented Considered Considered
AppImage ❌ Not implemented Considered Considered
WASM runtime ❌ Not implemented Considered Considered
CLI for quick setup ✅ Implemented Planned Planned
Automation ✅ Ansible Planned Planned
ACME for Onions ❌ Unlikely Considered Considered
WEBCAT8 ❌ Not implemented Considered Considered
Cookie-based locking ✅ Implemented (cookie_lock) ❌ Unlikely ❌ Unlikely
X-From-Onion header ✅ Implemented (x_from_onion_value) Planned Planned
HTTP Header injection ✅ Implemented (inject_headers_upstream) Planned Planned
HTTP Header suppression ✅ Implemented (suppress_header_*) Planned Planned
HTTP method suppression ✅ Implemented (suppress_methods_except_get) Planned Planned
Setting response headers ✅ Implemented (include_response_headers) Planned Planned
Well-known key-value pair proofs ✅ Implemented (ssl_proof_csv) Planned Planned
Arbitrary key-value pairs ✅ Implemented (hardcoded_endpoint_csv) Planned Planned
Proxy rewriting exceptions ✅ Implemented (preserve_*) Planned Planned
Proxy rewriting by content type ✅ Implemented (extra_processing_csv) Planned Planned
Redirects ✅ Implemented (redirect_*) Planned Planned
Blocklists ✅ Implemented (block_*, *_whitelist*, *_blacklist*) Planned Planned
HTTP proxy tunables ✅ Implemented (*nginx*) Planned Planned
Configurable logging ✅ Implemented (log_separate) Planned Planned
Upstream certificate checking ✅ Implemented (nginx_proxy_ssl_trusted_certificate) Planned ✅ Implemented
Caching ✅ Implemented (*cache*) Planned Planned
Circuit ID exporting ✅ Implemented (tor_export_circuit_id) Planned Planned
DoS protections ✅ Implemented (tor_pow_*, tor_intro_*, tor_max_*) Planned Planned
HTTP-based basic rate limiting ❌ Not implemented Planned Planned
HTTP-based circuit rate limiting ❌ Not implemented Planned Planned
HTTP-based PoW integration9 ❌ Unlikely Considered Considered
Tor daemon tuning ✅ Implemented (tor_*) Planned Planned
Address mapping ✅ Implemented (foreignmap) Planned Planned
CORS workaround (internal mapping) Considered Planned Planned

Legend

Tables in this document uses the same legend from the Implementations page.

Notes


  1. For multi-site, it's considered whether the tool can be used to host more than a single site at the same time. 

  2. For multi-project, it's considered whether the tool supports having multiple sets of sites being managed, each set having it's own configuration, and hence it's own Tor daemon instance. 

  3. HTTP mode means that it's possible to use the onionsite with HTTP -- without the additional TLS encryption (HTTPS). 

  4. HTTPS mode means that it's possible to connect to the onionsite through HTTPS. 

  5. The HTTP to HTTPS is the automatic redirection of HTTP requests to the equivalent HTTPS requests. 

  6. Onionspray does use UNIX sockets in the connection between the C Tor daemon and the HTTPS proxy, but is does not support a direct UNIX socket connection to the final website endpoint, such as a backend web server providing the actual application. 

  7. Offline keys are described in the rend-spec

  8. WEBCAT support could be twofold: first, by checking if the upstream site can be validated through WEBCAT; second, by optionally (re)signing the manifest. 

  9. HTTP-based Proof-of-Work (PoW) could be implemented by plugging the onionsite manager directly with a tool like Anubis, go-away or iocaine. But a similar, easier setup could be achieved by plugging the same tool in the backend, which would protect the site regardless how it's being accessed (through .onion or clearnet).