When Umbrel auto-updates apps from the app store, it restarts apps that were manually stopped by the user, re-enabling autoStart. Apps I intentionally turned off come back to life silently after an update cycle.
Expected Behavior
If I stop an app through the dashboard, it should remain stopped regardless of whether it receives an update. The update should be applied but the app’s stopped state should be preserved.
Actual Behavior
The update process stops the app, applies the update, then restarts it — even if the app was already stopped. This also flips the autoStart flag, so the app starts again on every subsequent reboot.
How I Discovered This
I had around 15 apps intentionally stopped on my Umbrel instance (v1.5.0). After a reboot I found all 40 installed apps running simultaneously, which exhausted system memory — swap thrashing, load average in the hundreds, SSH and web UI completely unresponsive.
Digging through journalctl logs, I traced it to an automatic app store update. The logs show umbreld updating and restarting over a dozen apps that were stopped at the time. After the next reboot, none were skipped — autoStart had been re-enabled on all of them.
Impact
This can be destructive. Users who carefully manage which apps are running to stay within their hardware limits will have their system brought down by a background update silently re-enabling everything. In my case the system became completely unresponsive and I lost access to all services, including ones handling financial transactions. The only recovery was a hard power cycle, which didn’t even fix the problem since autoStart was now enabled on everything — the system just crashed again on boot.
Suggested Fix
The update process should preserve the app’s current autoStart state. If an app is stopped, the update should either:
-
Defer the update until the user manually starts the app, or
-
Apply the update but not restart the app, keeping autoStart disabled