Last updated December 03, 2024

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

Fir-Generation Apps

• The $DYNO variable 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.

Additional Reading

• Dyno Lifecycle
• Dyno Restarts
• Dyno Shutdown Behavior
• R10 Boot Timeout