AdviblyConfiguration
Default arguments, profiles, environment variables and where state lives.
Default arguments
advibly config stores defaults applied to any command whose schema has that
property, when you do not pass the flag:
advibly config set brand_id <id>
advibly config set project_id <id>
advibly config list
advibly config unset project_idSetting brand_id once is the single biggest quality-of-life change, since
almost every generation command takes it.
Defaults are profile-scoped. Verify advibly whoami and advibly config list
before a batch that can spend credits; together they identify the account and
arguments the batch will use.
Environment
| Variable | Effect |
|---|---|
ADVIBLY_SERVER | MCP endpoint. Defaults to https://advibly.com/mcp. |
ADVIBLY_CONFIG_DIR | Relocates the whole state directory. Useful in CI. |
ADVIBLY_DEBUG | 1 prints stack traces for unexpected errors. |
Profiles
--server <url> overrides the endpoint for one command. A bare host gets
/mcp appended automatically.
Each endpoint keeps its own profile - tokens, OAuth client and defaults - and its own tool cache, keyed by host. Switching servers never mixes credentials, which is what makes pointing the CLI at a staging deployment safe.
State on disk
Everything lives under ~/.config/advibly:
- tokens, owner-readable only
- one profile per server host
- a tool-list cache per account, under
cache/
advibly logout --all clears every profile.
Treat the state directory as credentials. Keep it out of source control and do not copy one user's profile into shared CI storage.
In CI
export ADVIBLY_CONFIG_DIR=/tmp/advibly
export ADVIBLY_SERVER=https://advibly.com/mcp
advibly generate-image --args-file ./brief.json --json --timeout 900Check the exit code rather than parsing the output.
Use an isolated ADVIBLY_CONFIG_DIR per CI identity so concurrent jobs cannot
overwrite one another's profile or defaults.