Profiles, Config, and Secrets
Profiles, config, and secrets without the credential chaos.
Beltline gives generated CLIs a consistent way to handle user config, project config, environment overrides, named profiles, and secure credential storage.
Context switching should not mean token juggling. Make the safe path the default. The CLI should know who, where, and which environment before it acts.
Every internal CLI eventually needs context.
Users switch between staging and production. Contractors hold multiple accounts. CI needs non-interactive credentials. Projects need local defaults. Tokens have to stay out of Git history.
Most teams add this ad hoc — env vars here, config files there, a hardcoded base URL somewhere else — and end up with something fragile that breaks in CI and confuses new team members in their first week.
Before and after Beltline
| Before | After Beltline |
|--------|----------------|
| Tokens copied into shell env vars | Named profiles with isolated tokens |
| Staging/prod flags repeated everywhere | Project-level config with sensible defaults |
| No profile conventions | User-level config respecting XDG_CONFIG_HOME |
| Project config committed inconsistently | Clear split between shared and machine-local config |
| Hard-to-debug CI behavior | Every value overridable via environment variable |
| No non-interactive mode | First-class non-interactive flag for CI and agents |
Named profiles and project defaults
acme auth login
acme profile create staging
acme profile create production
acme profile use production
acme config set project.defaultEnv prod
acme whoami
Output:
user maya@acme.com
profile production
project billing-api
env prod
storage macOS Keychain
The same acme whoami --json returns a stable JSON envelope for CI logs and agent debugging.
What Beltline handles for you
Named profiles for real company workflows
Each profile carries its own token, base URL, and overrides. Switch with --profile or ACME_PROFILE. Works the way you would expect from aws or kubectl.
Project config for team defaults
Per-project config lives in .acme.yaml or a local config directory. Set project defaults once; every team member gets the same starting context.
Environment variables for CI Every config value can be set via environment variable for non-interactive CI runs. No special CI mode to wire up — the convention is built into the runtime.
Secrets stay out of command history and Git Tokens and credentials are stored in the OS keychain by default. Config files that accidentally contain sensitive values are flagged at runtime.
Same context across CLI, MCP, and automation surfaces The active profile, project, and credentials are available to CLI commands, MCP tools, and generated automation adapters from the same context layer.
Frequently asked questions
Can users switch between staging and production?
Yes. Named profiles and acme profile use <name> make context switching explicit. You can also set a default profile per project.
Can CI use the generated CLI?
Yes. Every config value accepts an environment variable override. Set ACME_PROFILE, ACME_TOKEN, and ACME_BASE_URL and the CLI runs non-interactively.
Where are tokens stored? Beltline uses the OS credential store by default — Keychain on macOS, Credential Manager on Windows, libsecret on Linux. Encrypted file fallback for headless environments.
Can different team members have different profiles? Yes. User-level config and credentials are scoped to the local machine. Project config is shared through the repository. They do not conflict.