A monorepo holds several apps or packages in one Git repository. dply deploys one package per app: you point the app at the package's folder with a Repository root, and dply builds from there while still installing dependencies from the workspace root. To deploy several packages from the same repository, create one app for each.
Set the repository root
When you create an app, dply inspects the repository for workspace markers: pnpm-workspace.yaml, turbo.json, nx.json, or lerna.json. When it finds one, it lists the packages it detected. If there is exactly one, it fills in the repository root for you.
To change it later, open Build, click the repository root row, and set it to the package folder relative to the top of the repository, such as apps/web.
Choose Save, then redeploy. The path cannot contain .., and leading or trailing slashes are removed. If the folder does not exist at the deployed commit, the build fails with Repository root "apps/web" was not found in the checkout.
How builds work in a monorepo
With a repository root set:
- Checkout. dply checks out only the package folder and the workspace files it needs, not every package in the repository.
- Configuration.
dply.yamlandwrangler.tomlare read from the repository root folder, not the top of the repository. Put them next to the package'spackage.json. - Build command and output directory run and resolve inside the repository root folder. An output directory of
distmeansapps/web/dist. - Install. When the top of the repository is a workspace (it has
pnpm-workspace.yaml, or apackage.jsonwithworkspaces), dply installs from the workspace root using the lockfile there, and filters the install to your package and its dependencies:
| Package manager | Filtered install |
|---|---|
| pnpm | pnpm install --filter ./apps/web... |
| npm | npm ci -w <package name>, falling back to npm install -w <package name> |
| Yarn | A full yarn install at the workspace root, then yarn workspaces focus <package name> |
If the package's package.json has no name, npm and Yarn repositories fall back to a normal install.
- Build cache. For workspace monorepos, the cache is saved and restored at the workspace root, where the installed
node_moduleslive.
You do not need to add cd apps/web to your build command. dply runs it from the package folder.
Which pushes trigger a deploy
With push-to-deploy connected, a push to the production branch redeploys the app only when it changes a file under the repository root. A push that only touches other packages is skipped. Changes to a dply.yaml, dply.yml, or dply.json at the top of the repository, or inside the repository root, also trigger a deploy.
With no repository root set, every push to the production branch redeploys the app.
Deploy hooks, redeploying from Deploys, and the API always deploy, whatever files changed. See Deploy triggers & hooks.
Turborepo and Nx
dply does not run turbo or nx for you. If your package's build depends on other workspace packages being built first, make the build command do it, for example:
pnpm turbo run build --filter=web
Because dply runs the command from the package folder, use your tool's filter flag rather than relying on the current directory.
Using build.root in dply.yaml
dply.yaml also accepts a build.root key, but it is not a substitute for Repository root. It changes where dply looks for the lockfile, Node version, and output directory, while your build command still runs from the folder dply.yaml was read from, and it does not affect checkout or which pushes deploy. Use Repository root for monorepos.