Monorepo Support

If you’re using the same repo for multiple Render services, you will want to configure the code changes that trigger deploys for each service. Regardless of your project’s structure, changes to a specific file in your code don’t need to trigger builds and deploys for every service associated with the repo. Monorepo Support helps you deploy just the services you need to eliminate unnecessary deploys, control build costs, and ship faster.

Monorepo Support offers two configuration mechanisms. For any service running on Render, you can define a root directory and/or specify build filters to configure when the service is built and deployed in response to code changes.

Defining the root directory for a service ensures changes to files inside the root directory trigger a build and deploy. Changes to files outside the root directory will not trigger a build for the service.

Specifying build filters for a service allows you to use glob patterns to include and exclude individual file paths for which changes trigger a build.

Using root directory and build filters simplifies your build and deploy process. Changes are rolled out faster and any resulting notifications are relevant to the recent changes pushed to the Git repository.

Sample monorepo

Here’s an example of how a monorepo might be organized:

├── backend
│   ├── app # Generated at build time
│   ├── build
│   │   ├── amd64.sh
│   │   ├── quemu.sh
│   │   └── x86.sh
│   ├── main.go
│   ├── readme.md
│   └── util
│       ├── util.go
│       └── util_test.go
├── community
│   ├── docker
│   │   ├── Dockerfile
│   │   ├── docker-entrypoint.sh
│   │   └── setup.sh
│   └── readme.md
└── frontend
    ├── build # Generated at build time
    ├── components
    │   └── login.js
    ├── index.js
    ├── sample.ts
    └── src
        ├── auth.js
        ├── authn.js
        ├── authz.js
        └── readme.md

Root directory

Render will build and deploy your service when you push changes to file paths inside the defined root directory. Changes to file paths outside the defined root directory are ignored, and Render will not build and deploy your service.

The default value of a service’s root directory is the top-level directory of the Git repository. You can define the root directory for a service as any sub-directory of your Git repository. In the example monorepo above, backend and community/docker are possible definitions of the backend and community service’s respective root directory.

Defining the root directory

The root directory for a service can be defined from either the Render Dashboard or a Blueprint Spec.

Dashboard

1. In the Render Dashboard, open the Settings page for the service you want to configure.

2. Scroll down to the Build & Deploy section and find the Root Directory setting:

   

3. Click Edit.

4. Enter the root directory you want to use.

5. Click Save Changes.

6. In the dialog that appears, verify your service’s build and start commands (which will now run relative to the new root directory).

7. Click Update Fields.

Example Blueprint spec

For a monorepo like this sample, defining the root directory in a Blueprint Spec looks like the following:

services:
- type: web
  name: app-backend
  runtime: go
  rootDir: backend
  buildCommand: go build -o app .
  startCommand: ./app
- type: web
  name: app-community
  runtime: docker
  rootDir: community/docker
  dockerfilePath: ./Dockerfile
  dockerContext: .

Settings relative to root directory

Render runs commands and interacts with files relative to each service’s root directory. The service’s Build Command, Start Command, Publish Directory, Dockerfile Path, and Docker Build Context Directory are all affected by defining a root directory. Each of these commands and file paths must take the service’s defined root directory into account.

In a monorepo like this sample, without a defined root directory, the service’s Build Command might look something like the following:

cd backend && go build -o app .

Setting the service’s root directory to the backend directory simplifies the Build Command to the following:

go build -o app .

Build filters

Build filters allow you to build and deploy a service only when certain files change and to ignore all other changes.

In a monorepo like this sample, specifying build filters ensures that the frontend service is only deployed when changes to static files occur, and that the backend service is likewise only deployed when a change occurs in a Go file.

You can configure build filters for each Render service by using included paths, ignored paths, or both.

Included paths

Changing a file that matches a glob specified as part of the Included Paths list will start a new build. If Included Paths is empty, we default to matching all files.

Ignored paths

Changing a file that matches a glob specified as part of the Ignored Paths list will not start a new build. If Ignored Paths is empty, we do not ignore any files.

