Latest Results
Add `replaces` field for renaming deployments in place
Renaming a deployment in `prefect.yaml` currently creates a second
deployment under the new name and leaves the original behind, splitting
run history across two records and letting users trigger the stale one.
Adds an optional `replaces` field to deployment definitions naming the
existing deployment to rename. When set, the server updates that
deployment row in place rather than upserting a new one, so the
deployment ID — and every flow run, schedule, and concurrency limit
attached to it — is preserved.
Behavior:
- `replaces` naming a deployment that exists: renamed in place
- `replaces` naming one that does not exist: created normally, warning logged
- `replaces` set while both old and new names exist: actionable error,
since renaming would violate the (flow_id, name) unique constraint
- Re-applying after a successful rename is a no-op, so `replaces` can be
left in the YAML
Revives #21685 by @vyagubov, which implemented the approach @desertaxle
proposed in #20850 and was auto-closed by the stale bot after review
feedback had been addressed. Rebased onto main and additionally
regenerates `schemas/prefect.yaml.schema.json`, which the original PR
left stale — without it, editors validating `prefect.yaml` flag
`replaces` as an unknown key.
Closes #20850
Co-authored-by: Vugar Yagubov <vy@vugaryagubov.com>praneethb7:deployment-replaces-20850 Latest Branches
+16%
praneethb7:deployment-replaces-20850 0%
uinstinct:sqlite-busy-snapshot 0%
© 2026 CodSpeed Technology