Skip to main content
Nixpacks is an open-source builder from Railway that detects your application’s language and framework from the repository and builds a container image with no configuration. It’s Sevalla’s default build strategy: every new application from Git builds with Nixpacks 1.41. The Nixpacks project is in maintenance mode; Railpack is its successor.

​
How Nixpacks builds your application

Nixpacks reads the files in the build path to pick a provider (for example package.json for Node.js or requirements.txt for Python), then builds in four phases, which the build log prints as a table: If the web process has a start command on the Processes tab, Sevalla passes it to Nixpacks and runs it instead of the detected start command.

​
Supported languages

Nixpacks detects Clojure, Cobol, Crystal, C#/.NET, Dart, Deno, Elixir, F#, Gleam, Go, Haskell, Java, Lunatic, Node.js (with npm, Yarn, pnpm or Bun), PHP, Python, Ruby, Rust, Scala, Scheme, Swift, Zig, and static files. The Nixpacks providers documentation describes how each is detected and built. For anything else, use a Dockerfile.

​
Use Nixpacks

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.
2

Choose Nixpacks

Click Nixpacks. Set the Build path if the application isn’t at the repository root, and choose the Nixpacks version.
3

Save and deploy

Click Update build strategy, then deploy the application.
The deployment’s build log starts with a Nixpacks v1.41.0 table (or the version you chose) listing the four phases.

​
Nixpacks version

Newer versions add language versions and change defaults, so a version change can change how your application builds. Read the Nixpacks release notes before you switch, and pin your language version in the repository so the build doesn’t depend on Nixpacks’ default.

​
Set the language version

Without a version in your repository, Nixpacks uses its own default for the language, which depends on the Nixpacks version. Set the version in your files, or with an environment variable marked Available during buildtime.
package.json
Nixpacks 1.41 installs Python 3.12 when the repository doesn’t set a version. It doesn’t fail on a version it doesn’t support, such as 3.14: it builds with Python 3.12 instead, so check the setup phase in the build log. For Python 3.14, use Railpack or a Dockerfile. PHP extensions come from composer.json too: add them to require, for example "ext-redis": "*" or "ext-imagick": "*". Python dependencies and their versions come from your dependency file (requirements.txt, poetry.lock, uv.lock, Pipfile and others); set NIXPACKS_PYTHON_PACKAGE_MANAGER to force one.

​
Configure the build

Most applications build with no configuration. To change a phase, add a nixpacks.toml file to the build path:
nixpacks.toml
"..." keeps the packages Nixpacks detects and adds yours. The Nixpacks configuration file reference lists every key. The same settings work as environment variables marked Available during buildtime: A start command set on the web process wins over nixpacks.toml and NIXPACKS_START_CMD. Define other processes, such as workers, on the Processes tab.

​
Procfile

Nixpacks reads a Procfile in the build path. Its web entry (or worker, or else the first entry) becomes the image’s start command; a start command on the web process still wins. Sevalla doesn’t create processes from the other entries: create them on the Processes tab. A release entry runs once, as the last step of the build, not before each deployment. It doesn’t run on restarts, rollbacks or promotions, and it gets only the variables available during the build. For release tasks such as database migrations, remove the release entry and create a job with the start policy Before deployment.

​
Frequently asked questions

Yes. When the repository has a composer.json, Nixpacks installs PHP and runs Composer to install its dependencies. Declare PHP extensions in the same file’s require section.
In your dependency file, for example Django==5.1 in requirements.txt. Set the Python version itself with a .python-version file.
Check the Build path: Nixpacks looks for the language’s files in that folder, not in the repository root. If the language isn’t supported, switch to Railpack or a Dockerfile.