Building your application with Buildpacks

Buildpacks are automatically used if there is no Dockerfile in your source code directory.

Nodion needs an OCI-compatible image to run your application on our high performance infrastructure. Nodion automatically uses Cloud Native Buildpacks to convert your source code to an OCI image if there is no Dockerfile present. Buildpacks are based on so called Builders. You can select a Builder within your application settings. We currently support Builders from Google Cloud, Heroku as well as Paketo. Creating a new application results in Heroku 20 Buildpacks being used by default.

The idea behind buildpacks is that you don't need to have any knowledge about creating Dockerfiles or even Docker. You simply provide us with your source code and we make sure your application runs on our platform.

Supported languages by Buildpacks

By using the default settings when creating an application, we are able to convert your source code to OCI images when using the following languages:

  • Go1.10 +
  • Node.js10+
  • Ruby2.6+
  • PHP7.4+
  • Python3.7+
  • Java1.10+
  • .NET3.1+

Building your application with Buildpacks

The process to build your application is based on Builders automatically trying to find Buildpacks that are relevant for your application. This is called the detect stage. For example the PHP buildpack is searching for a composer.json or index.php file. If it finds one, the PHP buildpack is being used. Each Buildpack has a build stage, for example the PHP buildpack would be running composer install.

Sometimes one Buildpack is not enough, this is why Buildpacks can be combined. If your application needs to makes use of the FFmpeg library, you would need to install FFmpeg first, before your application is able to utilize it. This can be done by using a Buildpack to install FFmpeg, before the PHP Buildpack is being used. You can add a project.toml file to your source code that exactly tells our platform what to use and install.

Adding Packages

As described a common use-case is adding packages. Depending on the selected Builder all images are based on Ubuntu 22.04 LTS, 20.04 LTS or 18.04 LTS. You can add packages that will be installed via apt. To do so you can simply create an Aptfile and add it to the root directory of your application.

# you can list packages
libexample-dev

# or include links to specific .deb files
https://downloads.example.com/example.deb

# or add custom apt repos (only required if using packages outside of the standard Ubuntu APT repositories)
:repo:deb https://apt.example.com/ example-distro mainAptfile

Providing a Port

The most common mistake when using Nodion is not providing a port your application listens on. This is required so that our load balancers are able to connect to your instances. Please set a PORT environment variable with the port your application should be using.

Running your application with Buildpacks

Most applications need a start command, or in Docker terms they need an entrypoint. Think npm start for Node.js applications or java -jar for Java applications. This is the command that will be run when your application is being executed. Depending on the Builder in use the start commands might differ. For some languages it is required, since it's very hard to automatically detect.

This is why we recommend using a Procfile to declare exactly which entrypoint to use.

Procfile

Nodion supports the widely used Procfile to set start commands. You can provide a process type as well as the entrypoint within the Procfile. A Procfile for a regular Ruby on Rails application might look like this and has to be added to the root directory of your application:

web: bundle exec rails s -p $PORTProcfile

If you are using background workers and they need another entrypoint you can simply provide that by adding an additional line to the Procfile with a worker process type:

web: bundle exec rails s -p $PORT
worker: bundle exec sidekiqProcfile

If you have multiple workers attached to your application and they need different entrypoints, you can simply set a customer process type per worker:

web: bundle exec rails s -p $PORT
worker1: bundle exec sidekiq
worker2: bundle exec cronoProcfile

Release phase

If your application requires executing certain things like running database migrations when deploying, you can use the release process type within the Procfile. The release command will be executed before your regular instances are started. That means your database migrations were already performed when the new version of your application is getting started.

release: bundle exec rails db:migrate
web: bundle exec rails s -p $PORTProcfile

The release phase can also be used to run a whole bash script instead of a single command.

release: ./release-script.sh
web: bundle exec rails s -p $PORTProcfile