Yunohost App Package to Systemd Service Migration Without Downtime

Answer to the core question

On a stock Yunohost installation the default yunohost app upgrade workflow stops the app’s systemd unit before applying changes. This means a short period of unavailability is unavoidable unless the package itself is written to support a parallel‑instance upgrade pattern.

Confirmed facts (based on current Yunohost design)

• The upgrade script calls systemctl stop on the unit that represents the app.
• Systemd cannot replace a running binary without stopping the unit, unless the application implements a graceful reload (e.g. via SIGHUP).
• Nginx supports an atomic reload: nginx -s reload starts new workers with the updated config while old workers finish current requests.
• Yunohost assumes a single instance per domain; shared resources such as the SSOWAT authentication layer, database credentials, and cron jobs are not designed for concurrent instances.

Likely explanation for why true zero‑downtime is hard

To avoid a stop, you would need to run two copies of the application side‑by‑side on different ports, point Nginx to the new upstream, reload Nginx, and then stop the old copy. This blue‑green pattern only works if the app can:

• listen on a configurable port that can be passed to systemd.
• shut down gracefully on SIGTERM (drain in‑flight requests) and start up without needing data that would be lost during the switch.
• share session state (database, Redis, etc.) or be able to duplicate it between instances.
• be packaged so that the upgrade script can launch a second unit before stopping the first.

Because Yunohost’s package templates and the SSOWAT layer are built around a single instance, most applications will not support this pattern out of the box. Adding the necessary hooks would require modifying the package’s install, upgrade, and systemd unit files, and would break the usual backup/restore semantics.

What you can do in practice

1. Check whether the application exposes a command‑line flag or environment variable that lets it bind to an arbitrary port.
2. Verify that the app can be started with a second instance while the first is still running (e.g. by running it manually on a different port).
3. If both instances can run, create a second systemd unit that points to the new port and start it before stopping the original unit.
4. Configure Nginx with an upstream block that can be updated atomically to the new port and reload Nginx.
5. After the reload, stop the old unit.

Each of these steps must be tested in a staging environment first. The approach will still involve a brief moment where the old unit is stopped, but the traffic loss can be limited to the reload window.

Missing diagnostic detail

Does the target application support graceful shutdown (e.g. drains requests on SIGTERM) and share session or state data (database‑backed sessions, Redis, etc.)? If not, the blue‑green pattern will likely cause session loss or data corruption, making a true zero‑downtime migration infeasible.