- 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_*, orREACT_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’spackage.json.
Example Dockerfile for the web frontend:
Nixpacks
You must create a separatenixpacks.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_CMDNIXPACKS_START_CMD
.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:
nixpacks.toml file for the API backend: