How a build works
- Sevalla clones the repository at the deployment’s commit, with its submodules and, unless you turned it off, its Git LFS files.
- The builder runs in the build path (or the Docker context) on a build machine, with the build-time environment variables and, when it’s on, the build cache.
- Sevalla pushes the image to the application’s private registry, then rolls it out to every process. See Deployments.
Choose a build strategy
New applications from Git use Nixpacks 1.41. Change the strategy when your language isn’t detected, when you’re moving from a platform that uses another builder, or when you need full control.
With Nixpacks, Railpack and Buildpacks, the web process’s start command (on the Processes tab) overrides the start command the builder detects. Leave it empty to use the detected one.
Update the build strategy
You need permission to update the application. The build strategy applies to Git sources only.
1
Open the build strategy
In the sidebar, click Applications, then click the application. On the Settings tab, in the Build strategy section, click Update build strategy. The same sheet opens from Update build strategy on the Deployments tab.
2
Choose the builder
Click Nixpacks, Railpack, Buildpacks or Dockerfile, then fill in its settings.
3
Save
Click Update build strategy.
4
Deploy
The change takes effect with the next deployment. Click Deploy in the undeployed changes bar, or deploy from the Deployments tab.
Build settings
Paths can use letters, digits,
., _, -, / and \, up to 400 characters. Otherwise the sheet shows Path contains invalid characters. or Must be at most 400 characters.
Build cache
With Cache enabled, each build starts from the image of the application’s latest successful deployment: steps whose inputs didn’t change, such as installing unchanged dependencies, are reused instead of run again. The first build of an application, and the first build after you turn the cache on, run in full. Turn the cache off to force a clean build, for example when a cached layer keeps a broken dependency. Clear Cache enabled in the Update build strategy sheet, deploy, then turn it back on. The Build cache row in the Build strategy section shows Enabled or Disabled.Environment variables during the build
The build gets every environment variable marked Available during buildtime: the application’s own and the company’s global variables, with the application’s value winning when both set the same key. New variables are available during both build and runtime by default. How each builder receives them:
A variable changed after a build isn’t in that build’s image. If your framework inlines variables into the bundle at build time (for example
NEXT_PUBLIC_* in Next.js or VITE_* in Vite), deploy with a new build after you change them, not a restart.
Avoid $ in build-time values: the build shell can expand it. See Special characters.
Sevalla also sets its own SVL_* variables during the build, such as SVL_APP_ID, SVL_DEPLOYMENT_ID, SVL_DEPLOYMENT_COMMIT_SHA and SVL_DEPLOYMENT_BRANCH. It doesn’t set PORT during the build, only at runtime. See Variables Sevalla sets.
Build machine
Every build runs on a build machine with 4 vCPU and 8 GB of memory. The Build resources row in the Build strategy section shows it; you can’t change it in the dashboard. Build time is billed per minute; see Pricing.Time limit
A deployment has 30 minutes to clone, build and roll out. If it runs longer, it fails; see Time limits and failures. To make builds faster, keep the build cache on, build only the folder you need with the Build path, and exclude files the build doesn’t need (for example with.dockerignore for a Dockerfile).
Read the build log
On the application’s Deployments tab, click the deployment, then the Build log tab. The log streams while the build runs and stays with the deployment afterwards. A failed build ends with the error that stopped it; Troubleshoot builds and deployments explains the common ones.API and CLI
In the API,
build_type is nixpacks, railpack, pack (Buildpacks) or dockerfile.