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 > Update settings).

You can choose which Heroku builder to use for your application. It is your responsibility to ensure this is compatible with your application by checking the Buildpacks and Builder changelogs for your application’s language.

​
Supported languages

We support the following application languages for Buildpacks:

  • Node.js
  • Ruby
  • Python
  • Java
  • Scala
  • PHP
  • Go

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 > Update settings > Add buildpack. To remove or change the order of your application’s buildpacks, click Build > Update settings.

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 Build > Update settings.

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:

LanguageDirectory
Node.js/layers/heroku_nodejs-engine/dist/bin/node
Ruby/usr/bin/ruby
Python/usr/bin/python
Java/layers/heroku_jvm/openjdk/bin/java
ScalaScala 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/
GoGo 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"