flitz login / logout

Sign in once per machine. Every command that needs a credential — downloading an SDK, reading the loader-plugin credentials, publishing, listing publishes, tracks, and apps — uses the stored sign-in from then on. CI jobs do not sign in; they set FLITZ_APIKEY instead.

login

flitz login

login prints a link and a short code, opens the link in your browser when it can (open on macOS, xdg-open on Linux), and waits:

Sign in to Flitz from a browser:

  Open  https://…
  Code  ABCD-EFGH

⠋ Waiting for approval 4.2s

Approve the sign-in in a browser on any device — it does not have to be the machine running the CLI. When the approval arrives, the CLI stores the credential and finishes:

✓ Waiting for approval 12.3s
✓ Signed in to Flitz.

Sign in with the account your organization invited — the same account you use for the Flitz portal.

Signing in does not itself check your organization's license. Each licensed command checks it as part of its own request, so you are never told the same thing twice. An inactive license shows up as your organization's Flitz license is not active with a hint to ask your organization's Owner to open Billing in the portal — run flitz status to see the license row directly.

When sign-in fails

The first four are exit 3; the last two are exit 4.

logout

flitz logout

Deletes the stored credential from this machine and prints Logged out. (or Not logged in. when there was nothing to delete). Exits 0 either way. It affects this machine only: your portal session and your sign-ins on other machines are separate.

Where credentials are stored

The sign-in credential lives outside any project repository:

~/.config/flitz/credentials.json     (or $XDG_CONFIG_HOME/flitz/credentials.json)

It is written atomically at mode 0600, never committed, never printed, and redacted from every diagnostic, including -v output and the bug-report capture. It holds your refresh credential plus the current short-lived access token and its expiry. The CLI reuses that token until it is about to expire, then refreshes it and rewrites the file — so any licensed command can update the file, not only login.

When that refresh is rejected — the session was revoked, expired, or ended by an administrator — the CLI reports your Flitz session has ended with the flitz login hint (exit 3), never a stack trace.

FLITZ_APIKEY takes precedence

When FLITZ_APIKEY is set and non-empty, the whole CLI authenticates with it and never reads the stored credential. flitz login is not needed and the ambient update notice is suppressed. See flitz apikey.

Access and revocation

• Granting access. Your organization's Owner or an Admin invites you by email from the Members page of the Flitz portal. Accept the invitation, then run flitz login with that account.
• Revoking. Removing a member in the portal, rotating or revoking the API key, or a lapsed license takes effect within minutes: no new SDK downloads, plugin credentials, publishes, or reads of the publish history, tracks, and apps. The license follows the Owner's subscription, which the Owner manages on the portal's Billing page.
• What stays. Links you already published keep working, and so does everything already on disk: a cached SDK's flutter and dart run without the network. Anything that talks to the Flitz service — including re-running flitz sdk use for a cached tag — needs a working credential and an active license. See Troubleshooting → Offline behavior.