Configuration

Configuration

Joro is configured via command-line flags at startup. Everything else is managed from the web UI and saved with your project — intercept toggles, scope, match-and-replace rules, passive detection, projects, C2 connections, and team server credentials all live there rather than on the command line. See Settings and Projects. Automation tokens and the MCP listener are also managed from the UI, but are stored outside any project — see Automation.

Flags

Flag	Default	Description
--proxy-port	8080	Intercepting proxy listen port
--ui-port	9090	Web UI and API listen port
--data-dir	~/.joro	Directory for CA cert, key, and databases
--dev	false	Proxy UI requests to the Vite dev server (frontend development only)
--vite-url	http://localhost:5173	Vite dev server URL, used with --dev
--listener	false	Run in listener mode (callback server, no proxy)
--domain		Callback domain for listener mode (e.g. callback.example.com)
--dns-port	53	DNS listener port (listener mode)
--http-port	80	HTTP callback listener port (listener mode)
--https-port	443	HTTPS callback listener port (listener mode, 0 to disable)
--smtp-port	25	SMTP callback listener port (listener mode, 0 to disable)
--smtps-port	465	SMTPS (implicit TLS) callback listener port (listener mode, 0 to disable)
--ftp-port	21	FTP callback listener port (listener mode, 0 to disable)
--ftps-port	0	FTPS (implicit TLS) callback listener port (listener mode, disabled unless set)
--ldap-port	389	LDAP callback listener port (listener mode, 0 to disable)
--ldaps-port	0	LDAPS (implicit TLS) callback listener port (listener mode, disabled unless set)
--tls-cert		PEM certificate for the HTTPS/SMTPS/FTPS/LDAPS listeners (listener mode); replaces the self-signed leaf. Requires --tls-key.
--tls-key		PEM private key paired with --tls-cert (listener mode)
--response-ip	127.0.0.1	IP address returned in DNS A responses (listener mode)
--bind	127.0.0.1	Bind address. In proxy mode this governs the proxy port only — the UI/API and the MCP listener are always loopback. In listener mode it defaults to 0.0.0.0 so callbacks are reachable.
--allowed-host		Additional Host header value(s) the proxy-mode UI/API will accept beyond loopback, e.g. an SSH-tunnel entry address. Comma-separated or repeatable; same-origin checks still apply.
--teamserver	false	Enable team server mode (requires --listener)
--disable-update-checks	false	Disable update checks at startup and in the background (also toggleable in Settings)
--no-automation	false	Disable the automation API and MCP listener entirely — no routes, no token file, no second port. See Automation
--automation-privileged	false	Make web shell execution and Sliver/Mythic C2 grantable as automation capabilities. Each still requires an explicit per-capability grant
--automation-scripting	false	Make the script capabilities grantable, and let the script kind of automation run. Runs submitted JavaScript in a sandboxed worker process against Joro's SDK. Each still requires an explicit per-capability grant. See Scripting
--automation-commands	false	Allow installed command automations to run a local operating-system command, on a trigger or as a lens. Grants nothing to a token — no capability sits behind it, and only automations you installed yourself can use it. See Scripting#local-commands
--no-webhooks	false	Disable outbound webhooks entirely — no routes, no ~/.joro/webhooks.json, and no outbound request from this process. Needs none of the automation flags to be useful, and is not gated by them. See Webhooks
--no-plugins	false	Do not load plugins from ~/.joro/plugins/. They are still listed in Settings so one can be deleted. This is the way back from a plugin the binary cannot load — see Plugins
--version, -v		Print version and exit
--build-plugin		Build a plugin from the given source directory and exit
--install	false	Copy the built plugin to ~/.joro/plugins/ (use with --build-plugin)
--output, -o		Output path for the built plugin (use with --build-plugin)

Common invocations

Default proxy mode:

./joro

Custom ports:

./joro --proxy-port 9000 --ui-port 9100

Listener mode on a remote host:

./joro --listener --domain callback.example.com --response-ip <remote-host-ip>

See Listener-Mode for DNS delegation and firewall requirements.

Team server:

./joro --listener --teamserver --domain callback.example.com --response-ip <remote-host-ip>

See Team-Server for operator onboarding.

Proxy mode with web shell execution and C2 grantable to automation:

./joro --automation-privileged

The MCP listener itself is still off until you enable it and issue a token. See Automation.

Proxy mode with JavaScript automations:

./joro --automation-scripting

The automation flags are separate axes: this one enables the scripting sandbox and the automation editor, and grants nothing toward web shell execution or C2. Take any without the others, or all together. See Scripting.

Proxy mode with local command automations:

./joro --automation-commands

Command automations run local tools against captured traffic. Without this flag they install and list but do not run. It is not a grant: no automation token can reach a command automation, whatever it holds. See Scripting#local-commands.

Build and install a plugin:

./joro --build-plugin examples/plugins/hello-feature --install

See Plugins for details.

Starting after a plugin that will not load:

./joro --no-plugins

A Go plugin is opened before the API server binds, so a plugin this binary cannot load is a Joro that will not boot. This starts without opening any of them, and still lists them in Settings → Plugins so you can delete the offender. See Plugins.

Modes are mutually exclusive

Listener and proxy modes do not run in the same process. The typical setup is listener on a remote host plus proxy on your local workstation, with the proxy pointing at the listener's API over the network.