drift account

Your identity against the platform, a different thing from the auth your own app uses. Authentication keeps the three apart.

Creating an account

Signup is two steps. create posts your details, the platform emails an 8-digit code, and you type it back to finish. Under invite-only mode the invite code takes the place of that email check, so the CLI skips the prompt and says so.

$ drift account create --invite-code DRIFT-XXXX
Username: alice
Email: alice@example.com
Password: ********

Sending verification code...
Invite-only alpha: skipping email verification (your invite code is the gate).

An invite is minted for one email address, so a code that reached you by another route won't sign you up as someone else. For CI, pass --username, --email, and --password-stdin. Once you're logged in the CLI keeps your session and refreshes it for you; you won't be asked again on this machine.

Working as more than one account

Logging in a second time adds a profile rather than replacing the first: drift account login as a different user files a new profile beside the old one, and either name works with drift account use afterward. Each profile keeps its own active slice, which is the reason profiles exist at all. With one shared slice, logging in as a second account left the first account's slice selected, pointing at a slice the new account might not even own.

To act as another account for one command without switching, set DRIFT_ACCOUNT instead:

DRIFT_ACCOUNT=other drift slice list

A member (see below) is filed under their own name rather than the account they work on: drift account use erica switches to the account Erica was invited onto. If you're a member of someone else's account, whoami prints their username, the account your commands act on, and notes your own name on stderr, so a command substitution still captures just the one word.

Second factor

A second factor means a stolen password is not a stolen account. Drift uses TOTP, the six-digit codes any authenticator app produces.

Enrolling prints ten single-use recovery codes for the day the phone is gone. They're shown once, and never stored by the CLI. Once enabled, drift account login asks for a code interactively, or takes one non-interactively with --mfa-code, or --recovery-code for a device you no longer have.

Access tokens

A token carries a subset of what your session can do and is revoked on its own, so a CI pipeline can deploy without also being able to read your secrets or delete your account. Use one by putting it in the environment: no login, and nothing written to disk.

export DRIFT_TOKEN=drift_pat_...
export DRIFT_SLICE=my-slice
drift file apply

--scope is repeatable, and at least one is required: slice:read, slice:write, secret:read, secret:write, account:read. Grant the narrowest set that does the job; a deploy pipeline usually wants slice:read and slice:write and nothing else, since it does not need to read secrets to ship a function that uses them.

Members

A member is a second person on your account. They log in as themselves and work on your slices: deploy, roll back, create and delete slices, read and write Backbone. They cannot read or change your secrets, read your audit trail, change your second factor, mint an access token, invite anyone else, or delete the account. For a CI pipeline or a script, use drift account token instead; a member is a person, and the audit trail is written on that assumption.

Removing a member does not delete their account. Their login, password, and second factor stay theirs; they simply stop having access to yours, within about fifteen minutes.

Auditing and exporting

The audit trail is hash-chained, kept for two years, and survives account deletion by design; the record that an account existed is exactly what must outlive it. --event filters to one type (login, secret.read, atomic.deploy, and so on), and --since/--until take 7d, 24h, or a bare date.

export reads nothing you couldn't already read yourself: it walks the same endpoints drift backbone nosql list, drift backbone blob get, and drift deed vault list call, with your own credentials. Secret values are excluded unless you pass --include-secret-values and confirm; a leaked archive shouldn't be the same thing as a leaked credential store.

The session on disk

Your login lives in ~/.drift/session.json (mode 0600, inside a 0700 directory), bound to a per-machine device_id beside it. The file holds one profile per logged-in account, each with its own active slice, plus a note of which profile is current; drift account use and DRIFT_ACCOUNT are two ways to change or override that. Every authenticated request carries:

• Authorization: Bearer <jwt>, your identity
• X-Slice: <active-slice>, the target slice

Tokens refresh automatically on a 401 that means the session expired; if the refresh fails you're prompted to log in again. Authentication has the token pair's lifetimes and what happens when a spent refresh token is replayed.