Versioning

A version is a snapshot of all your tasks at a specific point in time.

Version Identifiers

Format: YYYYMMDD.N — date in reverse + version number per environment per day.

• 20240313.1 — March 13, 2024, first deploy
• 20240313.2 — March 13, 2024, second deploy
• 20240314.1 — March 14, 2024, first deploy

Version Locking

When a run starts executing, it is locked to the version of code for that environment at that moment. Deploying new versions won't affect in-progress runs.

Delayed runs

Delayed runs are locked to the version when they begin executing, not when they were enqueued.

Child Task Version Locking

Whether child tasks inherit the parent's version depends on the trigger function used:

Trigger function	Child version	Locked to parent?
trigger()	Latest	No
batchTrigger()	Latest	No
triggerAndWait()	Same as parent	Yes
batchTriggerAndWait()	Same as parent	Yes

Local Development

Every relevant code change during npx trigger.dev dev automatically creates a new version. Each run continues on the version it was locked to via spawned processes.

Deployments

Every npx trigger.dev deploy creates a new version for the target environment.

Retries

Retries are locked to the original version of the run — they use the same code that started the run.

Replays

A replay creates a new run with:

• Same input payload
• Latest version of the code

Useful after fixing a bug — replay failed runs to re-execute with the fix.

See Runs for replay API.