Accounts & claiming
Connect the CLI through browser device authorization, make deploys permanent, and attach an existing anonymous site.
Anonymous deploys expire after 14 days. Deploys made through an authenticated account are owned and have no expiry.
Connect the CLI
flypod loginThe 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 ./distLog out by deleting only the local CLI session:
flypod logoutKeep sites you already deployed
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.
Found 3 anonymous sites on this machine.
Attaching to your account…
Attached 3 sites.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 are not in this CLI's registry.
Claim a site from another machine
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 output ever
contained:
flypod login
flypod claim <site_id> <claim_token>If the site already belongs to a different account, this fails with 409 rather
than transferring it.
Prefer running flypod login on the machine that made the deploy — it needs no
token at all. Don't design an agent or CI workflow around stashing a
claim_token for later; authenticate the job with FLYPOD_TOKEN instead and
its deploys are owned from the start.
Agents and CI
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 --jsonTreat the value as an account credential. The legacy FLYPOD_API_KEY variable
is still read for compatibility, but new integrations should use
FLYPOD_TOKEN.
Where local state lives
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.
Render Markdown to a docs site
Deploy a folder of Markdown files with no index.html and flypod renders them into a styled docs site with a sidebar and home page.
How to deploy a static site from an AI agent
Run npx flypod ./dist from any coding agent to get a live URL back on stdout, with no account and no config. Covers the one-line deploy, teaching the agent to do it unprompted, and making the URL permanent.