When you deploy an application built from source, the platform runs a build: it takes a version of your code and turns it into the thing that runs. This page is about builds from code; a Docker image has no build step.
What a build does
A build runs in its own throwaway guest, so your build cannot affect anything else. On success that guest becomes the application's release and starts serving; on failure it is thrown away and the release that was already running keeps running. You watch it live on the build log: Queued, then Building, then Succeeded or Failed.
Builders
The builder decides how your code becomes runnable:
| Builder | What it does |
|---|---|
| Detect automatically | Reads your repository and picks the right tools. The default |
| Dockerfile | Builds the Dockerfile at the root of your repository |
| Buildpacks | Cloud Native Buildpacks, which detect your language and build it |
| Railpack | Railway's builder, which covers some languages the others do not |
| Nixpacks | Railway's older Nix-based builder |
Detect automatically looks for a Dockerfile first, then tries Railpack, then
Buildpacks. It does not select Nixpacks on its own, so choose Nixpacks
explicitly if that is what you want.
You set the builder on the create form and can change it later under Configure your application or for a single deploy from the deploy menu.
What triggers a build
- The Deploy button on the application.
- A push to a connected GitHub branch with Deploy on push turned on.
A change to environment variables does not trigger a build. It stages a new release with the new configuration and the existing build, which you then deploy.