当您运行mix release时，它会将MIX_ENV的所有Elixir/Erlang依赖项、您在构建中使用的Erlang BEAM运行时/VM以及您在mix.exe的mix项目中指定的任何文件捆绑到发布目录中。
因为BEAM运行时和引导加载代码的代码包含在发行版中，所以您不需要在目标机器上安装Elixir或Erlang。

• 不 * 包括的内容包括：
• 例如，如果你依赖openssl，你需要确保你在你计划运行的机器上安装了一个二进制兼容的版本（通常是等价的主要版本）。
• 可移植的字节码。BEAM不像Java VM。编译后的BEAM代码需要运行在基本相似的架构上。例如，在Arm 64机器上构建，以便部署在Arm 64虚拟机上，或者在x86上构建，以便部署在与Intel兼容的硬件上。而且，最好使用相同的主要操作系统发行版。在某些情况下，“任何Linux * 相同的CPU架构”都可以，但例如，在Windows或MacOS上安装Elixir/OTP并在Linux上部署是不可行的;您需要使用足够相似的操作系统。

举个例子，我的一个项目使用Docker在Alpine上构建了它的版本，所以我们只需要担心CPU兼容性。在我们的例子中，我们确实需要确保我们的应用绑定的一些外部非Elixir依赖项包含在Docker映像中。

RUN apk add --no-cache libstdc++ openssl ncurses-libs wkhtmltopdf xvfb \
  fontconfig \
  freetype \
  ttf-dejavu

（忽略wkhtmltopdf有点过时的事实，我们正在研究它。但现在我们依赖的是一个非长生不老药依赖关系）。
如果您正在构建一个EC2示例，而没有使用Docker，那么您只需要确保您的版本构建在与生产所用的操作系统相似的操作系统上，并确保生产AMI（image）有那些非Elixir的依赖项，或者在部署的时候，可能会使用apt或其他包管理器。对于VPS，非酏剂依赖项的解决方案将取决于它们是否具有自定义基本计算机镜像的选项（可能具有Packer或Ansible）
由于您可能在评论中对此有点困惑，是的，MIX_ENV=prod mix release将构建您所有的生产Elixir/Erlang依赖项，并将它们包含在/_build/prod文件夹中。
我在我们的版本中包含了整个./prod文件夹，但它看起来像协议合并二进制文件和lib文件夹。

如果你做一个默认的构建，目标将在你的_build目录中，还有配置环境和你的应用的子目录，例如_build/dev/rel/your_app/。这个目录应该包含你运行你的应用所需要的一切--运行mix release后的提示提供了一些线索，比如：

Release created at _build/dev/rel/your_app!

但是，我发现将应用程序压缩成一个可移植的文件更有用（是，我同意如何做到这一点的细节不一定是你在阅读Elixir版本时看到的第一件事）。这通常通过专用的私有函数来完成，但是如何提供选项的组织由您决定。
我发现生成一个压缩的.tar.gz文件是很有用的，这可以通过指定include_executables_for选项和steps来完成，如下所示：

# mix.exs
defmodule YourApp.MixProject do
  use Mix.Project

  def project do
    [
      # ...
      releases: releases()
      # ...
    ]
  end

  defp releases do
    [
      my_app: [
        include_executables_for: [:unix],
        steps: [:assemble, :tar]
      ]
    ]
  end

当你以这种方式配置你的应用时，运行mix release将生成一个很好的可移植文件，其中包含你的应用所需的一切。解压缩此文件可以帮助你了解你的应用所需的一切。默认情况下，此文件将在类似_build/dev/yourapp-1.0.0.tar.gz的位置创建。你可以通过为你的应用指定path来配置构建路径。有关更多选项，请参见Mix.Release。