Manage your Onion Services via CLI or TUI on Unix-like operating system with a POSIX compliant shell.
Alternatives To Onionjuggler
Project NameStarsDownloadsRepos Using ThisPackages Using ThisMost Recent CommitTotal ReleasesLatest ReleaseOpen IssuesLicenseLanguage
Dive36,14215 days ago28July 02, 2021152mitGo
A tool for exploring each layer in a docker image
Textual18,4006511 hours ago19April 30, 2022128mitPython
Textual is a Rapid Application Development framework for Python. Build sophisticated user interfaces with a simple Python API. Run your apps in the terminal and (coming soon) a web browser!
Bubbletea17,4103017 days ago130August 19, 202263mitGo
A powerful little TUI framework 🏗
19 hours ago20July 26, 20225bsd-2-clauseC
n³ The unorthodox terminal file manager
5 days ago355mitC
GoAccess is a real-time web log analyzer and interactive viewer that runs in a terminal in *nix systems or through your browser.
Wtf14,7021a day ago97February 18, 202229mpl-2.0Go
The personal information dashboard for your terminal
Spotify Tui14,201
2 months ago24August 24, 2021262mitRust
Spotify for the terminal written in Rust 🚀
Glow11,966197 days ago25February 14, 202295mitGo
Render markdown on the CLI, with pizzazz! 💅🏻
7 days ago23March 02, 202242otherGo
Disk Usage/Free Utility - a better 'df' alternative
3a month ago15January 12, 202235mitJavaScript
System monitoring dashboard for terminal
Alternatives To Onionjuggler
Select To Compare

Alternative Project Comparisons


shellcheck CodeFactor GitHub top language License Just works

Feature-rich onion service manager for UNIX-like operating systems written in POSIX compliant shellscript

OnionJuggler is a minimal requirement, portable collection of scripts and documentation to help the service operator juggle (manage) his onion(s).

WARNING: do not trust this repo yet, backup your hs keys in another location. This project has not been released and should be considered for development only.

Quick link to this repository: git.io/onionjuggler

Table of Contents



tui-dialog tui-whiptail cli


This project was started after seeing the amazing OnionShare CLI python scripts, which possibilitates ephemeral onion services that never touch the disk and can be run on Tails or Whonix easily. Then after seeing the RaspiBlitz onion service bash script for the Raspberry Pi, the idea to port it to any Debian distribution started. As the idea grew, using GNU Bash and Linux was a single point of failure 1 2, so the making the script POSIX compliant to be compatible with any Unix-like system was a definitive goal.


The goal of this project is:

  • facilitate onion service management, from activating a service to adding client authorization to it, giving the full capabilities of editing files manually would have but with less tipying.
  • show the that managing the onion service is much more than just using a webserver with your pages.
  • distribution, from the source code level (FOSS) to the effect it takes when it allows anyone to run the code on any operating system, shell or service manager. Mitigation from a single point of failure

Mitigation from a single point of failure:

  • Kernel from predominant Linux to also BSD and any other Unix-like system.
  • Shell from predominant Bash to also any POSIX shell such as ksh, (y,d)ash and Zsh (emulating sh).
  • Service manager from predominant Systemd to also RC, OpenRC, SysVinit, Runit.

