Despliegues sin tiempo de inactividad y actualizaciones en caliente

Restarting a server drops in-flight requests and live WebSocket connections. Zero-downtime deploys roll out new code while users stay connected and unaware.

The BEAM supports two upgrade paths:

• Rolling deploys: start new nodes, drain old ones — simple and common
• Hot code upgrades: swap code inside a running node without restart — powerful but complex

A rolling deploy boots a new release alongside the old, shifts traffic over via a load balancer, then shuts the old one down. Most teams use this because it is straightforward and tooling-friendly.

Load balancers need to know when a new node is ready. Expose a lightweight health endpoint that returns 200 only when the app can serve traffic.

Before stopping an old node, stop accepting new requests but let active ones finish. This draining avoids cutting users off mid-request.

Old and new code run side by side during a rolling deploy, so migrations must be backward compatible. Add columns before using them; never rename or drop in a single deploy.

The BEAM can replace a module's code in a live system. :code.load_file/1 loads the new version; running processes switch over on their next function call.

For full hot upgrades of a release, the BEAM uses appup files (per-application upgrade instructions) and relup files (release-level). Tools like Distillery could generate these.

A long-lived GenServer can migrate its state during a hot upgrade via the code_change/3 callback, reshaping old state into the new format.

Hot upgrades avoid any restart but are hard to test and reason about. Most teams prefer rolling deploys for predictability, reserving hot upgrades for embedded or always-on telecom-style systems.

Always have a rollback ready:

• Keep the previous release artifact
• Make migrations reversible or additive only
• Automate rollback in your deploy pipeline

You learned zero-downtime deployment:

• Rolling deploys drain old nodes while new ones serve
• Health checks tell the load balancer when a node is ready
• Migrations must be backward compatible
• Hot code upgrades swap code live via appup/relup and code_change
• Always keep a rollback plan

Users stay connected through every release.