Types of Packages in Salesforce: Unmanaged, Managed & Unlocked

A package in Salesforce is a versioned container of metadata — Apex classes, Lightning components, objects, flows, permission sets and more — that you bundle once and then deploy or distribute to other Salesforce orgs. In 2026 there are three families you need to know:

• Unmanaged packages — a one-time copy of metadata with no upgrade path; best for templates, examples and open-source starter code.
• Managed packages — namespaced, upgradeable and IP-protected; the route for ISVs publishing on AppExchange. They split into legacy first-generation (1GP) and the modern, source-driven second-generation (2GP).
• Unlocked packages — a 2GP package type that needs no namespace; the current best practice for internal, modular org development by non-ISV teams.

The short version: if you are building a product to sell, you want a 2GP managed package; if you are organising your own org's metadata into clean, deployable modules, you want an unlocked package. 1GP is legacy — start new work on Salesforce DX and the sf CLI.

Key takeaways

• Packages bundle and version metadata so you can deploy or distribute it cleanly instead of hand-migrating components or stacking change sets.
• Unmanaged = editable one-time copy, no upgrades. Managed = locked, namespaced, upgradeable, for AppExchange. Unlocked = source-driven modules for your own org.
• 2GP (second-generation packaging) is the modern model for both managed and unlocked packages; 1GP managed packaging is legacy.
• The workflow runs on Salesforce DX: a source-tracked project, a Dev Hub, scratch orgs, and the sf CLI (sf package create, sf package version create, sf package install).
• The old sfdx force:package:* commands still run but are deprecated — prefer the newer sf package ... commands.

What is a package in Salesforce?

A package groups related components so they move together as a single, named unit with a version number. Instead of exporting components one by one or relying only on change sets, you declare what belongs in the package and Salesforce produces an installable package version you can deploy across sandboxes, scratch orgs and production — or list on AppExchange for customers to install.

Every package version is immutable once created, which makes releases reproducible: the same version installs the same metadata everywhere. Packages can also declare dependencies on other packages and an ancestry line so upgrades apply cleanly on top of what an org already has installed.

What are the types of packages in Salesforce?

The four options below cover every modern packaging scenario. Use this table to pick the right one before you write a line of metadata.

Package type	Namespace	Upgradeable	Source visible / editable	IP-protected	Built with	Best for
Unmanaged	No	No	Yes (fully editable after install)	No	Any org	Templates, samples, open-source starter code, one-off migrations
1GP managed (legacy)	Required	Yes	No (locked)	Yes	Packaging org	Older ISV products already shipping on 1GP
2GP managed	Required	Yes	No (locked)	Yes	Salesforce DX + Dev Hub	New ISV / AppExchange products
Unlocked	Optional	Yes	Yes (org admins can change)	No	Salesforce DX + Dev Hub	Internal, modular org development for one or many orgs

Direction of travel: Salesforce recommends building new managed and unlocked packages on second-generation packaging (2GP) with Salesforce DX. First-generation (1GP) managed packaging is in maintenance mode — keep it only for products already published on it.

When should you use an unmanaged package?

Unmanaged packages are a one-time copy of metadata. Once installed, the components belong to the destination org: an admin or developer can edit or delete them, and the original publisher cannot push upgrades or patches. There is no namespace, so component names can collide with existing metadata.

That makes them ideal for:

• Sharing a template app or reference implementation the recipient is expected to customise.
• Distributing open-source or sample code such as training material and quick-start kits.
• Moving a chunk of metadata between your own orgs as a one-off.

Avoid them for anything you need to maintain, version or protect — there is no upgrade story.

How do managed packages work (1GP vs 2GP)?

Managed packages are namespaced, upgradeable and IP-protected. The Apex source stays hidden from the subscriber, and the publisher can ship new versions and patches that customers install on top of what they already have. This is the route for software vendors (ISVs) distributing on AppExchange.

There are two generations:

• First-generation (1GP) — the original, org-based model. The package and its namespace are tied to a single packaging org, and you assemble versions through that org's UI. It still works, but it is legacy and harder to put under version control and CI/CD.
• Second-generation (2GP) — the modern, source-driven model. The package is defined in your sfdx-project.json and built from source in a repo, the namespace is linked to your Dev Hub (not locked to one org), and versions are created from the CLI. 2GP is the recommended path for all new managed packages.

If you are an ISV starting fresh, build on 2GP. For teams modernising a 1GP product, Salesforce provides tooling to help migrate metadata toward 2GP over time.

What are unlocked packages used for?

Unlocked packages are a 2GP package type aimed at your own org's development, not at selling on AppExchange. They are upgradeable like managed packages, but the namespace is optional and admins can still see and adjust the installed metadata.

They are the current best practice for non-ISV teams because they let you:

• Break a large, tangled org into modular, independently deployable packages (for example: core objects, a sales module, an integrations module).
• Put each module under source control and ship it through CI/CD instead of fragile change sets.
• Reuse the same package across multiple orgs — sandboxes, regional production orgs and business units.

