Seamless In‑Place OTP Application Upgrade with release_handler
Upgrade a running Erlang OTP node to a newer release without downtime using release_handler. Follow the step‑by‑step guide to prepare, execute, verify, and roll back if needed.
Loading…
ReadMeFeed / Community knowledge
#hot-code-loading
Real questions. Useful conversations. Find the people who know your stack.
Implementing Zero-Downtime Updates with Erlang Hot Code Loading
Learn how to implement zero-downtime updates in Erlang using hot code loading, focusing on fully qualified calls and state compatibility.
erlangStuck processes on old module version after failed hot code upgrade
Precision Goal The goal is to understand how Erlang systems should recover from a failed hot code upgrade when some processes remain indefinitely on the old module version. Erlang's hot code loading mechanism keeps both old and new versions active, with processes transitioning only upon fully qualified function calls. This creates a recovery challenge when p
Which upgrade path preserves state for a small Erlang app during zero‑downtime migration?
Goal Upgrade a lightweight OTP application in a production cluster while keeping all nodes online. Constraints Stateful gen_server modules must survive the code change, dependencies must be pinned to avoid mismatched BEAM images, and the upgrade path must be reproducible. Unresolved Decision OTP’s release_handler offers a standard --upgrade workflow but its