Skip to main content
Turborepo is a framework-agnostic tool for efficiently managing monorepos. It includes the following features:
  • Turborepo build system - Intelligent build orchestration with incremental builds.
  • Parallel execution - Run tasks across multiple packages simultaneously with automatic CPU optimization.
  • Task pipelines - Define dependencies between tasks to ensure optimal execution order.
  • Workspace management - Organize multiple packages and apps in a single repository.
  • Incremental adoption - Add Turborepo to existing monorepos without refactoring.
  • Selective task execution - Run tasks only for packages affected by your changes.
  • TypeScript support - Full TypeScript configuration across all workspaces.
  • Framework agnostic - Works with Next.js, React, Vue, Express, and any JavaScript/TypeScript framework.

​
Configuration

In Sevalla, each application instance can host only a single app. Therefore, in Monorepos with workspace dependencies (packages/*), your services must be built from the repository root directory to access all workspace packages and ensure all dependencies resolve correctly.
To do this, all you need to do is ensure that your build and start commands are specific to the service you wish to deploy. Refer to our examples in the containerization section for guidance on how to achieve this.

​
Environment variable types

  • globalEnv: Variables that apply to every task and invalidate the cache when changed. Use these for settings that impact all builds, such asNODE_ENV, DATABASE_URL.
  • Task-specific env: Variables scoped to individual tasks only. These help avoid unnecessary cache invalidation by limiting their impact to the tasks that actually use them.
  • Framework variables: Variables like NEXT_PUBLIC_*, VITE_*, or REACT_APP_* are automatically detected by Turborepo and will invalidate the cache when modified. Use these for client-exposed configuration.
  • passThroughEnv: Variables that are passed to tasks but do not affect cache keys. Ideal for runtime-only values that should not trigger new builds, such as secrets or tokens that don’t alter the build output.

​
Containerization

​
Dockerfile

You must create separate Dockerfiles for each application, the web frontend, and the API backend, located in the repository’s root directory. After creating each application in Sevalla, assign the correct Dockerfile to the corresponding service within Applications > application name > Settings > Update build strategy. Inside each Dockerfile, make sure to use the appropriate build and start commands defined in that application’s package.json. Example Dockerfile for the web frontend:
Example Dockerfile for the API backend:

​
Nixpacks

You must create a separate nixpacks.toml file for each application, the web frontend, and the API backend, located in the repository’s root directory. Alternatively, you can use the following Nixpacks environment variables to specify the build and start commands:
  • NIXPACKS_BUILD_CMD
  • NIXPACKS_START_CMD
You can control the Node.js version used during the build by using an .nvmrc file, the engines field in package.json, or the NIXPACKS_NODE_VERSION environment variable. If none are set, Nixpacks defaults to Node.js 18. Example nixpacks.toml file for the web frontend:
Example nixpacks.toml file for the API backend: