Railway uses Nixpacks to build and deploy your code with zero configuration.
Currently, we support the following languages out of the box.
Nixpacks has a variety of options that can be configured with environment variables. These include things like
- Install/build/start commands
- Nix/Apt packages to install
- Directories to cache
For a full list of these options, please view the Nixpacks docs.
If using the Nixpacks builder, you can customize the build command that is run. For those familiar with Nixpacks, this gets set as the
--build-cmd argument during the Nixpacks build.
The root directory defaults to
/ but can be changed for various use-cases like
monorepo projects. When specified, all build and deploy
commands will operate within that root directory. Additionally, files changed
outside the root directory will not trigger a new build.
Watch paths are
that can be used to trigger a new deployment based on what file paths have
changed. For example, a monorepo might want to only trigger builds if files are
changed in the
/packages/backend directory. When specified, any changes that
don't match the patterns will skip creating a new deployment. Multiple patterns
can be combined, one per line.
Note, if a Root Directory is provided, patterns still operate from
/. For a root directory of
/app/**.js would be used as a pattern to match files in the new root.
Here are a few examples of common use-cases.
Note, negations will only work if you include files in a preceding rule.
With Nixpacks, we analyze the app source directory and generate a build plan. This determines which language provider to install packages and runtimes for.
If there is a detected
nixpacks.toml file, it is possible to define a build provider ahead of time like so:
Within your Service's settings, under the Builds section, you can define within the multi-select box which Nixpacks language providers you would like to use for your builds. This is useful if you have code that calls libraries that need to be built from another language within your repo.
When multiple providers are defined, Railway will build your service with the language providers (in the order you defined) and ensure your binaries are ready to be called. The runtime(s) will then initialize as soon as you start your application.
If using Nixpacks, you can override the start command with a Procfile at the root of your app. Only a single process type is supported at the moment.
HTTP servers should use the
web process type. This process should listen on
the PORT environment variable and will receive
Note: some buildpacks specify a default start command
We will also build using a Dockerfile if found at the project root.
Edit this file on GitHub