Buildpacks
Sevalla uses Nixpacks by default to build your application and set up the container image. Sevalla also offers Buildpacks, an open-source project maintained by Heroku, as one of the options to automatically determine and create a container for your application based on your repository. Buildpacks are scripts that are run when your application is deployed to install dependencies for your application and configure your environment.
You can choose Buildpacks by changing the Build environment option in application settings (Settings > Build > Change environment).
Sevalla always uses the latest recommended Heroku builder and Buildpacks. Sometimes, this may cause changes to the build process; it is your responsibility to keep up-to-date with the latest changes by checking the Buildpacks and Builder changelogs for your application’s language.
Supported languages
We support the following application languages for Buildpacks:
If you do not specify a version in your application’s code, the buildpack uses the latest available version.
If you want to use a different language version for your application, you’ll need to set the version in your application’s files.
If you want to use a language that is not a supported Buildpack language, you can first check to see if it’s a supported language with Nixpacks. If it isn’t, you must use a Dockerfile.
Configure Buildpacks
Some applications require no configuration, but some require specialized commands and options to run, such as:
Environment variables — You may need to set certain environment variables to run your application.
Processes — Sevalla can automatically detect your web process command. You can change this if required, and you can define additional processes.
Processes in a Procfile — You may want to define your processes in a Procfile within your application’s code.
Add or edit Buildpacks
You can manage buildpacks on your application’s Settings page. To add additional build packs, click Build > Add buildpack. To remove or change the order of your application’s buildpacks, click Build > Edit buildpacks.
When you add a buildpack, it’s automatically added to the end of the buildpacks list, so you may need to edit the order of your buildpacks. You can drag and drop the buildpacks to change their order in the Edit buildpacks modal/pop-up.
The buildpack that contains the primary language of your application must be the last one in the buildpacks list. For example, if you have a Node.js application and need to add another buildpack, make sure the Node.js build pack is at the end of the list.
Buildpack binary directories
With buildpacks, the binary directories may differ from the default binary directories for the application language. The following table shows the binary directories used for each buildpack language:
| Language | Directory |
|---|---|
| Node.js | /layers/heroku_nodejs-engine/dist/bin/node |
| Ruby | /usr/bin/ruby |
| Python | /usr/bin/python |
| Java | /layers/heroku_jvm/openjdk/bin/java |
| Scala | Scala doesn’t have a specific default binary path like some other compiled languages. When you compile a Scala program, it generates bytecode that runs on the Java Virtual Machine (JVM). The compiled Scala classes are typically stored in a directory structure that mirrors the package structure of your code. This is similar to how Java classes are organized. By default, when you compile a Scala source file, the compiled .class files will be placed in the same directory as the source code (within a subdirectory structure based on the package declarations). If needed, you can install Scala’s runtime tools using a Dockerfile instead of a buildpack. |
| PHP | /workspace/.heroku/php/bin/ |
| Go | Go doesn’t have a specific default binary path like some other compiled languages. When you compile a Go program, the resulting binary executable is typically placed in the same directory as your source code by default. If needed, you can install Go’s runtime tools using a Dockerfile instead of a buildpack. |
Set a Buildpack’s language version
When you select the option to use Buildpacks, if you do not specify a version in your application’s code, the Buildpack will use the latest available version. If you want to use a different language version for your application, you’ll need to set the version in your application’s files.
The method for setting the version varies by language. Below we’ve included examples for currently supported languages.
Go
To specify your Go version, include the following in your application’s go.mod file:
// +heroku goVersion go1.11
go 1.21.1
Java
To specify your Java version, include the following in your application’s system.properties file:
java.runtime.version=11
Node.js
To specify your Node.js and npm versions, include the following in your application’s package.json file:
"engines": {
"node": "^16.14.0",
"npm": "^8.3.1"
}
Specifying the npm version isn’t usually necessary (npm is bundled with Node.js). Setting the npm version is only needed when you want to use a different version than the one bundled with your version of Node.js
React
If you’re using React and want to specify your React version, replace or add the React version in the dependencies of your package.json file:
"react": "^17.0.2"
To also set the Node.js and npm versions in your React application, include the following in your application’s package.json file:
"engines": {
"node": "^16.14.0",
"npm": "^8.3.1"
}
PHP
Buildpacks support the currently supported PHP versions; once a PHP version reaches end-of-life, it is no longer supported but remains available so you can upgrade your application to a newer version.
To specify your PHP version, include the following in your application’s composer.json file:
{
"require": {
"php": "~8.1.0"
}
}
PHP.ini
You can change PHP.ini settings using a .user.ini file in the same directory as the .php file. For more information about which settings you can control, refer to the PHP manual.
A small set of PHP.ini configuration directives cannot be modified using .user.ini; for example, always_populate_raw_post_data and PHP_INI_SYSTEM. In this case, you must pass additional configuration settings for PHP at startup time using a custom configuration file fpm_custom.conf with the php_value and php_flag directives.
If you use a custom configuration file, you must tell your application to start with this configuration by adding -F to the start command. You can also use this configuration file to modify the PHP-FPM behavior.
Python
To specify your Python version, include the following in your application’s runtime.txt file:
python-3.10.13
You can also specify module versions within the requirements.txt file:
Django==4.1
virtualenv==20.18.0
Ruby
To specify your Ruby version, include the following in your Gemfile:
ruby "3.0.6"
Scala
To specify your Scala version, include the following in your application’s build.sbt file:
scalaVersion := "3.2.2"