Files matching both Included Paths and Ignored Paths will be ignored and will not trigger a new build. For example, in a monorepo like this sample, adding backend/** as both an Included Path and Ignored Path would cause the backend directory to be ignored and changes to its contents will not trigger a new build.

Specifying build filters

You can specify build filters on the Render Dashboard or as part of a Blueprint Spec.

Dashboard

1. In the Render Dashboard, open the Settings page for the service you want to configure.

2. Scroll down to the Build & Deploy section and find the Build Filters setting:

   

3. Click Edit.

4. Click Add Included Path and/or Add Ignored Path as needed.

5. Enter the glob patterns for all paths you want to include and ignore.

6. Click Save Changes.

Example Blueprint spec

In a monorepo like this sample, the Blueprint Spec, would be something like:

services:
- type: web
  name: app-frontend
  branch: main
  runtime: static
  buildCommand: cd frontend; yarn; yarn build
  staticPublishPath: ./frontend/build/
  # Build and deploy `app-frontend` if any `js` file changes,
  # but ignore any test files.
  buildFilter:
    paths:
    - frontend/**/*.js
    ignoredPaths:
    - frontend/**/*.test.js

Glob syntax

Using root directory and build filters together

It is possible to simultaneously define the root directory and specify build filters for a service. In a monorepo like this sample, the Blueprint Spec might look like:

services:
- type: web
  name: app-backend
  branch: main
  runtime: go
  # Build and deploy `app-backend` if any files change
  # within the `backend` or `community/docker` folders.
  rootDir: backend
  buildCommand: go build -o app .
  startCommand: ./app
  buildFilter:
    paths:
    - community/docker/**

Pull request previews

Root directory and build filters enable you to control the creation of pull request previews for your services.

In this example monorepo, if you define the root directory as backend for the backend service; and if you then create a Pull Request that only changes files in the backend directory, Render will create a Pull Request Preview only for the backend service and will not create a Pull Request Preview for the frontend service.

services:
- name: app-backend
  rootDir: backend

The same is true for build filters. If you specify one or more build filter paths for the frontend service; and if you then create a Pull Request that only changes files that match those paths, Render will create a Pull Request Preview only for the frontend service and will not create a Pull Request Preview for the backend service.

services:
- name: app-frontend
  buildFilter:
    paths:
    - frontend/**/*.js
    ignoredPaths:
    - frontend/**/*.test.js

FAQ

Can I ignore the render.yaml file?

No, changes to render.yaml are always processed regardless of the patterns specified in buildFilter. Blueprint syncs are also unaffected by the buildFilter setting.

Do build filters apply to manual deploys?

A manual deploy will always trigger a build and deploy using the latest Git commit, regardless of any build filters.

What if I have autoDeploy turned off for a service?

Turning autoDeploy off prevents automatic deploys for your Render Service; however, root directory and build filters for that service will decide if Render should create a Pull Request Preview.

What if my service has no build filters?

Any new commit will trigger a build and deploy for services by default.

What if my service has no root directory?

The default root directory for a service is the top-level directory of the repository.

What happens when I update a setting that triggers a new build?

Updating your service’s Build Command or any other setting that triggers a new build will always deploy the latest Git commit from your repo.

Do build filters and root directory work with preview environments?

Yes. If you define the root directory or specify build filters for each service in your Blueprint Spec, Render will only create a Preview Environment if the files changed in a pull request match the root directory or build filter paths for at least one service.

If I change the root directory will it affect the build filters for my service?

Paths for build filters are always relative to the top-level directory of your repository, even if you’ve defined the root directory for the service. This makes it possible for you to define paths for a service’s build filters that are outside the root directory for that service.

If I change the root directory, will it affect auto-deploys for my service?

If you define the root directory for a service, Render will only build and deploy your service when you push changes within that root directory.

For example, if you define the root directory as backend, Render will build and deploy your service if you push changes to any files inside the backend directory and ignore any changes you push to other directories.

If I define the root directory, do I need to add that same path as a build filter?

You don’t have to add that same path as a build filter.

Defining the root directory for a service ensures changes to files inside the root directory trigger a build and deploy. Changes to files outside the root directory will not trigger a build for the service.