The Nodion File allows you to configure how your application should be deployed. There are certain defaults with which our system tries to make your application available, but it's always better to be explicit and configure a fixed environment your application should run in.
A Nodion application is based on one of our Native Environments and can be extended with Databases, Workers and/or be connected to our object storage buckets. To configure how Nodion should handle your application you have to create a nodion.yml file in the root directory of your Git repo.
While basic things can be configured via our web interface, the Nodion File is always prioritized. With every deploy our system checks if a Nodion File is present and if yes it will override configurations made in our web interface. This is why we recommend having a Nodion File right from the beginning.
nodion: env: ruby version: 2.7 port: 3000 build_command: bundle start_command: puma -e production
What happens here is that we select the Native
ruby Environment. If we would not set this, Nodion tries to auto-detect based on your repositories content. For example for Ruby our system would look for a "Gemfile". If the file is present it would automatically set it to the Ruby environment.
Next we have the Ruby version our application needs. We support the most common versions, please check the docs page of the Native Environment to see which versions are exactly supported.
The port is needed to connect our load balancing system to your application. If there is no health check set up and this is not properly set, requests to your application might result in a Bad Request error.
The build command is used to run commands before the application is started. This could be used to run database migrations, install libraries or simply prepare your application. You can either add and chain the commands in the yaml file or run a bash script.
The environment your application should run in. The following options are allowed:
ruby, php, node, static
The version of the environment your application should run in. Depending on the environment we support different versions. Please check the docs page of each technology to view supported versions.
Setting the port allows the webserver and/or load balancer to connect to the application on the correct port. If this is not properly set, requests to your application might result in a Bad Request error.
Run commands before your application is started. For example installing components or running database migrations. This either takes the commands, which could also be chained like
yarn && yarn build or you can call a bash script, for example
You can start your application by setting this command.
The publish directory can be used for static sites to set the output dir, for example "/dist" or "/build". Our system will take the publish directory and serve requests to this directory.
This argument is mostly relevant for mono repos. If you have multiple directories in your repo you can set a prepend directory, which will automatically be added before running the build and start command. This way you don't have to cd into the directory first.
To make sure deployments are successful you are able to add a health check endpoint to your application. For example you could add an endpoint that accepts a
GET request to
/health. This way our system will send the request to this endpoint before switching to a new deployment and only switch over to the new version if the endpoint returns a
200 OK status code. You could also add internal checks (for example database queries) to make sure everything is running.
If you add the
/health endpoint to your application, the value for this argument would be