Dyno Startup Behavior
Last updated December 03, 2024
Table of Contents
There are different parts to a dyno’s lifecycle. This article describes a dyno’s startup behavior.
.profile File Commands
During startup, the container starts a bash shell to run any code found in $HOME/.profile before executing the dyno’s command. You can put bash code in this file to manipulate the initial environment, at runtime, for all dynos in your app.
The .profile script is sourced after the app’s config vars. To have the config vars take precedence, use a technique like LANG:
# add vendor binaries to the path
export PATH=$PATH:$HOME/vendor/bin
# set a default LANG if it doesn’t exist in the environment
export LANG=${LANG:-en_US.UTF-8}
For most purposes, config vars are more convenient and flexible than .profile. You don’t need to push code to edit config vars, but you do to edit the .profile file.
Local Environment Variables
The dyno manager sets up a number of default environment variables that you can access in your application.
Cedar-Generation Apps
- If the dyno is a web dyno, we set the $PORT variable. The dyno must bind to this port number to receive incoming requests.
- The
$DYNOvariable set to the dyno identifier. For example,web.1,worker.2,run.9157. - The
$DYNOvariable value isn’t always unique within an app. For example, during a deploy or restart, two running dynos can have the same dyno identifier. The values eventually become consistent during normal operation.
Fir-Generation Apps
- The
$DYNOvariable for the dyno identifier won’t have sequential numbers and instead will have an auto-generated unique alpha-numeric string. For example,web-12a34b56d-e78f9,worker-23z34x56y-w78k9 - If the dyno is a web dyno the process needs to bind on IPv6 addresses on the specified
$POST:[::]:$PORT
Processes
After the .profile script executes, the dyno executes the command associated with the process type of the dyno. For example, if the dyno is a web dyno, then the command in the Procfile associated with the web process type executes.
Any command executed can spawn additional processes.
Heroku regularly reaps orphan processes to prevent the accumulation of defunct processes.
The maximum number of processes/threads that can exist in a dyno at any one time depends on dyno size.
Port Binding of Web Dynos
A web dyno must bind to its assigned $PORT for Cedar-generation apps, or [::]:$PORT in Fir-generation apps within 60 seconds of startup. If not, the dyno manager terminates it, resulting in a R10 Boot Timeout. Processes can bind to other ports before and after port binding.
If your application requires more time to boot, use the boot timeout tool to increase the limit as a temporary solution. In general, slow boot times make it harder to deploy your application and recovery from dyno failures.