pnpm/pnpm11/docs/cli/deploy.md

id, title

id	title
deploy	pnpm deploy

Deploy a package from a workspace. During deployment, the files of the deployed package are copied to the target directory. All dependencies of the deployed package, including dependencies from the workspace, are installed inside an isolated node_modules directory at the target directory. The target directory will contain a portable package that can be copied to a server and executed without additional steps.

:::note

Since v11.26.0, pnpm deploy no longer requires injectWorkspacePackages. A linked workspace dependency is rewritten to a file: dependency in the dedicated deploy lockfile. The peer dependencies it declares are bound the way an injected install binds them: to the version its parent provides. If the parent does not depend on the peer, pnpm looks further up, to the deployed project. A peer that no ancestor provides is bound to the deployed graph's own resolution.

The binding is ambiguous when the ancestors provide more than one package or version, or when no ancestor provides the peer and the deployed graph holds more than one version. The deploy then fails with ERR_PNPM_DEPLOY_AMBIGUOUS_PEER, naming the package, the peer, and the competing resolutions. Pin the peer to one version with an overrides entry, or turn injectWorkspacePackages on, which is the setting that decides between the candidates.

Before v11.26.0 the command refused every non-injected workspace up front. --legacy, or forceLegacyDeploy: true, still selects the older implementation.

:::

:::note

When the enableGlobalVirtualStore option is set, pnpm deploy ignores it and always creates a localized virtual store within the deploy directory. This keeps the deploy directory self-contained and portable.

:::

Usage:

pnpm --filter=<deployed project name> deploy <target directory>

In case you build your project before deployment, also use the --prod option to skip devDependencies installation.

pnpm --filter=<deployed project name> --prod deploy <target directory>

Usage in a docker image. After building everything in your monorepo, do this in a second image that uses your monorepo base image as a build context or in an additional build stage:

# syntax=docker/dockerfile:1.4

FROM workspace as pruned
RUN pnpm --filter <your package name> --prod deploy pruned

FROM node:22-alpine
WORKDIR /app

ENV NODE_ENV=production

COPY --from=pruned /app/pruned .

ENTRYPOINT ["node", "index.js"]

A deployed symlink to a directory inside the project is kept even if the directory is not deployed. A link into node_modules resolves to the dependency installed in the output directory. A symlink to a file that is not deployed is replaced by a copy of the file.

Options

--force

Allow deployment to a non-empty target directory. Without this flag, pnpm fails with ERR_PNPM_DEPLOY_DIR_NOT_EMPTY if the target directory is not empty.

--ignore-scripts

Skip lifecycle scripts during deployment, including dependency build scripts. See pnpm install --ignore-scripts.

--dev, -D

Only devDependencies are installed.

--no-optional

optionalDependencies are not installed.

--prod, -P

Packages in devDependencies won't be installed.

--filter <package_selector>

Read more about filtering.

--legacy

Force legacy deploy implementation.

By default, pnpm deploy will try creating a dedicated lockfile from a shared lockfile for deployment. The --legacy flag disables this behavior and also allows using the deploy command without the inject-workspace-packages=true setting.

Files included in the deployed project

By default, pnpm copies the files that pnpm pack would include. They are selected in one of the following ways, resolved in order:

1. The project's package.json may contain a "files" field to list the files and directories that should be copied.
2. If there is an .npmignore file in the application directory then any files listed here are ignored.
3. If there is a .gitignore file in the application directory then any files listed here are ignored.

To copy every file of the project, set deployAllFiles to true.

Since v11.28.0, symlinks that point to files or directories included in the deployed project are kept as symlinks.

The deployed project

Since v11.28.0:

• The packageManager and devEngines.packageManager fields of the workspace root package.json are not copied into the deployed package.json. Versions v11.28.0 through v11.28.x copied them.
• The virtual store is created at virtualStoreDir, resolved against the deploy directory. A deploy from a shared lockfile records virtualStoreDir in the deployed pnpm-workspace.yaml. With the global virtual store enabled or an absolute virtualStoreDir, the deploy uses node_modules/.pnpm.
• The prepare script of the deployed project is not run.
• --package-import-method passed on the command line is respected.

Configuration

forceLegacyDeploy

• Default: false
• Type: Boolean

By default, pnpm deploy will try creating a dedicated lockfile from a shared lockfile for deployment. If this setting is set to true, the legacy deploy behavior will be used.