   the `RELEASE_TMP` environment variable, either explicitly or inside your
   `releases/RELEASE_VSN/env.sh` (or `env.bat` on Windows).
 
-  The `releases/RELEASE_VSN/env.sh` script can also be used to perform
-  limited runtime configuration via Erlang `-app` flags. For example, if
-  you want to make sure the Erlang Distribution listens only on a given
-  port known at runtime, you can set the following:
-
-      export ELIXIR_ERL_OPTIONS="-kernel inet_dist_listen_min $BEAM_PORT inet_dist_listen_max $BEAM_PORT"
-
-  Or for Windows, in your `releases/RELEASE_VSN/env.bat`:
-
-      set ELIXIR_ERL_OPTIONS=-kernel inet_dist_listen_min %BEAM_PORT% inet_dist_listen_max %BEAM_PORT%
-
-  See the "Customization" section to learn exactly how to provide a custom
-  `releases/RELEASE_VSN/env.sh` file.
-
   ### Config providers
 
   Releases also supports custom mechanisms, called config providers, to load

      set to `false` with caution and only if you are assembling the release on the
      same server that runs it.

  Also see the "Customization" section for other options and the hooks
  available to customize your release.

  Other features, such as runtime configuration, may introduce their
  options. Those will be listed in their own respective sections.

  ## Configuration

  Releases provides two mechanisms for configuration: built-time and
  runtime.

  ### Build-time configuration


  their respective supervision trees will stop, one by one, in the
  opposite order that they were started.

  ## Customization

  There are a couple ways in which developers can customize the generated
  artifacts inside a release.

  ### Options

  The following options can be set inside your mix.exs on each release definition:

    * `:applications` - a keyword list that configures and adds new applications
      to the release. The key is the application name and the value is one of:
