Blue-green release swaps and in-process hot upgrades for a single Elixir node.

BeamDeploy keeps a long-lived parent node running locally and serves traffic from a child peer node started with OTP's :peer module. When you hand the parent a new mix release tarball, it boots a new peer with the new release, lets both peers overlap on the same socket via SO_REUSEPORT, then gracefully shuts down the old one.

The package is intentionally small:

• no storage, polling, or orchestration layer
• no Docker or platform coupling
• local tarball input only

You copy a release tarball onto the host and call either:

• BeamDeploy.upgrade/1 for a blue-green peer swap
• BeamDeploy.hot_upgrade/2 for an in-process hot code reload

Integration

defmodule MyApp.Application do
  use Application

  def start(type, args) do
    BeamDeploy.start_link(
      otp_app: :my_app,
      start: {__MODULE__, :start_app, [type, args]},
      endpoint: MyAppWeb.Endpoint
    )
  end

  def start_app(_type, _args) do
    children = [MyApp.Repo, MyAppWeb.Endpoint]
    Supervisor.start_link(children, strategy: :one_for_one, name: MyApp.Supervisor)
  end
end

Enable parent/peer mode in production with either:

config :beam_deploy, enabled: true

or:

BEAM_DEPLOY=true

In environments where BeamDeploy is not enabled, start_link/1 and start_link/2 just call your start_app MFA directly.

Upgrades

BeamDeploy.upgrade("/tmp/my_app-0.2.0.tar.gz")
# => :ok

BeamDeploy.hot_upgrade("/tmp/my_app-0.2.0.tar.gz", otp_app: :my_app)
# => :ok

The tarball must be a standard mix release archive built with the same OTP version as the running node.

Hot upgrades are only safe for compatible code changes. Use a cold deploy or the blue-green path instead when changing supervision tree shape, upgrading Erlang/OTP, changing major runtime topology, or touching NIFs.