Skip to main content
Move an existing cloud installation to a newer PRFlow release, and keep the settings you changed. The installer is review-first on an update: it previews by default, and it never silently overwrites a file you edited.

​
Update in Three Steps

The examples below pin a specific release tag. Replace it with the tag you are moving to, from the releases page.
Download the installer again at the new tag — do not re-run a saved copy. Each release ships its own install.sh logic, so re-running an older installer against a newer release applies stale install steps to the new files. Before it writes anything, the installer compares its own bytes against the fetched release’s install.sh (line-ending differences ignored) and, in apply mode, stops before touching your repository and prints the command that downloads the matching installer. A dry run prints the same warning and still shows the plan. Set DEVFLOW_ALLOW_INSTALLER_DRIFT=1 to install with the mismatched copy anyway. A curl … | bash run, or a release that ships no install.sh, cannot compare and prints one line noting the self-check was skipped, then continues. If a stale installer copy (install.sh, devflow-install.sh, or prflow-install.sh) sits committed at your repository root, /prflow:init and the installer’s scaffolding step also warn about it and name the download command.
1

Preview the Update

Download the newer installer and pass the same new tag as the payload.
On an existing installation this runs in dry-run mode. It does not intentionally change your repository, though it can create temporary files, and it does execute the script you downloaded. Read that file before you run it.
2

Apply It

This refreshes the managed workflows, the composite actions and the configuration schema. It backfills newly added configuration keys and preserves the values and arrays you already set.
3

Review Before Committing

Look for two things: changes under .github/ that you accept, and any file ending in .prflow-new. The next section explains those.

​
Resolve Preserved Files

The installer records a digest for each file it manages, in .prflow/install-manifest.json. On an update it decides file by file: Whenever it preserves your version, it writes the proposed replacement beside it as <path>.prflow-new.
1

Compare Each Sidecar

An empty list from the first command means nothing was preserved and there is nothing to merge.
2

Merge What You Need by Hand

Copy the changes you want into the file you maintain.
3

Delete the Sidecar

Remove each .prflow-new file once you have merged it. Sidecars are ignored by Git, so a broad git add -A will not commit them by accident.
4

Re-run the Installer in Apply Mode

Merging or adopting a sidecar changes the file’s bytes, so the digest the installer recorded is now stale. When the preserved file is one the cloud implement gate depends on — .github/workflows/devflow-implement.yml, the setup-project-env action, or .prflow/lint-manifest.json — re-run the installer in apply mode (--apply, or DEVFLOW_APPLY=1 for a curl | bash invocation) afterwards. Only that re-apply rebinds the .prflow/install-state.json marker to your merged bytes; skip it and the implement run refuses to start on every run. The apply that preserved the file warned you and named each affected sidecar.
If Python cannot run, the installer cannot compare managed files or write the provenance manifest. It preserves every existing artifact and writes sidecars instead of risking your work. That is safe but it means nothing was updated in place. Fix Python, then run the same update again.

​
Keep the Workflow and the Version Pin Together

In a thin install, prflow_version in .prflow/config.json decides which plugin the installed workflows fetch at run time. The installer re-stamps an empty or SHA-shaped value to the commit it installed, and preserves a value you set by hand, such as a tag or a branch name.
Updating only the workflow files, or only prflow_version, can leave two halves of one feature out of sync. Run the installer with the new tag and review the resulting pin in the same change.
A current example makes the risk concrete. The skills that read .prflow/skill-extensions/ ship inside the plugin, while the permission entries their delivery needs ship in the workflow files. Raising only prflow_version leaves that delivery unpermitted, and a refused delivery is not reported as a failure. The run looks normal and quietly applies less of your configuration.
In a vendored install, prflow_version is ignored. The committed .prflow/vendor/prflow/ tree supplies the runtime, so update that tree instead. An apply run that finds a git-tracked .prflow/vendor/prflow/ treats the repository as vendor mode automatically: it replaces the committed tree with the fetched release’s plugin files, keeps /vendor/ out of .prflow/.gitignore, and logs how to switch to a thin install — so CI stops running the old plugin after an upgrade.

​
After the Update

Run /prflow:init locally in the repository. It backfills newly added settings into .prflow/config.json without replacing the values you set, and refreshes prompt-extension .md.example files whose content is out of date (never creating one beside a live <skill>.md). Then try one low-stakes command, such as /prflow:review on a throwaway pull request, before you rely on the automation again. If something stops working after an update, see Cloud-Run Problems and Cloud Recovery.