If you manage more than one BinaryLane account, save each account's API token under a named CLI context. You can then choose the account for each command without entering its token again.
A context is a local CLI setting, not a separate account or a restriction on token permissions. The names personal and work below are fictional examples; choose names that make sense to you.
Keep API tokens secure
Access tokens are like passwords and should be kept secure. API access allows programmatic control of your account, including destructive actions such as deleting servers and data. A context name does not make a token read-only. See BinaryLane API token permissions.
TABLE OF CONTENTS
- Before you begin
- Applies to
- Configure each account
- Choose an account for each command
- Check unexpected results
Before you begin
Install the CLI using the BinaryLane CLI instructions. You need an API token from each account you want to use.
The commands below work in Bash and PowerShell. They configure local credentials and read account or server details; they do not create or change servers.
If you already use BL_API_TOKEN in your shell or automation, remove that override from the environment used for these commands first. It takes precedence over the token saved in a context. Do not print token values to check them.
Applies to
binarylane-cli0.21.0
Configure each account
For the first account, run:
bl configure --context personal
Follow the prompt's link to Developer API in mPanel. Check that you are signed in to the intended account, then select + Create Token, enter a token name and select Create. Paste that account's token at the CLI prompt. The CLI checks the token before saving it. Avoid screen sharing or recording while entering it: the prompt may display the token.
Check which account the context accesses:
bl account get --context personal
Read the returned account details and confirm they match the intended account. Keep this output private.
Repeat for the second account, using its own token. Check the account signed in to mPanel before creating or copying that token:
bl configure --context work
bl account get --context work
Use a different context name for each account. Running bl configure again with an existing context name replaces that context's saved token after successful authentication. To replace an expired or revoked token, configure the same context with a new token from the same account and repeat the account check.
Choose an account for each command
Add --context and the saved name to each command. For example, list servers in either account:
bl server list --context personal
bl server list --context work
This selects the context for that command only. It does not switch subsequent commands to that account. Before running a command that changes resources, check the account with bl account get --context work, then use that same context on the change command.
Without --context, the CLI normally uses the context named bl, not the one you used most recently. If BL_CONTEXT is set in the environment, it supplies the context instead. An explicit --context takes precedence over BL_CONTEXT.
Contexts apply to the CLI only. When calling the API directly, authenticate the request with the intended account's token; there is no context name to add to the API request.
Check unexpected results
- The wrong account appears: stop before changing anything. Check the context name and whether the token saved under that name belongs to the intended account. Also check for
BL_API_TOKENor a command-line--api-tokenoverride; both take precedence over a saved token. - Authentication fails: check the context spelling and configure that context again with a valid token from the intended account. A context name alone does not supply credentials.
- A server is missing: confirm the account first. A resource ID or name from one account should not be assumed to identify a resource in another.
The CLI saves tokens in its local configuration file. Protect that file and do not include it in shared screenshots, scripts or version control. If a token may have been exposed, revoke it in mPanel and configure the affected context with a replacement.
