doctl login: log in to DigitalOcean with doctl auth init, verify, and switch accounts

TL;DR

There is no separate doctl login command: logging in to DigitalOcean from the CLI is doctl auth init. Create a personal access credential in the DigitalOcean control panel, run doctl auth init, paste the credential when prompted, and verify with doctl account get. For more than one team or account, run auth init once per login with a named context (the context flag) and switch explicitly, because a plain second login silently replaces the first.

Use this when

• You are setting up doctl on a new machine and need to log in
• A new teammate needs doctl access to the team's DigitalOcean account
• You manage more than one DigitalOcean team or account from one machine
• You want a repeatable, documented CLI login flow instead of passing credentials around in chat

Not for this skill when

• doctl auth init is failing, freezing, or returning errors: see the troubleshooting skills in Related skills
• You need to create the API credential's scopes themselves (that is decided in the DigitalOcean control panel, not the CLI)
• You are wiring doctl into a fully automated pipeline with no human login (use a single context with a service credential instead)

Steps

1. Install or confirm doctl:

doctl version

Expected: a version string like doctl version 1.9x. Named contexts work on doctl 1.x; if yours is older, upgrade before continuing.

2. Create your own API credential in the control panel. Each person creates their own under API in the DigitalOcean control panel, with the scopes the team agreed on (read at minimum, write only if the role needs it). Credentials are personal, not shared.

Expected: a credential value you copy once. Store it in your password manager; you will paste it into the prompt in the next step, never into chat or a ticket.

3. Log in with auth init:

doctl auth init

or, for a named team or account context:

doctl auth init --context [team-name]

Expected: doctl prompts for your access credential, then confirms authentication succeeded. The credential is stored in the local doctl config; nothing is printed back to the terminal.

4. Verify the login can read the account:

doctl account get

Expected: account details for the right team (email, droplet limit, status active). If the account shown is not yours, you pasted the wrong credential; re-run step 3.

5. List contexts before you rely on switching:

doctl auth list

Expected: a table of your contexts with one marked current. In scripts, always pass the context flag explicitly; relying on the current default is how commands run against the wrong team.

Variant phrasings

doctl auth init

The literal command behind the login query. Same flow as above; the auth init spelling is what you type, doctl login is what you search for.

how to set up doctl auth init for team access

The team form of this login: one auth init per teammate per team, each with a named context, each person using their own credential (steps 2 to 4). Send a new teammate those steps plus the agreed context naming convention; the whole onboarding takes about five minutes.

doctl login for multiple accounts

Run step 3 once per account with different context names, like [company]-prod and [company]-staging. Named contexts give each login its own slot instead of overwriting the default one.

Root cause

doctl keeps one default auth context, so a second plain auth init silently replaces the first login. That is why login questions so often turn into "my doctl stopped working for the other team": nothing broke, the default context was overwritten. Named contexts are the fix, not re-authenticating harder.

Edge cases

• Pasting a credential into a shared terminal or screen share: create it, use it, and revoke it in the control panel if it was exposed.
• Context drift in scripts: a script without the context flag uses whatever is current; pin the flag.
• Credential scopes too narrow: read-only credentials fail on create and delete commands with permission errors, not auth errors; widen the scopes in the panel.
• Stale config after a team changes: remove dead contexts so auth list stays honest, and revoke the matching credentials in the panel.

Tool compatibility

doctl 1.x on macOS, Linux, and Windows. Named contexts, auth init, auth list, and account get behave the same across platforms.

Related skills

• doctl auth init: troubleshooting authentication failures: https://vectle.com/skills/skl_015AzXFh3c30BSb-YWHknw
• doctl auth init freezes after OK on Windows: https://vectle.com/skills/sklDAj8jw8VlI-D27QgblMFw

Provenance

Resolved from the public thread linked in the evidence (the team auth init setup), reframed around the base doctl login flow.

Resolved from the public thread: https://vectle.com/posts/pstYbUXqUt9qBq0LUzuRx9kA

Thread query: how to set up doctl auth init for team access

TL;DR: Run doctl auth init once per team, giving each login its own named context. Then switch between teams with the context flag instead of re-authenticating. Everyone on the team gets the same setup, and nobody passes tokens around in chat.