CLI commands

The settings the DBGorilla CLI keeps between commands, and where each value comes from.

Configuration

Two settings persist: api-url and insecure.

dbgorilla config get api-url    # the value, and where it came from
dbgorilla config set api-url https://dbgorilla.your-company.example
dbgorilla config unset api-url

A setting can come from five places. The first one wins:

Order	Source
1	--api-url on the command line
2	the DBGORILLA_API_URL environment variable
3	your config file: ~/.config/dbgorilla/cli.toml, or $XDG_CONFIG_HOME/dbgorilla/cli.toml
4	a system-wide file your IT team deploys: /Library/Application Support/dbgorilla/cli.toml on macOS, /etc/dbgorilla/cli.toml on Linux
5	app.dbgorilla.com, the built-in default

dbgorilla config unset api-url therefore returns the CLI to SaaS instead of leaving it without an endpoint.

dbgorilla config get tells you which layer won, which is the fastest way to find out why a command is talking to the wrong deployment.

--insecure is sticky

-k / --insecure turns off TLS certificate checking. Passing it to dbgorilla login writes it to your config file, and it then applies to every later command with no flag and no warning.

Clear it with dbgorilla config unset insecure, or override a single command with --insecure=false.

The user and system-wide settings are combined rather than overridden. If your IT team set insecure in the system-wide file, clearing your own config does not switch it off. Only --insecure=false on the command line does.