Script Versions

Devpilot keeps a full history of every script. Each time you save a change, the previous content is tucked away as a new entry in the Versions tab with a version number, an optional note, and the user who made the edit. You can browse any earlier version, compare it against what's live today, and restore it with one click — and because restoring also saves a new version, you can always undo.

What Each Version Captures

Every version records the version number (a counter that goes up by one each time, starting from 1), the full script body as it was before your last edit, an optional change summary (on automatic saves this defaults to the script's name, and on restores it reads "Before restoring to vN" so you know why it's there), the user who triggered the save, and the timestamp.

Versions are tied to the script itself, so deleting a script also clears its history.

How Versions Are Created

Devpilot creates a new version entry before it applies your update — the entry holds the previous content, not the new one. In plain terms:

1. You save an edit to a script.
2. If the body actually changed, Devpilot tucks the old body into a new version with the next available version number.
3. The live script is then updated to the new content.

That means the highest-numbered version represents "what the script was before my most recent save," while the live script shows the most recent save. If you only tweaked non-body fields like the name or description, no version is created — history only tracks real body changes.

Browsing Versions

Restoring a Previous Version

Example History

Imagine a script that's seen a few edits and a restore:

v4  Before restoring to v2   today       you
v3  Add error handling       yesterday   teammate
v2  Switch to sudo           last week   you
v1  Initial import           last month  you

If v3 introduced a bug, clicking Restore on v2 creates v4 (holding the bad v3 content) and overwrites the live script back to v2's body. You keep the full chain, including the broken version, so you can diff and fix it forward later.

Auditing and Accountability

Every version record is tied to the user who made the change. For sensitive scripts — production deploy recipes, credential rotations, database migrations — this gives you a clean audit trail:

• Who last edited the script, and when?
• What did the script look like on the day a specific run happened?
• Which edit introduced a regression? Diff two versions to find it.

Pair versions with Script Secrets and you get a secure, reviewable scripting workflow where credentials never appear in history and every edit is attributed.

Limits and Constraints

• The Versions tab shows the 50 most recent versions. Older versions are still retained and can be opened directly from their link.
• Only the script body is versioned. The associated name, description, tags, category, schedule, run-as user, attached secrets, webhooks, and triggers are configuration around the script — not part of the content snapshot.
• A new version is only created when the script body actually changes. Saves that only tweak non-body fields don't produce a version.
• Versions can't be deleted individually — they live as long as the script does.

Troubleshooting

Next Steps