Separate onion identity from the clearnet
Keep the service’s private onion keys protected and back them up if you need the address to survive a rebuild. Avoid accidental links between identities through reused credentials, content or external resources.
Bind the application deliberately
Bind the backend to a local or private interface and expose only the intended service through Tor. Check the reverse proxy and application for redirects, absolute URLs and resources that contact external hosts.
Reduce information leaks
Review error pages, headers, debug output and uploaded file metadata. Do not assume the onion route hides identifying application content. Protect the administrator login and avoid logging more visitor information than necessary.
Operate it lawfully and reliably
Keep Tor and the application updated, monitor resource use and maintain backups. Hosting and legal policies still apply. KoalaVPS has not yet published an operational onion-service approval or traffic commitment.
Check the page’s external requests
Load the service through the intended route and inspect every image, font, script, stylesheet and redirect. An external asset can create an identifying request outside the service’s intended boundary. Local assets also reduce avoidable third-party dependencies.
Preserve the address deliberately
Back up the onion identity keys privately if continuity of the address matters. A clean reinstall without those keys may produce a different address. Keep the backend bound privately and confirm that an unintended clearnet listener is not exposing the same application.
Get a private backend working before Tor routing
Install Tor from a supported trusted source for the chosen OS and confirm the service is running. Prepare a separate local web listener and test it before adding an onion route. Bind it to loopback or an appropriately permissioned Unix socket, rather than assuming a firewall hides a listener bound to every interface. This design describes lawful publication; KoalaVPS still needs to confirm any operational service policy for the actual workload.
- Use local assets and deliberate application URLs.
- Keep administration separate from the public publication path.
- Record a recovery method that does not depend only on the onion service.
Official documentation: Tor Project onion-service setup
Map an onion virtual port to the local application
The following torrc fragment illustrates a dedicated identity directory and a loopback backend on port8080. Adapt ownership and paths to the distribution’s Tor service user. The private directory must be readable/writable by that user and inaccessible to unrelated users. Validate the installed configuration before using its service-manager restart procedure. Tor creates identity files for a new directory; do not publish those private files alongside website content.
# Example torrc fragment; backend already listens on loopback:
HiddenServiceDir /var/lib/tor/koala-publication/
HiddenServicePort 80 127.0.0.1:8080
# Verify the backend independently:
curl --fail http://127.0.0.1:8080/Official documentation: Tor configuration and identity directory
Test the onion path and the unwanted clearnet path
Read only the generated hostname file to obtain the public address and open it with Tor Browser. Inspect redirects, forms, error pages and asset requests. From another network, confirm that the same backend is not accidentally reachable through a public listener. An onion address does not remove an application login requirement; use client authorisation or application authentication where access should be private. Check contact details and published content for unintended identity links.
Official documentation: Tor Project operational security
Repair permissions without replacing the identity
If the service does not appear, inspect Tor startup errors, directory ownership and the local backend before deleting anything. Replacing the identity directory creates a new address; restoring the correct private keys is what preserves continuity. Keep an encrypted offline recovery copy with restricted access and test the process using a separate disposable identity. Logs and debug pages can expose information even when transport routing is correct; review them after configuration changes.