plan, apply, destroy, test — read the active profile to know where each service lives and how to authenticate.
Where profiles live
Profiles are stored in~/.wxctl/config.json. You don’t edit it by hand — wxctl init writes it for you:
-f, --filenamescopes the prompts to just the services a configuration references, instead of every supported service.-p, --profilenames the profile being written; omit it to write thedefaultprofile.--templateskips the interactive prompts and emits a profile with placeholder values — useful for piping or generating a starting point to fill in later.
~/.wxctl/config.json, pass --profile-path <path>.
Choosing the active profile
When a command needs credentials, wxctl resolves the active profile in this order — the first match wins:- The
-p, --profile <name>flag - The
WXCTL_PROFILEenvironment variable - The name stored in
~/.wxctl/active_profile default
Authentication types
Each service in a profile declares anauth_type that selects how wxctl obtains a token. The table below lists the type and the config fields it uses — fill the values in via wxctl init.
| Type | auth_type | Config fields |
|---|---|---|
| IBM Cloud API key | apikey | apikey |
| ZenApiKey (Software Hub) | zenapikey | username, apikey |
| Cloud Pak for Data | cp4d / icp4d | username, password |
| HMAC (object storage) | hmac | access_key, secret_key |
| Basic | basic | username, password |
| Bearer token | bearer | apikey |
| None (local) | none | — |
apikey; Software (Cloud Pak for Data / Software Hub) services use cp4d or zenapikey — apikey is rejected on Software and zenapikey on SaaS. hmac covers object-storage (S3 / COS) services.
Credentials live only in
~/.wxctl/config.json and in the environment variables your YAML references with ${env:VAR}. Never commit credentials into a configuration file — keep them in your profile or the environment.Next steps
Declarative model
Resources, references, and
${env:VAR} interpolation.Pipeline
The stages every command runs.

