Versioning

Every deploy produces a version: an immutable snapshot of the site's content. A site has one live pointer that selects which version it serves. Deploying, updating, and rolling back are all just operations on versions and that pointer.

Content-hashed version ids

A version_id is the first 16 hex characters of the SHA-256 hash of the deploy's content. The id is derived entirely from what you uploaded, which makes deploys idempotent:

• Identical content always produces the identical version id.
• A redeploy of unchanged content stores no duplicate. The existing version is reused, no files are re-stored, and flypod versions does not grow.
• flypod update still uploads and still reports the version as live. There is no "nothing changed" message — the deduplication happens server-side, on the hash, and is invisible from the command line.

This makes flypod update safe to call on every iteration of a loop: a run that changes nothing costs an upload and produces no new version.

Versions are immutable

Once stored, a version never changes. There is no "edit a version"; you only ever create new ones. Every deploy and every update creates a version, unless a version with that content hash already exists — in which case that version is reused.

The live pointer

A site serves exactly one version at a time: the one its live pointer references. The serve plane reads this pointer to pick which files to return, and embeds the live version id in the ETag.

Two commands move the pointer:

Update vs rollback

flypod update ships forward: it deploys the current folder as a new version (or reuses an existing one) and points the site at it.

flypod rollback moves the live pointer back to an earlier version. Nothing is deleted. The versions you rolled past still exist, so you can roll forward again at any time. List the full history, newest first, with flypod versions.