Dyno Startup Behavior
Last updated October 16, 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:
- 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
$DYNO
variable set to the dyno identifier. For example,web.1
,worker.2
,run.9157
. - The
$DYNO
variable 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.
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
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 binding to $PORT
.
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.