sfdx-hardis vs DevOps Center: which one fits in 2026

sfdx-hardis and Salesforce DevOps Center, called Lifecycle Center since October 2026, both come without licence fees and both take changes to production through Git. The difference is where the process lives. Lifecycle Center is a native app in a Salesforce org with a click-based interface, and it works only with GitHub.com and Bitbucket Cloud. sfdx-hardis runs as a pipeline in the client’s CI, on GitHub, GitLab, Azure DevOps, Bitbucket or Jenkins, and adds monitoring, backup and documentation. My rule of thumb: Lifecycle Center for small, click-based teams, sfdx-hardis for programmes with several partners.

What is the difference between sfdx-hardis and DevOps Center?

Lifecycle Center is what used to be called Next Generation DevOps Center. Salesforce moved the app into the platform in 2026: you open it from the App Launcher, there is no package to install. Salesforce calls the org it runs in the hub org. That is where you create projects, pipelines and work items. A work item is one business change that you promote from stage to stage with a click, while the app creates branches, pull requests and deployments in the background. The old DevOps Center managed package keeps running for existing customers, but Salesforce recommends the switch, and only one of the two can be active at a time. The details of the move are in the Salesforce help on Lifecycle Center1.

sfdx-hardis is an open source toolkit from Cloudity and a large community. It consists of a Salesforce CLI plugin, a VS Code extension and Docker images for the pipeline. The process sits in configuration files in the repository and in the client’s CI pipeline. What it covers is in my introduction to sfdx-hardis.

In short: with Lifecycle Center, Salesforce is the control centre and Git is the storage. With sfdx-hardis, the Git platform is the control centre and Salesforce is the target.

Where the release process is controlled

Lifecycle Center

Control centreHub org in Salesforce

1. Development
2. UAT
3. Production

branch, PRdeployment

StorageGitGitHub.com, Bitbucket Cloud

TargetSalesforce orgsUAT, production

A Salesforce service calls the Git platform from the outside.

sfdx-hardis

Control centreGit platform with CI

1. Pull request
2. Checks
3. Merge

deploymentscheduled

TargetSalesforce orgsUAT, production

PlusMonitoringBackup, documentation

The runner in the client's CI connects from the inside.

The comparison at a glance

Lifecycle Center and sfdx-hardis compared

CriterionLifecycle Centersfdx-hardis

User interfaceStrengthClicks in Salesforce, plus DX Inspector in the dev orgVS Code extension and CLI

Where the pipeline runsHub org, a Salesforce service calls the Git platformStrengthIn the client's CI

Tests and quality gatesTest suites and quality gates before review and promotionValidation, Apex tests and static analysis on every pull request

Deploying dataThrough DX InspectorThrough deployment actions, for example with SFDMU

Monitoring and backupNot includedStrengthScheduled org checks, metadata backup, Grafana dashboards

DocumentationNot includedStrengthGenerated from the repository, including flows

TicketingJira import as a one-off copyStrengthJira, Azure Boards, ServiceNow and others

AIMCP tools in the Salesforce DX MCP Server, governance (beta)Coding agents for fixes, deployment agent (beta)

On origin: Lifecycle Center comes from Salesforce and runs with Salesforce support. sfdx-hardis comes from Cloudity and the community, with paid support available through Cloudity.

The sources for Lifecycle Center are the Salesforce help and the Winter ’27 release notes, for sfdx-hardis the project documentation2 and the overview of version 83, as of October 2026.

Which Git platforms are supported?

At many companies the question is settled right here. According to the setup considerations for Lifecycle Center4, only GitHub.com cloud plans, including GitHub Enterprise Cloud, and Bitbucket Cloud work. GitHub Enterprise Server, Bitbucket Data Center, GitLab and Azure DevOps are out. Salesforce has named GitLab and Azure as a priority after launch, with no date. More providers were already promised when DevOps Center launched in 2022, and so far only Bitbucket Cloud has arrived.

sfdx-hardis ships ready-made pipelines for GitHub, GitLab, Azure DevOps, Bitbucket and Jenkins. Because the pipeline runs in the client’s CI, the connection comes from the inside: the runner fetches the repository and deploys to the org. Whether your self-hosted variant is fully covered, for example for pull request comments, is best checked in a short test. For Lifecycle Center, the answer for self-hosted platforms is a clear no.

Which Git platform works with which tool

Git platformLifecycle Centersfdx-hardis

GitHub.com and Enterprise Cloudsupportedsupported

GitHub Enterprise Servernot supportedcheck in a test

Bitbucket Cloudsupportedsupported

Bitbucket Data Centernot supportedcheck in a test

GitLabannounced, no datesupported

Azure DevOpsannounced, no datesupported

Jenkinsnot supportedsupported

So if you work on Azure DevOps, like many industrial companies that run on Microsoft tools, you cannot use Lifecycle Center today without changing Git platform. And nobody changes their Git platform for a release tool.

