Buildpacks

Last updated October 14, 2024

Kinsta uses Nixpacks by default to build your application and set up the container image. Kinsta 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).

Supported languages

We support the following application languages for Buildpacks:

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 — Kinsta 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.

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	/layers/heroku_php/platform/bin/php or launcher php
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. The following are 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"
}

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

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"