Editing the tor configuration file (torrc) is not difficult, but automation solves problem of misconfiguration and having:

  • less time spent by running a single line command
  • no downtime by rejecting invalid configuration before applying them to be used
  • complete uniformity
  • graphical interface to help newbies


  • Enable service - Create directory if not existent (HiddenServiceDir), select onion version (HiddenServiceVersion), custom socket type being unix or tcp, with as many virtual ports as you would like, as well as targets (HiddenServicePort).
  • Disable service - Remove service configuration from the torrc, the service will not be acessible anymore, but you can enable it again any time you want. Optionally purge the service, deleting its configuration and directory, which will delete its keys permanently.
  • Renew service address - Focused on private onion services, if you ever leak its address, you can change its hostname, beware all of your authorized clients will be disconnected and the service keys will be permanently deleted.
  • Credentials - Show hostname, clients, torrc block, qrencoded hostname.
  • Onion authentication - For v3 onion services only. This depends on client and server side configuration and works with a key pair, the client holds the private key part either generate by him (more safe) or given by the service operator and the onion service operator holds the public part. If any if
    • Server - Generate key pair or add public part, list client names and their public keys from <HiddenServiceDir>/authorized_clients/<client>.auth. If any client is configured, the service will not be acessible without authentication.
    • Client - Generate key pair or add public part, list your <ClientOnionAuthDir>/<SOME_ONION>.auth_private.
  • Onion-Location - For public onion services You can redirect your plainnet users to your onion service with this guide for nginx, apache2 and html header attributes.
  • OpSec - Operation Security
    • Unix socket - Support for enabling an onion service over unix socket to avoid localhost bypasses.
  • Web server - Serve files with your hidden service using Nginx or Apache2 web server.
  • Usability - There are two dialog boxes compatible with the project, dialog and whiptail.
  • Bulk - Some commands can be bulked with the argument @all to include all services or clients depending on the option --service or --client, list enabled arguments[SERV1,SERV2,...] and [CLIENT1,CLIENT2,...], the command will loop the variables and apply the combination.
  • Fool-proof - The script tries its best to filter invalid commands and incorrect syntax. The commands are not difficult but at first sight may scare you. Don't worry, if it is invalid, it won't run to avoid tor daemon failing to reload because of invalid configuration. If an invalid command runs, please open an issue.


  • General:

    • Unix-like system.
    • superuser privileges to call commands as root and the tor user
  • Required programs:

    • sh - any POSIX shell: dash 0.5.4+, bash 2.03+, ksh 88+, mksh R28+, yash 2.29+, busybox ash 1.1.3+, zsh 3.1.9+ (zsh --emulate sh) etc.
    • tor >=
    • grep >=0.9
    • sed
    • openssl >= 1.1 (Client Authorization - requires algorithm x25519, so it can't be LibreSSL)
    • basez >= 1.6.2 (Client Authorization)
    • git (Build)
    • dialog/whiptail (TUI)
    • nginx/apache2 (Web server)
  • Optional programs:

    • (lib)qrencode >= 4.1.1 (List)
  • Development programs:

    • pandoc (Manual)
    • shellcheck (Review)


Mainly tested on Debian systems, including Whonix.

It can work on OpenBSD -

  • auth -> if you build basez from source, as it is not in ports.
  • web -> nginx or apache, openbsd's httpd configuration was difficult to cleanly remove the server block

Regarding other operating systems, please see etc/onionjuggler for pre-defined configuration for your operating system. They were not all tested


Clone the repository

git clone https://github.com/nyxnor/onionjuggler.git
cd onionjuggler

Setup the enviroment

Run from inside the cloned repository to create the tor directories, create manual pages and copy scripts to path:

./configure.sh --install

Set custom variables

You should not modify the default configuration on /etc/onionjuggler/onionjuggler.conf, it will be modified on every update. Your local configurations should be on /etc/onionjuggler/conf.d/*.conf, and from this folder, they will be parsed using lexical order, and the last value will supersede the defaults.


Each configuration and script has its own manual page and help message, it is the best way to learning onionjuggler entirely.

Before executing any script to make changes, it is recommended to see what options are configured. Every script has a --getconf option that will print the current configuration read by onionjuggler:

onionjuggler-cli --getconf

It is also possible to get command line options without making changes, useful to see if the assignment is correct:

onionjuggler-cli --getopt --service=example --hs-version=3

To use the TUI, just run:


To create a service on the CLI:

onionjuggler-cli --on --service=terminator --socket=tcp --hs-version=3 --port="80:"

Many more things are possible, read the man pages

Featured on


Contributors graph

Popular Tui Projects
Popular Command Line Projects
Popular Command Line Interface Categories
Related Searches

Get A Weekly Email With Trending Projects For These Categories
No Spam. Unsubscribe easily at any time.
Shell Script
Self Hosted