Where does the release process live, and who owns it?

In Lifecycle Center, projects, pipelines and work items are records in the hub org. The repository stays with the client, the process around it lives in Salesforce.

For IT

What IT should know before connecting Lifecycle Center

• The GitHub connection runs through a Salesforce OAuth app that requests access to all repositories of the account.
• Repositories of a GitHub organisation only show up once an owner of that organisation approves the app.
• If the Git platform has IP restrictions, the Lifecycle Center addresses need to go on the allowlist.

With sfdx-hardis, everything sits in files in the repository and in the pipeline configuration. With branch protection, a partner can only change them through a pull request the client approves. That fits my basic rule that clients should own their DevOps tools: whoever controls repository and pipeline controls the release process.

For operations this means: Lifecycle Center needs an admin in the hub org, sfdx-hardis needs someone who understands the pipeline. Either way it is a role that someone on the client side should hold.

The cost sits in the release role

Neither has licence fees. The costs are elsewhere:

• Lifecycle Center: you need GitHub or Bitbucket Cloud, with their per-user costs. According to Salesforce, the AI features through MCP tools can be used together with services that consume paid credits. Setup is quick, because nothing is installed.
• sfdx-hardis: CI minutes on the Git platform, setting up the pipeline and a person who maintains it. Cloudity offers paid help, but you do not need it.

What both tools really cost

VisibleLicence: €0for both tools

Below: the real costs

1. Git platformCost per user on GitHub, Bitbucket or your platformboth
2. CI minutes and creditsMinutes for the pipeline, credits for AI servicesper tool
3. Setupquick for Lifecycle Center, building the pipeline for sfdx-hardisboth
4. Release rolean admin who clicks, or someone who maintains the pipelinebiggest item

In the programmes I support, the cost of a responsible release role is always higher than the cost of the tool. So choose the tool by the role you can fill: an admin who clicks, or someone who is at home with pipelines.

What I see in projects

I have used sfdx-hardis in client projects for about two years, and in October 2026 I completed all three levels of the free sfdx-hardis training. In programmes with several implementation partners, what counts most for me is that the process is binding: every partner works through the same pipeline, every pull request is validated the same way, and reviews are mandatory before anything is merged. Monitoring and generated documentation come along without a separate project.

Every partner on its own path

Changes only meet in the org, conflicts show up late.

One pipeline for all partners

Every pull request is validated and reviewed the same way before it is merged.

I have no project experience with Lifecycle Center that I could cite here. I therefore describe the following case as an assumption: a mid-sized machine builder runs one Salesforce org with two admins, no in-house developers, and already uses GitHub for another team. For this client, Lifecycle Center would be a good step away from change sets. The admins stay in Salesforce, they still get source control, and quality gates and test runs are built in. sfdx-hardis would be too much tool for too small a team there.

When does which tool fit?

Lifecycle Center fits when

• mostly admins and consultants click and little code is written,
• GitHub.com or Bitbucket Cloud is already in place,
• one team works on one org, without several partners,
• the org is not in the EU Operating Zone or Government Cloud Plus, where Lifecycle Center is not available.

sfdx-hardis fits when

• several teams or partners work on the same org,
• the Git platform is GitLab, Azure DevOps or a self-hosted variant,
• monitoring, metadata backup and documentation are needed,
• someone on the client side can own the pipeline, or that role is being built.

If you need a fully managed service with org comparisons and contractual support instead, commercial platforms such as Gearset or Copado are the better fit. How these vendors are currently adding AI agents to their products is summarised in Copado, Gearset and Provar AI agents.

I would not combine both tools

Technically both can point at the same org and even the same repository. Lifecycle Center handles merges that happen outside the app, and sfdx-hardis validates every pull request, wherever it comes from. I still would not do it. When two tools decide on the same stage branches, there are two release processes, and in the end nobody knows which state counts in production.

Decide per repository which tool owns merges and promotions. If you switch later, make it a planned cut, not a gradual drift.

For teams using coding agents this question matters more. Lifecycle Center is building a governance layer for agents in the hub org, sfdx-hardis relies on the checks in the pipeline. Which quality gates should stop AI-generated code applies to both tools in the same way.

Settle Git platform, teams and release role

Answer three questions first: which Git platform is set at your company, how many teams and partners work on the org, and who takes on the release role? With these answers the choice is made in most cases. If you are new to the topic, why DevOps matters in Salesforce enterprise projects explains the basics, and setting up a binding process is part of my work in DevOps and release management.

Sources4

1. 1Salesforce help on Lifecycle Center (opens in a new tab)help.salesforce.com
2. 2project documentation (opens in a new tab)sfdx-hardis.cloudity.com
3. 3overview of version 8 (opens in a new tab)sfdx-hardis.cloudity.com
4. 4setup considerations for Lifecycle Center (opens in a new tab)help.salesforce.com