> For the complete documentation index, see [llms.txt](https://docs.flxbl.io/flxbl/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://docs.flxbl.io/flxbl/sfp/getting-started/docker-images/sfp-pro/upgrading-v50-to-v51.md).

# Upgrading the CLI from v50 to v51

v51 is the release where sfp gains a server: from v51 the CLI runs against [sfp server](https://docs.flxbl.io/sfp-server) and is no longer standalone. If your pipeline runs sfp itself — a `container: image: …/sfp-pro:…` job in GitHub Actions, Azure Pipelines, Buildkite, or any CI — this page covers the mechanical upgrade: the image, the moved commands, and the reworked review-environment calls.

Moving those workflows onto codev entirely — so the server runs them and there is no image or command for you to maintain — is a separate, gradual path; see [Migrating to codev](https://docs.flxbl.io/codev/migrating-to-codev). The steps below apply to any sfp calls you still run yourself during or after that move.

## Step 1 — Update the image

Point the version tag your pipeline pulls at a v51 release.

```yaml
# Before (v50)
container:
  image: source.flxbl.io/flxbl/sfp-pro:50.x

# After (v51)
container:
  image: source.flxbl.io/flxbl/sfp-pro:51.x
```

If you mirror the image into your own registry, sync the v51 tag first — see [Automated Image Synchronization to Your Registry](/flxbl/sfp/getting-started/docker-images/sfp-pro/migrating-to-sfp-pro.md). Valid version tags are listed at <https://source.flxbl.io/flxbl/-/packages/container/sfp-pro/>.

What comes with the new image:

| Component                 | v50                         | v51                                      |
| ------------------------- | --------------------------- | ---------------------------------------- |
| Base OS                   | Debian bookworm             | Debian trixie                            |
| Salesforce CLI            | 2.131.7                     | 2.135.7                                  |
| JDK                       | 17                          | 21                                       |
| Data-move runtime (sfdmu) | installed as an `sf` plugin | bundled in the image, invoked in-process |

You no longer install sfdmu yourself. On v50 the image ran `sf plugins:install sfdmu`; on v51 the data-move runtime ships inside the image and sfp calls it directly — remove any `sf plugins:install sfdmu` step from custom images. If you extend the `sfp-pro` base image with your own `apt-get install` layer, note that the trixie transition renames some system packages (the `t64` suffix, e.g. `libasound2` → `libasound2t64`).

## Step 2 — Rename the moved commands

Most v50 commands run unchanged on v51. Commands that moved under a parent topic keep a backward-compatible alias, so existing invocations still resolve. The one exception is `releasedefinition:generate`: it moved under `sfp server` with no alias, so update it wherever your pipeline calls it.

```bash
# Before (v50)
sfp releasedefinition:generate -c HEAD -d release-definitions -f release-configs/my-release.yml -n $RELEASE_NAME -b $RELEASE_BRANCH

# After (v51)
sfp server releasedefinition generate -c HEAD -d release-definitions -f release-configs/my-release.yml -n $RELEASE_NAME -b $RELEASE_BRANCH
```

**Moved but still work via aliases** (update at your own pace):

| v50                                  | v51 canonical                                           | Old form still works?     |
| ------------------------------------ | ------------------------------------------------------- | ------------------------- |
| `sfp dependency install`             | `sfp org dependency install`                            | Yes (alias)               |
| `sfp pool prepare`                   | `sfp server pool scratch init`                          | Yes (alias)               |
| `sfp reviewenv fetch` / `transition` | `sfp server review-envs assign` / `acquire` / `release` | No — reworked, see Step 3 |

Commands that did **not** move: `sfp build`, `sfp install`, `sfp publish`, `sfp release`, `sfp pool delete`, `sfp validate pool`. Your existing flags on these are unchanged.

A few v50 topics were removed entirely because the server owns them now (`ai`, `config`, `resource`, and the top-level `releasedefinition`). If your pipeline manually queued environment locks with `sfp resource enqueue` / `wait` / `dequeue`, that is replaced in Step 3.

## Step 3 — Rework review-environment calls

This is the largest change for pipelines that run PR validation. On v50, fetching a review org, holding an exclusive lock, and returning it were separate CLI calls. On v51 the server manages the lease, and the CLI reserves and acquires in two phases.

```bash
# Before (v50) — one fetch, one status flip to return it
sfp reviewenv fetch --repository "$REPO" --issue "$PR" --pool "$POOL" --pooltype "$TYPE" --leasefor 60
# ... run validation ...
sfp reviewenv transition --repository "$REPO" --issue "$PR" --status "Available"

# After (v51) — reserve, then acquire exclusive access; release when done
sfp server review-envs assign  --type pr --id "$PR" --repository "$REPO" --pool-tag "$POOL_TAG" --domain "$DOMAIN" --expiration 60 --json
sfp server review-envs acquire --type pr --id "$PR" --repository "$REPO" --domain "$DOMAIN" --duration 90 --wait --poll-interval 30 --json
# ... run validation ...
sfp server review-envs release --type pr --id "$PR" --repository "$REPO"
```

Two related simplifications come with this:

* **Pool-type probing is gone.** v50 ran `sfp pool probe` to discover a pool's type before fetching. v51 carries the pool by tag, so that step is removed.
* **Environment locking is a single action.** The manual `sfp resource enqueue` / `wait` / `dequeue` sequence is replaced by one lock-and-authenticate step.

## Step 4 — Verify

Confirm the CLI is on v51:

```bash
$ sfp --version
@flxbl-io/sfp-pro/51.23.0 darwin-arm64 node-v26.4.0
```

From here, each capability you hand to the server — build-on-merge, validation, pools — retires its CLI step from your pipeline. [Migrating to codev](https://docs.flxbl.io/codev/migrating-to-codev) walks that handover.

{% content-ref url="/pages/sAT9ouO659vuBfvUx9Ct" %}
[sfp versioning and upgrade Process](/flxbl/sfp/faqs/sfp-versioning-and-upgrade-process.md)
{% endcontent-ref %}


---

# Agent Instructions
This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com.

## Querying This Documentation
If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question.

Perform an HTTP GET request on the current page URL with the `ask` query parameter, and the optional `goal` query parameter:

```
GET https://docs.flxbl.io/flxbl/sfp/getting-started/docker-images/sfp-pro/upgrading-v50-to-v51.md?ask=<question>&goal=<endgoal>
```

`ask` is the immediate question: it should be specific, self-contained, and written in natural language.
`goal` is optional and describes the broader end goal you are ultimately trying to accomplish on behalf of the user. GitBook uses it to tailor the answer towards what is most useful for that goal.

The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.

Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.