docs

Other commands

div login

Sign in to the div CLI via your browser to deploy from any folder or machine.

div login

Pairs the CLI on this machine with your div.so account, so you can deploy updates from any folder — not just the one you ran div deploy from originally.

#Synopsis

div login

No flags. The whole flow happens through your browser.

#What it does

  1. The CLI starts a tiny local HTTP server on a free port (e.g. http://localhost:53241/callback).
  2. It opens your default browser to a consent page on div.so. If you're not signed in, Fortify catches you and bounces you through the normal login flow first (including 2FA if you have it on).
  3. The consent page shows your account, what the CLI will be able to do, and the exact local URL that'll receive the token. Click Approve and sign in.
  4. div.so mints a personal access token scoped to cli:deploy and redirects your browser to the local URL with the token attached.
  5. The CLI captures the token, verifies a random state value to confirm it's the same request you initiated, looks up the email it belongs to, and saves everything to auth.json on this machine.
  6. The browser shows a "you can close this tab" page. The CLI prints ✓ Signed in as you@example.com.

Every subsequent div deploy from any folder on this machine sends the saved token as Authorization: Bearer *** — no email prompt, no verification round trip.

#When you need it

  • You've already verified a project and want to push updates from the CLI again (the original claim token is dead after verification — see Authentication).
  • You're on a fresh machine and want to manage existing projects.
  • A div projects or div deploy failed with "Your session has expired" and you want to get back in.

#Example

div login
# Opening browser to sign you in…
#    https://div.so/cli/authorize?state=...&callback=http://localhost:53241/callback
#    (Waiting up to 5 minutes — Ctrl+C to cancel)
# ✓ Signed in as you@example.com.

#What can go wrong

  • No browser opens. Some environments (SSH sessions, headless containers, missing GUI) can't launch a browser. The CLI prints the URL — open it manually on any machine that can reach div.so, copy-paste, finish the flow there. The token still flows back to the localhost server you started on this machine, so the browser needs network access to http://localhost:<port> on this host.
  • State mismatch error. Means the callback the local server received came from a different consent screen than the one this CLI just initiated. Usually caused by an old browser tab finishing late. Re-run div login and only use the tab that just opened.
  • Timed out waiting for browser approval. You took longer than 5 minutes to approve. Re-run and try again.
  • Couldn't look up account. The token was issued but the follow-up /api/cli/me call failed (network blip, server hiccup). Re-run div login.

#Security model

A few belt-and-suspenders defaults:

  • Callback URL is whitelisted server-side. Only http://localhost or http://127.0.0.1 with the /callback path on any port. A malicious link can't redirect your fresh token to an attacker's server.
  • State round-trips. The CLI generates a random 128-bit state and verifies the callback returns the same value. Defends against CSRF-style swaps where someone tricks you into approving a request they initiated.
  • Scope-limited token. The PAT carries only the cli:deploy ability — it can't be used for unrelated parts of the API.
  • Local file is 0600. auth.json is created with owner-only read/write permissions.

#See also