flypod update

flypod update ships a new version to the site linked to the current folder, or to an explicit --site. The new version becomes live immediately.

Plain flypod in a folder that already has a site does the same thing, with the same receipt; flypod update is the explicit spelling, and the one that also takes --site and --token. To make a separate site from a linked folder, run flypod --new.

SynopsisCopy Anchor Link

flypod update [path] [flags]

With no path, update deploys the folder the site was last deployed from; when that folder is gone, it follows the same auto-detection rules as flypod [path]. flypod resolves the target site from the folder-to-site link saved on the last deploy, or from --site.

A version id is derived from the content hash of the files, so re-running flypod update with byte-identical content returns the same version id and adds no new version — nothing is re-stored. If that content matches an older version, that version becomes live again. The upload still happens and the CLI still reports the version as live; there is no special "nothing changed" message.

FlagsCopy Anchor Link

ExamplesCopy Anchor Link

Ship a new version to the linked site:

flypod update ./dist

  ✓ Updated · version 8f1a0c2e is live

  https://a3f1c2d4e5b60789.flypod.page

  undo      flypod rollback  puts the previous version back
  expires   19 Oct 2026      in 14 days
  keep it   flypod login     free · removes the expiry

On a site that is yours the expires row is absent. When stdout is not a terminal, the URL alone is printed there, so URL=$(flypod update) works. If something was left out of the upload (see what is uploaded), a notice lists it first.

Machine-readable output:

flypod update ./dist --json

{
  "ok": true,
  "action": "updated",
  "site_id": "a3f1c2d4e5b60789",
  "version_id": "8f1a0c2e44b7d913",
  "url": "https://a3f1c2d4e5b60789.flypod.page",
  "healed": [],
  "warnings": [],
  "expires_at": 1782929906088,
  "next": {
    "update": "flypod update",
    "versions": "flypod versions",
    "rollback": "flypod rollback",
    "keep": "flypod login --json"
  }
}

action is always "updated" here (a first deploy says "created"), so a caller that ran plain flypod can tell which happened. As on a first deploy, skipped appears when something was left out, and timeline / history_url when --timeline or --no-timeline was passed.

Target a specific site with a manage token — for an anonymous site on a machine that doesn't remember it. Get the token with flypod token on the machine that does:

flypod update ./dist --site a3f1c2d4e5b60789 --token fk_...

If the site is yours, flypod login on the second machine is the better path: a session can be replaced, a manage_token cannot.

NotesCopy Anchor Link

• warnings works as it does on a first deploy: check it before treating the new version as good. In a terminal a warning is shown between the URL and the next steps.
• No link and no --site fails with no_site before anything is read or uploaded. Its reason says whether the folder was never linked, its site expired, the site is gone, or a folder above or below this one is the linked one.
• A 401 or 403 response fails with unauthorized, and the fix depends on what this machine sent: the folder's stored token, an account, or nothing. When the site refuses the folder's stored token and you are signed in, flypod retries once as your account; if that works, the site was kept by your account and the link is updated to match.
• A 404 fails with site_gone: the linked site no longer exists. flypod drops the stale link and tells you to run flypod to create a fresh deploy. Plain flypod in that folder does not fail: it drops the link and creates a new site.
• When plain flypod ran the update and it was refused, the fix ends with To make a separate new site from this folder instead, run `flypod --new`.
• Credentials: --token wins, then the manage_token this machine stored for the site, then your session or FLYPOD_TOKEN. See credential precedence.
• Use flypod versions to inspect history and flypod rollback to revert.