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.
• flypod update with no changes reports No changes and does nothing.

flypod update
# No changes (already live)

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 the content already exists, per above).

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.