If your goal is a cleaner, version-controlled org rather than a commercial product, unlocked packages are almost always the right answer. See our guide to Salesforce source code management with VS Code, Git and GitHub for the repo setup that makes this work.

How does the modern Salesforce DX packaging model work?

Both 2GP managed and unlocked packages live in the Salesforce DX (SFDX) model, which treats metadata as source in a Git repository rather than something you click together in a single org. The moving parts are:

• Source-tracked project — an sfdx-project.json that declares your package directories, package names and versions.
• Dev Hub — the org that owns your 2GP packages and authorises scratch orgs. You enable it once in Setup.
• Scratch orgs — disposable, source-tracked orgs you spin up from a config file to build and test a package version, then throw away.
• The sf CLI — the unified command-line tool that creates packages, builds versions and installs them.

A typical flow: develop against a scratch org, commit the source to Git, create an immutable package version from the CLI, then install that version into QA and production. This is exactly the kind of pipeline we cover in techniques and tools to improve the Salesforce development cycle.

# Authorise your Dev Hub (one-time). Enable Dev Hub + 2GP in Setup first.
sf org login web --set-default-dev-hub --alias DevHub

# Create a package definition (run once per package).
#   --package-type can be "Unlocked" or "Managed".
sf package create \
  --name "Sales Core" \
  --package-type Unlocked \
  --path force-app \
  --target-dev-hub DevHub

# Build an immutable, installable version from your source.
sf package version create \
  --package "Sales Core" \
  --installation-key-bypass \
  --code-coverage \
  --wait 20 \
  --target-dev-hub DevHub

# Install a specific version into a target org (sandbox, scratch org or prod).
sf package install \
  --package "Sales Core@1.2.0-1" \
  --wait 20 \
  --target-org QA

# Legacy equivalents (deprecated) used the sfdx force:package namespace, e.g.:
#   sfdx force:package:version:create ...
#   sfdx force:package:install ...
# Prefer the "sf package ..." commands above for all new work.

Package versions, dependencies, and ancestry

Three concepts make packaging reliable at scale:

• Versions — every sf package version create produces an immutable version such as 1.2.0-1. Because versions never change after they are built, an install is fully reproducible across environments.
• Dependencies — a package can declare that it depends on other packages, or specific versions of them, in sfdx-project.json. Salesforce installs dependencies in the right order, so a "sales" module that builds on a "core" module always gets what it needs.
• Ancestry — for upgradeable packages you define an ancestor version so each new release upgrades cleanly on top of the one an org already has, rather than forcing a fresh install. Ancestry is what makes managed and unlocked upgrades safe.

Getting these right is the difference between a smooth release train and a tangle of manual deployments.

Which package type should you choose?

• Building a product to sell on AppExchange? Use a 2GP managed package so your IP stays protected and customers get clean upgrades.
• Cleaning up and modularising your own org? Use unlocked packages under Git and CI/CD.
• Sharing a template, sample or starter kit? An unmanaged package is fine.
• Already shipping on 1GP? Keep it running, but plan your roadmap toward 2GP.

Need help choosing a packaging strategy or moving an org onto Salesforce DX? Our Salesforce consulting and development team has done this for startups and enterprises across 12+ years and 50+ projects.

Frequently Asked Questions

What are the different types of packages in Salesforce?

There are three families: unmanaged, managed and unlocked. Unmanaged packages are a one-time, editable copy of metadata with no upgrades. Managed packages are namespaced, locked and upgradeable — the AppExchange route — and come in legacy first-generation (1GP) and modern second-generation (2GP) forms. Unlocked packages are a 2GP type for modular, version-controlled development of your own org.

What is the difference between managed and unmanaged packages?

A managed package is locked, namespaced and upgradeable: the source stays hidden and the publisher can push new versions, which is why ISVs use it for AppExchange products. An unmanaged package is an editable one-time copy with no namespace and no upgrade path, suited to templates and open-source samples.

What is the difference between 1GP and 2GP packaging?

1GP (first-generation) is the original org-based model: the package and namespace are tied to a single packaging org and assembled through its UI. 2GP (second-generation) is source-driven — the package is defined in sfdx-project.json, built from a Git repo, linked to your Dev Hub, and created with the sf CLI. 2GP is recommended for all new packages; 1GP is legacy.

When should I use an unlocked package?

Use an unlocked package when you want to organise your own org into modular, independently deployable units under source control and CI/CD — not when you are selling software. They are upgradeable, the namespace is optional, and admins can still adjust the installed metadata, which makes them the current best practice for internal Salesforce development.

Is the sfdx force:package command still used?

The sfdx force:package:* commands still function but are deprecated. The current tooling is the unified sf CLI: use sf package create, sf package version create and sf package install for all new automation and CI/CD pipelines.

Do I need a Dev Hub to create packages?

For second-generation packaging, yes. 2GP managed and unlocked packages require a Dev Hub — the org that owns your packages and authorises scratch orgs — which you enable once in Setup. Unmanaged and legacy 1GP managed packages do not use a Dev Hub.