Skip to main content
Every successful telnyx-edge ship produces an immutable revision. telnyx-edge revisions list shows a function’s deploy history; telnyx-edge rollback retargets traffic to a previous revision without rebuilding or re-uploading anything.

​
Listing revisions

Prints the most recent revisions, newest first: the revision ID, when it was shipped, who shipped it, and its deploy status. The revision currently serving traffic is marked with *. Revision IDs are short identifiers like a1b2c3d — you pass one to rollback.

​
Rolling back

Traffic is instantly retargeted to the existing, immutable revision across all clusters — there is no rebuild and no re-upload. Two constraints:
  • The target must have reached deploy_ok. A revision whose build or deploy failed never served traffic and can’t be rolled back to; revisions list shows each revision’s deploy status.
  • Rollback doesn’t touch your source. Your working tree and git history are unchanged. The next ship deploys whatever is on disk — as a new revision — regardless of which revision is currently active.

​
Rolling forward

To move forward again, either ship — every successful ship creates a new revision and moves traffic to it — or rollback to any other revision that reached deploy_ok.

​
Recovering a failed function

Rollback assumes the function has a healthy revision to return to. A function stuck in a terminal failure state (build_failed, deploy_failed, delete_failed) can instead be reset:
This tears down the function’s deployed resources and returns it to the created state — preserving its ID, name, and config — so you can fix the code and ship again. A healthy function (build_ok/deploy_ok) can’t be reset; use delete-func if you want it gone.

​
Next Steps

  • CI/CD — ship from a pipeline; rollback is your escape hatch
  • Routes & Domains — the function URL always points at the active revision
  • CLI reference — ship, revisions, rollback, and reset-func in full