Salesforce native DevOps runs inside your Salesforce org, so your metadata is processed inside the Salesforce platform's trust boundary. External Salesforce DevOps tools run somewhere else, either on a vendor's cloud or on servers you own.
That one choice decides where your data rests, who holds the encryption keys and who patches the infrastructure.
Flosum offers all three: Salesforce-native, Flosum-hosted cloud and customer-hosted. Below is what each one means in practice, and how to pick.
What is Salesforce native DevOps?
Flosum's native option is a managed package installed in your org from the AppExchange. Version control, merges, deployments and pipelines all execute inside Salesforce.
Because nothing runs outside the org, your existing profiles, permission sets, login policies and Shield Platform Encryption apply to the tool automatically. Our post on native Salesforce DevOps covers why it suits teams led by Salesforce admins.
An external tool connects to your org from outside. It keeps a copy of your metadata outside the org, for example in a Git repository.
Native vs external DevOps: what actually changes
With Flosum, the functional product is the same in every model. What changes is where the work runs, where the data rests and who operates the stack.
This table compares the three deployment options, using the details on Flosum's deployment architectures page.
What every model shares: the Metadata API
The Metadata API is Salesforce's API for deploying metadata, so its limits apply to any tool that deploys through it, native or external.
A single Metadata API deploy caps at 10,000 files and roughly 39 MB compressed. A release bigger than that has to be split into several deploys.
If you build with Salesforce DX, our DX guide covers how those deployments are packaged.
The Salesforce development process in every model
The Salesforce development process underneath is the same whichever deployment model you choose. Salesforce DX is Salesforce's way to manage and develop apps across their entire lifecycle, built around source-driven development.
Salesforce DX supports two development models, and both keep changes and project files in a source control repository. They differ in how you deploy, test and release code.
With org development, you work against orgs that don't have source tracking, such as non-source-tracked sandboxes or Developer Edition orgs, and retrieve and deploy code directly.
With package-based development, you build self-contained packages, typically against source-tracked scratch orgs, using source tracking and continuous integration. Salesforce says the right model depends on the complexity of the change, your team's size and skills, and the metadata you work on.
Salesforce DX scratch orgs are disposable, source-driven environments built from a configuration file you can share, so every developer starts from the same basic org. Salesforce says they support automated testing and continuous integration, and asks you not to add personal data to them.
Salesforce suggests a new one when you start a project or feature branch, test a new feature or start automated testing.
To load test data into scratch orgs, the Salesforce CLI command data import tree imports JSON files into an org.
The Salesforce CLI ties it together. Salesforce developers use the Salesforce CLI to create and manage orgs, sync source, and create and install packages, on a laptop or on a continuous integration (CI) system.
So when you compare Salesforce DevOps tools, check how each one fits the development model your Salesforce development teams already use. Scratch orgs, Salesforce CLI scripts and package-based development don't go away when you pick a deployment model.
Where Lifecycle Center (formerly DevOps Center) stops
Salesforce's own release management tool is Lifecycle Center (formerly DevOps Center). It's built into the Salesforce platform, but it isn't native in the sense above.
You open it from the App Launcher with no package to install, and Salesforce says it uses source control as the single source of truth for your team. It's included in Professional (with API access), Enterprise, Performance, Unlimited and Developer editions.
It isn't available in Government Cloud Plus or the EU Operating Zone, which matters if your org runs in either. Salesforce describes it as bringing modern DevOps best practices to your team through a click-based interface, built on the principles of the DevOps Center managed package.
Teams can also commit changes by hand from development environments that don't have source tracking. Its MCP tools, available through the Salesforce DX MCP Server, suggest fixes for merge conflicts and deployment failures.
Salesforce Help also has a quick start for using the Salesforce CLI with Lifecycle Center.
Work moves through a default pipeline with Integration, UAT and Staging stages between development and production. Quality gates can require Apex tests and Code Analyzer scans to pass, and a failed gate blocks the promotion.
Unlike change sets, it keeps work in source control and tracks it as work items. In sandboxes and scratch orgs, the DX Inspector lets developers track source-tracked changes, create work items and commit metadata without leaving the org.
Its governance layer is still in Beta. It checks Agentforce Vibes coding-agent actions against policies in real time, not changes people make.
If you still run the older DevOps Center managed package, it stopped accepting new installs in April 2026. Existing installs keep working, and Salesforce offers a migration tool to move projects to the current version.
Lifecycle Center keeps your changes in a GitHub or Bitbucket Cloud repository hosted outside Salesforce. Salesforce's Security, Privacy and Architecture documentation lists it under its former name, DevOps Center, as outside the scope of its ISO, SOC and PCI reports.
Backup, archive and point-in-time recovery aren't among its documented capabilities, so restoring data after a bad deployment needs another tool.
Audit evidence has a gap too. You can only download the past 180 days of Setup Audit Trail, so you have to export older configuration history if you need to keep it.
Our Lifecycle Center guide covers the product in full, and its known limitations get their own post. We compare other tools in our Lifecycle Center alternatives roundup.
Option 1: Salesforce-native
With the native option, everything Flosum does runs inside your org. There's no external server, database or data center behind it.
Your security review of it is mostly a review of the Salesforce platform, plus the package's AppExchange security review. Identity runs through your Salesforce login and SSO.
Choose it when the rule is simple: no new vendor infrastructure in scope, and data stays in Salesforce.
Option 2: Flosum-hosted cloud
Here, Flosum's Cloud Apps (DevOps, Backup & Archive, Data Migrator and Global Settings) run on AWS infrastructure that Flosum owns and operates. Data moves between your org and Flosum over TLS 1.2 or later, and older TLS versions are disabled.
Data Migrator, one of those Cloud Apps, handles sandbox seeding, so it runs Flosum-hosted or customer-hosted too. Our sandbox seeding guide walks through the process.
Backups and archives are encrypted at rest with AES-256, and each connected org gets its own AWS KMS key that survives sandbox refreshes. The application database stores configuration and job logs, never your backup payloads.
Flosum patches the stack, monitors it with AWS tooling including CloudTrail, and has it audited by third parties every six months. You still manage users through SSO, SCIM, MFA and IP allowlists.
There's also a hybrid.
With Backup & Archive, Flosum runs the application while backups land in a storage bucket you own, in your AWS S3 or Azure Blob account. Our Salesforce backup guide goes deeper on backup itself.
Option 3: Customer-hosted
Customer-hosted is the same application on infrastructure you own. You provision a VM in AWS, Azure or GCP, and the Cloud Apps install in Docker containers behind an NGINX proxy on your own domain.
You generate the encryption key material, so Flosum never holds your data or your keys. The minimum VM is 32 GB of RAM and 4 vCPUs on Ubuntu x64.
The trade is plain.
You get full data sovereignty, and you take on VM hardening, OS patching, certificates, storage durability and key custody. Flosum's certifications don't extend to infrastructure Flosum doesn't run.
Who is responsible for what
This table shows who owns each layer in each model, from Flosum's published shared responsibility matrix.
Rollback and backup in each model
A bad deployment is a recovery problem as much as a release problem. Flosum's Salesforce DevOps solution captures each deployment so changes can be reversed in one click, with impact analysis.
That covers metadata. For records, Backup & Archive is one of Flosum's Cloud Apps, so your backup data sits on Flosum-managed AWS, in your own S3 or Azure Blob bucket, or on a VM you run.
Encryption follows the model. Flosum-hosted backups use AES-256 with an AWS KMS key per org, and customer-hosted ones use key material you generate.
Whichever model you choose, test a restore before you need one.
How compliance shapes the choice
None of these rules names a deployment model. They set how long records must be kept and which controls a system needs.
SOX
The SEC requires auditors to keep audit and review records for seven years. If your auditors test change management, plan to keep change evidence longer than Setup Audit Trail's 180 days.
Our SOX compliance guide covers SOX for Salesforce in more depth.
HIPAA
The HIPAA Security Rule requires audit controls on systems that hold electronic protected health information. Required documentation has to be kept for six years.
The required risk analysis covers all the ePHI you create, receive, maintain or transmit, so every external system that holds it is one more to assess. Here's how to make Salesforce HIPAA compliant on the platform side.
GDPR
GDPR asks for data protection by design and records of processing activities. If an external tool processes personal data, for example in backups, your records of processing need to cover it.
Government
Flosum's deployment page describes a frequent public-sector pattern. Teams run Salesforce-native inside Salesforce Government Cloud and customer-hosted Cloud Apps inside their own accredited enclave, so the whole toolchain stays within their accreditation boundary.
Lifecycle Center isn't available in Government Cloud Plus, so check where your org runs before planning around it. Our FedRAMP guide covers the authorization side.
Which deployment model fits your team?
Start from your hardest requirement, not from the tool. This table maps common requirements to a starting model, following Flosum's deployment guidance.
Retention is the other half of the decision. Our guides to Salesforce data retention, data archival and the Salesforce audit trail cover retention in more depth.
What a Salesforce CI/CD pipeline does for release management
A Salesforce DevOps pipeline is the controlled path that moves metadata and code from development through testing and approval to production. Flosum's DevOps page describes a mature pipeline as one that automates validation, dependency checks, quality gates and approvals.
Change sets are the older way to move Salesforce deployments between orgs. With change set development, Trailhead notes, the production org stays the source of truth, and metadata isn't organized in a way that's easy to upgrade and maintain.
Package-based development moves the source of truth to your version control system, with source grouped into package directories in a Salesforce DX project. Each package version is an immutable snapshot, and developers use scratch orgs for unit testing.
From there, packages are installed in QA, sandbox and production orgs. A fix made directly in production gets overwritten when the next package version installs, so admins need to tell the development team about it.
The pipeline is the same idea in all three deployment models. What changes is where it executes: inside your org, on Flosum-managed AWS or on your own VM.
Good Salesforce release management means every promotion is approved, tested and recorded. Flosum adapts to how Salesforce teams branch and release, from two-week sprints to release trains with more than 100 developers.
Salesforce changes from admins, developers and AI tools all go through the same version control, approvals and audit trail. Each change is also validated against a dependency graph of your org, so missing references show up before deployment.
For regulated Salesforce teams, Flosum says its audit trails, segregation of duties and approval controls support SOX, HIPAA, GxP and 21 CFR Part 11 requirements.
How to choose the best Salesforce DevOps tools
The deployment model tells you where Salesforce DevOps tools run. It doesn't tell you how well the tool handles Salesforce metadata, so check that separately.
Start with version control. Every change to code and metadata should be tracked in version control with its author, so you have a complete history and can roll back when a release goes wrong.
Next, look at CI/CD. A CI/CD setup should give you automated deployments with validation, quality gates and automated testing before anything reaches the production environment.
Ask how a bad deployment gets reversed, and how long that takes. Then check that the tool connects to the Git host, ticketing system and CI servers you already run.
Finally, ask for proof. Request each vendor's SOC 2 and ISO/IEC 27001 reports instead of relying on a logo on a web page.
Flosum DevOps is an enterprise DevOps platform for Salesforce with metadata-aware version control, governed CI/CD, automated testing and one-click rollback. It merges each metadata type with its own logic, so a Profile merges differently from an Apex class.
Git is optional in Flosum: teams can run full CI/CD without it, because Flosum's own version control is the system of record. It connects to GitHub, GitLab, Bitbucket and Azure DevOps when you want it, along with Jira, Slack and ServiceNow.
For the wider field, our roundup of the best Salesforce DevOps tools compares features and pricing, and our guide to version control without Git explains how that works.
How to measure DevOps success with DORA metrics
Salesforce teams can measure delivery the same way whichever model they run. DORA, the DevOps Research and Assessment program, tracks five software delivery metrics: change lead time, deployment frequency, failed deployment recovery time, change fail rate and deployment rework rate.
DORA's research found that speed and stability aren't tradeoffs, and top performers do well on all five.
Take a baseline before you change tools or deployment models, then measure again after go-live. Our guide to DORA metrics for Salesforce shows how to track them.
You don't have to pick only one
You can mix models. The government pattern above combines two, and the Backup & Archive hybrid splits the application from the storage.
Because the functional product is the same in all three models, moving a workload to a different one doesn't mean switching vendors for Flosum DevOps.
For the bigger picture on release automation, start with our Salesforce DevOps guide, or read our take on native ALM software.
FAQs
Not sure which model your security team will sign off on? Book a demo to walk through all three Flosum deployment options against your own requirements.
Thank you for subscribing
