Stalwart v1.0.0 (26 Oct 2026) ships a new data store layout, so v0.16.x
deployments cannot be upgraded in place. Data has to be copied into a new,
empty v1 store with stalwartlabs/stalwart-migrate, which requires v0.16.27
as its source version and needs an interactive prepare step plus an offline
final cutover.
The update path pulled "latest" and would have swapped the binary for v1 on
existing containers, leaving the mail server unable to start on its old store.
Pin install and update to v0.16.27 instead and surface the reason through
check_for_gh_release. Containers that already pulled v1.0.0 are put back on
v0.16.27 by the next update run.
mise 2026.10.19 defaults lockfile_mode to generate, which locks every platform during mise install. Immich's mise.toml enables the lockfile, and Java 21.0.2 has no linux-arm64-musl build, so the update failed on any host. Fixes#18236
* Add honcho (ct)
* Clean up comments in honcho-install.sh
Removed comments about Dockerfile and Honcho client build conditions for clarity.
* Remove admin key printing from setup output
Removed the command to print the admin key from the setup output.
---------
Co-authored-by: push-app-to-main[bot] <203845782+push-app-to-main[bot]@users.noreply.github.com>
Co-authored-by: CanbiZ (MickLesk) <47820557+MickLesk@users.noreply.github.com>
The official Mealie image installs ffmpeg. This script's apt list
did not, so yt-dlp could not extract reel audio (ffprobe missing).
ensure_dependencies on update covers existing containers.
hermes update refuses a checkout its caller does not own, so the
root-run update stopped working for every install. The installer and
hermes update now run as hermes, and the dashboard becomes a user unit
next to the gateways, so Hermes Desktop and the dashboard can update
and restart it themselves. libatomic1 is installed up front, the one
package Hermes would otherwise ask sudo for.
update moves existing containers over once: the system unit becomes a
user unit, leftover root processes are stopped and /home/hermes is
handed back to hermes.
tsc on the 5.0 server needs about 3 GB of heap; the 2 GB default left it 2.3 GB and the update died in the build. npm ci runs with --ignore-scripts like upstream, so better-sqlite3 keeps its prebuilt binary instead of an addon built against the running Node's headers. kitinerary-extractor sits in libexec on Debian, so link it into PATH where TREK looks for it.
Bar Assistant seeds new bars from its public datapack via FromDataPack in
DataPackMediaMode::StarterCatalog, which requires the pack's starter-media-release.json
manifest AND a published starter-media catalog produced by `php artisan
starter-media:publish`. Upstream's Docker image runs that publish on every container
start; neither Proxmox script does, so creating any bar (or "Synchronize data") fails
and leaves the bar created but completely empty.
- install/bar-assistant-install.sh: publish the starter media catalog after storage:link
- ct/bar-assistant.sh: same on update, and refresh resources/data so an updated
container cannot keep a data pack older than the app (a pack predating
starter-media-release.json cannot be published at all)
starter-media:publish is idempotent: it reports "already published" and exits 0.
Fixes#18123
* install: answer every prompt from the environment, survive a closed stdin
Every interactive prompt takes a var_<app>_<name> override and treats a
closed stdin like Enter (`|| true`), so an install keeps going after the
console that started it is gone. Values the script cannot do without end
with exit 64 and name the variable to set. Validation loops stop asking
when nobody can answer instead of spinning on an empty read.
* mongodb, paperless-gpt: accept yes as well as y
Upstream added PROXCENTER_SKIP_TYPECHECK for builds from a released tag;
the type check alone needs about 3 GB. A 4.6 GB heap on 6 GB of RAM got
the build killed.
CanbiZ (MickLesk)