Monorepos FAQ
Learn the answer to common questions about deploying monorepos on Vercel.Whether or not your deployments are queued depends on the amount of Concurrent Builds you have available. Hobby plans are limited to 1 Concurrent Build, while Pro or Enterprise plans can customize the amount on the "Billing" page in the team settings.
Learn more about Concurrent Builds.
After having set up your monorepo as described above, each of the directories will be a separate Vercel project, and therefore be available on a separate domain.
If you'd like to host multiple projects under a single domain, you can
create a new project, assign the domain in the project settings, and proxy
requests to the other upstream projects. The proxy can be implemented
using a vercel.json
file with the rewrites
property, where each
source
is the path under the main domain and each destination
is the
upstream project domain.
Pushing a commit to a Git repository that is connected with multiple Vercel projects will result in multiple deployments being created and built in parallel for each.
To access source files outside the Root Directory, enable the Include source files outside of the Root Directory in the Build Step option in the Root Directory section within the project settings.
For information on using Yarn workspaces, see Deploying a Monorepo Using Yarn Workspaces to Vercel.
Vercel projects created after August 27th 2020 23:50 UTC have this option enabled by default. If you're using Vercel CLI, at least version 20.1.0 is required.
Vercel CLI will accept Environment Variables instead of Project Linking, which can be useful for deployments from CI providers. For example:
VERCEL_ORG_ID=team_123 VERCEL_PROJECT_ID=prj_456 vercel
Learn more about Vercel CLI for custom workflows.
Yes. Turborepo is available on all plans.
When using Nx on Vercel with environment variables, you may encounter an issue where some of your environment variables are not being assigned the correct value in a specific deployment.
This can happen if the environment variable is not initialized or defined in that deployment. If that's the case, the system will look for a value in an existing cache which may or may not be the value you would like to use. It is a recommended practice to define all environment variables in each deployment for all monorepos.
With Nx, you also have the ability to prevent the environment variable
from using a cached value. You can do that by using Runtime Hash
Inputs . For
example, if you have an environment variable MY_VERCEL_ENV
in your project, you will add the
following line to your nx.json
configuration
file:
"runtimeCacheInputs": ["echo $MY_VERCEL_ENV"]
Was this helpful?