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.
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 Buildpack Builders
Most programming languages are supported by buildpacks. The language and version support varies depending on the buildpack builder in use. We support all major buildpack builders, namely:
- Paketo Base (22)
- Paketo Full (22)
- Paketo Static (22)
- Paketo Tiny (22)
- Heroku (24)
- Google (22)
- Paketo Base (18) [EOL]EOL Date: 31.07.2025
- Paketo Full (18) [EOL]EOL Date: 31.07.2025
- Paketo Tiny (18) [EOL]EOL Date: 31.07.2025
- Heroku (22) [EOL]EOL Date: 31.12.2025
- Heroku (20) [EOL]EOL Date: 31.07.2025
- Google (18) [EOL]EOL Date: 31.07.2025
Please note that for security reasons buildpack builders marked as EOL will be removed from our platform by the provided EOL date. Applications will continue to run after that day, but new deployments will have to be made with a supported builder. Please make sure you upgrade your applications accordingly.
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.
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