 
   TODO: Implement custom vm.args.
 
-  ## Internals
-
-  This section covers some details about how releases are assembled.
-
-  ### Structure of a release
-
-  A release is orgnized as follows:
+  You may also set `ELIXIR_ERL_OPTIONS` inside `bin/start` to dynamically
+  set VM options.
+
+  ## Directory structure and environment variables
+
+  A release is organized as follows:
 
       bin/
         RELEASE_NAME


  embed_template(:start, ~S"""
  #!/bin/sh
  set -e
  HEART_COMMAND="$(dirname "$0")/start"
  export HEART_COMMAND
  # Feel free to edit this file in anyway you want
  # To start your system using IEx: "$(dirname "$0")/<%= @name %>" start iex
  # To start it as a daemon using IEx: "$(dirname "$0")/<%= @name %>" daemon iex
  "$(dirname "$0")/<%= @name %>" start

        COOKIE
        start_erl.data

  Furthermore, the system can be configured and sets the following
  environment variables:

    * `RELEASE_ROOT` - points to the root of the release. If the system
      includes ERTS, then it is the same as `:code.root_dir/0`

    * `RELEASE_NAME` - the name of the release. It can be overridden on
      `bin/start` to a custom value

    * `RELEASE_VSN` - the version of the release, otherwise the latest
      version is used. It can be overridden on `bin/start` to a custom
      value

    * `RELEASE_COOKIE` - the release cookie. By default uses the value
      in `releases/COOKIE` . It can be overridden on `bin/start` to a
      custom value

    * `RELEASE_NODE` - the release node name, in the format `name@host`.
      It can be overridden on `bin/start` to a custom value

  ## Hot Code Upgrades

  Erlang and Elixir are sometimes known for the capability of upgrading
  a node that is running in production without shutting down that node.
