⚠️ End of Life Notice - May 2026

sfp Community Edition will be sunset in May 2026.

Thank you for being part of the flxbl community over the last 6 years. It's been a great experience building this out alongside all of you—starting from an Azure DevOps extension put together in a weekend, to a plugin, and eventually to a CLI. Today we have 300+ orgs using it in their CI/CD workflows.

Over the last 2 years, as we started building sfp pro (initially as a means to sustain the overall project), we didn't anticipate the extent of changes we'd introduce to support developers with an experience that removes the need to pause and ponder—staying in your natural flow. We introduced codev and sfp server. sfp server is rapidly evolving into our vision of "devhub++", with codev providing the visual interface on web/desktop and sfp pro cli providing the CLI interface. We're hoping to promote sfp server and codev from beta to v1 at the beginning of April.

All of this means the architecture has changed drastically—community and pro are now two entirely different codebases. The community edition has to be maintained independently, and to be transparent, we haven't been able to ship new features to the community for a while now. It's also become hard to align documentation across both topologies, creating confusion for organisations upgrading or new to the ecosystem.

We've decided to sunset sfp community edition by May 2026. Issues and PRs are no longer being accepted. The repo will remain available if you want to fork and maintain it internally—see the build instructions below.

Thanks once again for your understanding and all your contributions.

Timeline

Date	Milestone
January 2026	Issues and PR intake closed
Feb - April 2026	Build instructions and Claude instructions added for users who are forking
Early May 2026	Repository archived, docs updated to focus on new terminology

---

         .----------------.  .----------------.  .----------------.
        | .--------------. || .--------------. || .--------------. |
        | |    _______   | || |  _________   | || |   ______     | |
        | |   /  ___  |  | || | |_   ___  |  | || |  |_   __ \   | |
        | |  |  (__ \_|  | || |   | |_  \_|  | || |    | |__) |  | |
        | |   '.___`-.   | || |   |  _|      | || |    |  ___/   | |
        | |  |`\____) |  | || |  _| |_       | || |   _| |_      | |
        | |  |_______.'  | || | |_____|      | || |  |_____|     | |
        | |              | || |              | || |              | |
        | '--------------' || '--------------' || '--------------' |
         '----------------'  '----------------'  '----------------'

sfp is an purpose built cli based tool specifically designed for modular Salesforce development and release management. sfp is aimed at streamlining and automating the build, test, and deployment processes of Salesforce metadata, code and data. It extends sf cli functionalities, focusing on artifact-driven development to enhance DevOps practices within Salesforce projects.

Key Aspects of sfp:

• Artifact-Centric Approach: sfp packages Salesforce code and metadata into artifacts, along with deployment details, ensuring consistent deployments and simplified version management across environments.
• Best-in-Class Mono Repo Support: Offers robust support for mono repositories, facilitating streamlined development, integration, and collaboration
• Support for Multiple Package Types: sfp accommodates various Salesforce package types with streamlined commands, enabling modular development, independent versioning, and flexible deployment strategies.
• Orchestrate Across Entire Lifecycle: sfp provides an extensive set of functionality across the entire lifecycle of your Salesforce development.
• End-to-End Observability: sfp is built with comprehensive metrics that are emitted on every commands providing unparalleled visibility into your ALM process. Commands

sfp is comprised of a suite of commands to aid in your end to end development cycle for Salesforce. Starting with the core commands, you are able to perform basic work flows to to build and deploy artifacts (locally to start, and to a NPM artifact repository after) across environments through the command line. As you progress in your understanding of the core commands, you can utilized more advanced commands and flags in your CI/CD platform of choice to drive a more complete release process leveraging release definitions, change logs, metrics and much more.

sfp is constantly evolving and being driven by the passionate community that has embraced our ways of working. We have introduced key utility commands over the years to solve pain points specific to the Salesforce Platform. The commands have been successfully tested and used on large enterprise-scale implementations. As we continue to grow the toolset, we hope to introduced more commands to address the future wave of challenges.

Installing sfp locally

sfp can be installed on your local device using npm

npm i -g @flxbl-io/sfp

Docker

Docker images for sfp are available at GitHub Container Registry.

We recommend using the sfp docker image to avoid breakages in your CI/CD pipelines due to updates in sfp

Build Instructions

To build sfp execute the following on the terminal:

cd <sfp directory> # Navigate to the checked out directory
npm i
npm run build

To run unit tests

npm run test

To debug and test plugin

 cd packages/sfp-cli
 npm link

... ...

Building and Testing sfp in Isolation

To ensure consistent and reproducible builds and tests of sfp across different environments, you can leverage Docker to create an isolated container. Assuming you have a Dockerfile set up in the sfp package directory, follow these steps:

1. Build the Docker image:

   docker build -t sfp .
   

   This command will build a Docker image tagged as sfp using the Dockerfile in the current directory.

2. Run the Docker container:

   docker run -it --rm -v $(pwd):/usr/src/app sfp
   

   This command does the following:

   • -it: Runs the container in interactive mode, allowing you to see the output and interact with the container if needed.
   • --rm: Automatically removes the container when it exits.
   • -v $(pwd):/usr/src/app: Mounts your current directory (the sfp package directory) to /usr/src/app inside the container. This allows you to work on the sfp package files locally while running the build and test processes inside the isolated container environment.
   • sfp: Specifies the name of the Docker image to run.

3. Inside the container, the CMD instruction defined in the Dockerfile will be executed, running sfp's tests and build process.

4. The logs from both the test and build steps will be outputted to the console, allowing you to see the results and any potential issues.

By running the tests and build process inside a Docker container, you ensure that sfp is built and tested in a consistent and isolated environment, regardless of the host machine's setup. This helps prevent issues related to different Node.js versions or system dependencies.

If you want to run the tests and build separately or execute other npm scripts, you can override the default CMD instruction by specifying the command after the docker run command. For example:

docker run -it --rm -v $(pwd):/usr/src/app sfp npm test

This command will run only the npm test command inside the container.

...

To simplify building and testing the sfp package inside a Docker container, you can create aliases for the relevant commands. Open your shell configuration file (e.g., ~/.bashrc, ~/.bash_profile, or ~/.zshrc) and add the following lines:

alias sfp-build="docker build -t sfp ."
alias sfp-test="docker run -it --rm -v $(pwd):/usr/src/app sfp 'npm test'"
alias sfp="docker run -it --rm -v $(pwd):/usr/src/app sfp './bin/run'"

Save the file and reload the shell configuration by running the appropriate command (e.g., source ~/.bashrc, source ~/.bash_profile, or source ~/.zshrc).

Now, you can easily build the sfp package and run the tests inside a Docker container using the defined aliases:

1. Build the sfp package:

   sfp-build
   

   This command will build the Docker image tagged as sfp-package using the Dockerfile in the current directory. The --no-cache flag ensures that the image is always built from scratch, blowing up the previous image if it exists.

2. Run the sfp tests:

   sfp-test
   

   This command will execute the npm test command inside the sfp Docker container, running the tests in an isolated environment.

By using these aliases, you can quickly build the sfp package and run the tests within a Docker container, ensuring a clean and isolated environment every time.

...

Maintainers

List of Maintainers are available in the link

Where do I reach for queries?

Please create an issue in the repo for bugs or utilize GitHub Discussions for other queries. Join our Slack Community as well.

License