Skip to content
Thyme Docs

Release Management

A function release is immutable. Uploading new code creates another release; it never silently replaces what a scheduled executable runs.

Publish a version

thyme upload update-value --tag v2

Use a new tag for changed code, schema, callbacks, or permissions. Tags are reserved permanently within the function family, including after deprecation/deletion. Retrying the same active tag with the same archive checksum reuses it.

Review the new release's schema and permission manifest. An address arg or additional selector can require an owner-approved profile scope change before the release can be bound.

Switch an executable

  1. Pause the executable and review any in-flight runs.
  2. Select an active release in the same project.
  3. Supply the intended args for the new schema, including unchanged values you want to retain.
  4. Wait for the replacement sandbox to finish building.
  5. Confirm the function ID, args, and absence of a switch error.
  6. Activate deliberately and inspect the next execution.

The build is staged: the existing function and sandbox remain committed until the replacement succeeds. A failed build leaves the old code available. A successful switch leaves the executable paused. During the build, conflicting switches, args edits, activation, and regeneration are blocked.

The API entry point is PATCH /api/v1/executables/{id}/function with functionId and the intended args. An accepted response is 202, not proof that the switch finished. Poll until pendingFunctionSwitch clears; see management operations and API reference.

Roll back

Pause and switch back to an older active release using compatible args. This uses the same staged rebuild. Persistent executable storage is not automatically rolled back with code, so maintain backward-compatible state or perform a reviewed state migration.

Execution history keeps the release ID that actually ran, enabling comparison before and after the change.

Retire a release

The console's deprecation action is one-way and asks for the exact function/version label. It prevents new executable bindings, version switches to that release, and copying it as active code. Move dependent executables to an active release first: current execution and webhook guards require an active function, so deprecating a still-used release can prevent later invocations.

Deprecation is different from deletion. Move or retire dependent executables before deleting code they use. Keep a rollback candidate active until it is no longer needed.

Copying a release to another project creates a separate destination function. It does not copy executable secrets, state, profiles, or schedules.