Accounts & claiming

Anonymous deploys expire after 14 days. Deploys made through an authenticated account are owned and have no expiry.

Connect the CLICopy Anchor Link

flypod login

The command prints a short confirmation code and opens flypod in your browser. Sign in, verify that the displayed code matches, and approve the device. The CLI stores the resulting session in your user config directory, outside the repo.

Every later deploy from that CLI is attributed to the account:

flypod ./dist

List the sites on your account (always JSON on stdout):

flypod list

Log out by deleting only the local CLI session:

flypod logout

flypod logout removes the session file on this machine; it does not sign out other machines or a CI secret holding a session token.

Keep sites you already deployedCopy Anchor Link

Login automatically attaches anonymous sites this CLI remembers on the same host. Each local folder link already contains the site's manage_token, so the CLI can prove control without asking you to copy a secret:

$ flypod login
  ✓ Logged in
  ✓ Attached 3 sites · no expiry now, same URLs

This is the whole ownership story: temporary → flypod login → yours. It claims every anonymous site the machine remembers, not just the last one, and you never handle a token to do it. Claiming also clears the local 14-day expiry, so the folder link survives and flypod update keeps working.

Deleted, expired, and already-owned sites are skipped. Sites deployed from a different machine, or against a different server (DEPLOY_URL), are not attached. With --json, login reports {"ok":true,"logged_in":true,"attached":[…],"skipped":[…]}.

Claim a site from another machineCopy Anchor Link

The fallback, when the machine that deployed the site isn't the machine you're on. It needs that deploy's claim_token, which only --json --verbose output contains:

flypod login
flypod claim <site_id> <claim_token>

flypod claim needs a signed-in CLI (not_signed_in otherwise). If the site already belongs to a different account, this fails with already_claimed (HTTP 409) rather than transferring it.

Agents and CICopy Anchor Link

Agents running on a connected machine automatically use its saved session. A stateless job can receive an existing session token through its secret store:

# FLYPOD_TOKEN is read straight from the environment, so a job that sets it
# from its secret store needs no extra step.
flypod ./dist --json

There are no separate API keys. FLYPOD_TOKEN is an ordinary login session (the session_token that flypod login writes to session.json), and there is no dashboard button that mints a long-lived one. It acts as your whole account, so treat it like a password.

The CLI picks one credential, in this order: --token (on the commands that take it), the folder's stored manage_token for an anonymous site, FLYPOD_TOKEN, the session saved by flypod login, then the legacy FLYPOD_API_KEY. A credential that is sent but not accepted fails with token_rejected (exit code 3); nothing silently falls back to an anonymous deploy. To deploy anonymously, unset the variable.

flypod login --token <session_token> saves a session you already hold, after checking it with the server; a rejected token is not saved.

Where local state livesCopy Anchor Link

session.json and the folder-to-site registry projects.json live in the platform-specific flypod config directory with mode 0600. Override the directory with FLYPOD_CONFIG_DIR. Neither file belongs in your repo.