CLI Servers & Credentials

The CLI can keep credentials for more than one Unmeshed server at a time. It tracks one active server and uses that server for commands such as run, call, search, update, and upload.

The login command can run interactively or non-interactively.

Examples:

The current login flow:

1. Reads the instance URL and API key from flags, environment variables, stdin, or prompts
2. Verifies the credentials by calling /api/namespaces
3. Stores the credentials using the configured credential store
4. Saves the server and sets it as active

Supported login inputs:

• --url
• --api-key
• --api-key-stdin reads the API key from stdin
• --non-interactive fails instead of prompting when required login inputs are missing

If you need to disable TLS verification for a specific server entry, use:

That flag is stored with the server record, so later CLI calls to that server use the same TLS mode.

Use:

Behavior to expect:

• unmeshed server active prints the active server and whether SSL verification is enabled or disabled for it.
• unmeshed server list is interactive in a terminal. You can move through the configured servers and press Enter to make one active.
• In non-interactive output, unmeshed server list prints the configured servers and marks the active one.

Use one of these patterns:

Current behavior:

• With one configured server, unmeshed logout removes that server directly.
• With multiple configured servers, unmeshed logout opens an interactive selection list.
• unmeshed logout --all deletes the credential file after confirmation.

The CLI defaults to local-file storage when no external credential store is configured.

The default credentials file is:

The CLI writes that file with restrictive 0600 permissions.

When you stay on the default storage mode, ~/.unmeshed.ini holds:

• the active server
• the configured server URLs
• the API keys
• each server's disable_ssl_verification setting

When no external credential store is configured, unmeshed login stores credentials in this local file automatically.

Run:

The current storage choices are:

• local-file
• azure-key-vault

When local-file is selected:

• API keys stay in ~/.unmeshed.ini
• no external vault is required
• the CLI reads the API key directly from the file

When azure-key-vault is selected:

• the CLI expects the host to already have Azure credentials that can access the target vault
• the CLI performs a connectivity test by writing and reading a temporary secret
• the API key for each server is stored in Azure Key Vault
• the CLI keeps server metadata locally in ~/.unmeshed.ini

With Azure Key Vault enabled, the local file still stores:

• the active server
• each server URL
• the Key Vault configuration
• each server's disable_ssl_verification setting
• the local reference to the secret name (api_key_secret_ref)

The actual API key value lives in Key Vault. At runtime, the CLI resolves the secret and loads the current value before making API calls. That means you can rotate the secret outside the CLI and the CLI will read the updated value when it needs it.

For automation, unmeshed login can be scripted with flags, environment variables, or stdin. Even so, avoid depending on interactive server switching. Use separate runners or separate home directories per environment instead, and let each environment keep its own ~/.unmeshed.ini with the right active server already selected.

• CLI & Remote Agents
• Setup & Upgrades
• CI/CD & Environment Promotion