# Configuration

How the Sinch CLI stores its settings, switches between projects, and exposes global flags and debug output. For the `sinch config` command itself, see the [config command reference](/docs/functions/cli/commands/config).

## Config file

Each profile's settings are stored in `~/.sinch/profiles/<name>.json`. `~/.sinch/config.json` records which profile is active, plus settings that apply to every profile, such as `autoUpdate`. Use `sinch config set` or `sinch auth login` to update values.

| Field | Description |
|  --- | --- |
| `projectId` | Your Sinch project ID |
| `apiUrl` | SinchFunctions API URL (defaults to production) |
| `keyId` | Public key identifier (non-secret) |
| `defaultVoiceServiceId` | Voice v2 service `init` last picked, preselected on the next `init` (override with `--voice-service-id`) |
| `autoUpdate` | Install CLI updates automatically (default off) |


Key secrets are never written to these files — they live in your OS keychain. Only non-secret identifiers are stored.

## Environment variable override

For CI/CD pipelines, bypass the keychain with environment variables:

```sh
SINCH_PROJECT_ID=...
SINCH_KEY_ID=...
SINCH_KEY_SECRET=...
```

When all three are set, the CLI uses them instead of the stored profile's credentials and project — no `sinch auth login` required. Set them together: with only `SINCH_KEY_ID` and `SINCH_KEY_SECRET`, the project still comes from the active profile.

See [CI/CD](/assets/ci-cd.66afb53ca35033512942b50d6ad0ff9e0768727ac2c2100f305647ab37d7185b.8a245974.md) for complete GitHub Actions and GitLab CI examples.

## Config profiles

Profiles let you switch between multiple Sinch projects without re-authenticating.

```sh
sinch config profile create staging    # create a new profile
sinch config profile use staging       # switch to it
sinch config profile list              # show all profiles
sinch config profile delete staging    # remove a profile
```

To run one command against another project, pass `--profile <name>`, for example `sinch --profile staging functions list`. The flag works with every command and does not change the active profile. To make another profile the default for later commands, run `sinch config profile use <name>`. `sinch config profile create` asks whether to switch to the new profile, and leaves the active profile alone when you answer no or when it cannot prompt.

`--profile` must name a profile that exists. A misspelled name fails with exit code 64 and creates nothing. Without the flag, commands use the active profile as before.

## Global flags

| Flag | Description |
|  --- | --- |
| `-h, --help` | Show help for the current command |
| `-V, --version` | Print CLI version |
| `--profile <name>` | Run this command against a profile other than the active one. The profile must exist |


## Corporate proxies and custom certificates

The CLI trusts the certificate authorities in your operating system's trust store as well as its own bundled list. On a managed laptop whose network proxy inspects TLS, the proxy's root certificate is usually already in the system store, so no setup is needed.

If the root certificate is not in the system store, save it as a PEM file and point `NODE_EXTRA_CA_CERTS` at it:

```sh
export NODE_EXTRA_CA_CERTS=/path/to/corporate-root.pem
```

`SELF_SIGNED_CERT_IN_CHAIN` or `UNABLE_TO_GET_ISSUER_CERT` means the CLI was not given the certificate that signed the connection. Check that the variable is exported in the shell, CI job or agent that runs the CLI, and that the file holds the root certificate rather than an intermediate.

## Update environment variables

| Variable | Effect |
|  --- | --- |
| `SINCH_NO_AUTO_UPDATE=1` | Never install updates automatically |
| `SINCH_AUTO_UPDATE=false` | Same. Also accepts `0`, `no`, `off` |
| `SINCH_AUTO_UPDATE=true` | Opt in, unless `autoUpdate` is explicitly `false` in the config |


The environment can always turn auto-update **off**, but can only turn it **on** when you have not
explicitly turned it off with `sinch config set autoUpdate false`. That way a project you cloned
cannot re-enable unattended installs on a machine whose owner declined them.

Values that are not recognised as true or false are ignored rather than treated as "on", so a
stray `export SINCH_AUTO_UPDATE=` does not silently opt you in.

See [Updating](/docs/functions/cli/installation#updating) for what auto-update does.

## Debug environment variables

| Variable | Effect |
|  --- | --- |
| `SINCH_DEBUG=1` | CLI debug logs (operations, timing) |
| `SINCH_DEBUG=2` | + HTTP requests (method, URL, status) |
| `SINCH_DEBUG=3` | + request headers (redacted) |


Also configurable via `sinch config set debug <0-3>`. Levels 2–3 cover both the
axios-based commands (functions, templates, storage) and the SDK-based commands
(fax, voice, conversation, numbers). At level 3 the SDK-based commands also log
a redacted preview of the request body. Response bodies are not logged, except
the body of a failed OAuth exchange, which is logged in full.