onionize

Put any Docker service on Tor with one env var.

Point it at a container or a port on your host. It writes the config, starts Tor, and prints the .onion address. Nothing gets published on your host.

Interactive setup: pick your network and container from a list

$ bash <(curl -fsSL onionize.dev/run.sh)

Or add it to your compose file

services:
  app:
    image: nginx:alpine

  onion:
    image: ghcr.io/abiabdillahx/onionize
    depends_on: [app]
    environment:
      TARGET: app:80
    volumes:
      - onion-keys:/var/lib/tor

volumes:
  onion-keys:
  1. $ bash <(curl -fsSL onionize.dev/run.sh)
  2. Where does the service run?
  3. 1) Docker container
  4. 2) Directly on this host
  5. > 1
  6. Which Docker network? > myapp_default
  7. Which container? > myapp-web-1
  8. Container port [5000]: ⏎
  9. Onion port [80]: ⏎
  10. Start it now? [Y/n] ⏎
  11. waiting for the onion address ........
  12. onion is up:
  13. http://xxxxxxxxxxxxxxxx.onion -> myapp-web-1:5000
  14. open it in Tor Browser.

How it behaves

One env var
TARGET=app:80 is the whole configuration. The torrc, hostname lookup and onion port are generated for you.
No ports published
The app is reachable only through its .onion address, so there are no host port conflicts to sort out.
Same address every time
The key lives in a volume. Recreate or update the container and the address stays the same.
Many services, one address
TARGET=app:3000,443:app:3443 maps each onion port to its own service.

Before you ship