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 +
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
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
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.
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.
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
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