# CLI commands

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

## Configuration

Two settings persist: `api-url` and `insecure`.

```sh
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.

:::caution[`--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.
:::