Log In

Run:

spinup login

The CLI starts a device authorization flow, prints a verification URL and code, tries to open your browser, and then polls until you approve the request.

If you point the CLI at a non-default API or auth host, re-run the command with --allow-non-default-host. The CLI prints the effective non-default endpoints before it sends credentials there.

What gets stored

After a successful login, the CLI writes a config file to:

~/.config/spinup/config.json

If XDG_CONFIG_HOME is set, Spinup uses $XDG_CONFIG_HOME/spinup/config.json instead.

What the config contains

{
  "cliApiKey": "sk_user_...",
  "defaultWorkspaceSlug": "acme"
}

The stored cliApiKey is a personal/device key. It can also be passed to @getspinup/sdk as apiKey, although dashboard-created workspace API keys are the better default for app code and automation.

Endpoint overrides are not written automatically during login. Use SPINUP_BASE_URL and SPINUP_AUTH_BASE_URL for one-off local or staging commands, or edit the config file manually if you want persistent non-production endpoints. Credentialed login against those non-default hosts requires --allow-non-default-host.

Device label handling

When the CLI exchanges the approved device flow for a sk_user_* personal/device key, it derives a device label from your local username and hostname. Spinup normalizes that label to a safe printable form before sending it to the API and before storing it in key metadata or audit records.

Browser fallback

If the CLI cannot open a browser automatically, copy the printed URL into your browser manually and continue the flow there.

Multi-workspace behavior

If your user can see exactly one workspace, spinup login stores it as the default automatically.

If your user can see multiple workspaces, login stores the personal/device key but leaves workspace selection explicit. Use:

spinup workspaces list
spinup workspaces use <workspace-slug>

For a one-off override, set SPINUP_WORKSPACE on the command you are running.