# Auto-update (opt-in)
omniMux’s web UI can show an “update available” banner with a one-line changelog, and a button that pulls + rebuilds on your host. Running the install step below is itself the opt-in — there’s no second switch to flip afterward. Skip it and nothing about your deployment changes.
# Why a separate host service
Applying an update means running git pull and docker compose up -d --build on the host. The omnimux-api container can’t do that itself
without either mounting /var/run/docker.sock into it (root-equivalent
access to your whole host from a container that also parses YouTube search
results) or a docker-socket-proxy sidecar. Instead, omnimux_updater.py runs
directly on the host as its own systemd service, and the api container talks
to it over a Unix socket that can only do two things: report the changelog,
and trigger an update. No docker API access, no host shell, ever reaches the
container.
# Install
sudo ./deploy/install.sh
docker compose up -d
That generates a token, writes /etc/omnimux/updater.env and
/etc/systemd/system/omnimux-updater.service, sets UPDATER_TOKEN in the
repo’s .env (creating it from .env.example first if you don’t have one
yet — everything else already in .env, like JWT_SECRET, is left alone),
and starts the service. docker-compose.yml itself is never edited, by the
script or by you — see below.
Re-running install.sh is safe — it reuses the existing token instead of
generating a new one.
# Manual install
If you’d rather not run a script as root, do the same things by hand: copy
deploy/omnimux-updater.service to /etc/systemd/system/, copy
deploy/updater.env.example to /etc/omnimux/updater.env (mode 600) and
fill in OMNIMUX_REPO_DIR / a token from openssl rand -hex 32, edit
User= / WorkingDirectory= / ExecStart= in the unit file to match your
checkout, then set that same token as UPDATER_TOKEN in the repo’s .env
(copy .env.example first if you don’t have one). Finish with sudo systemctl daemon-reload && sudo systemctl enable --now omnimux-updater.
# Why .env instead of editing docker-compose.yml
JWT_SECRET and UPDATER_TOKEN are read from .env (gitignored, Compose
loads it automatically) rather than hardcoded in docker-compose.yml. If you
edit secrets directly into the tracked file instead, a future git pull —
including one the updater runs for you — has to reconcile your local changes
to that file with upstream’s, which is exactly the kind of thing that turns
“click update” into a merge conflict. Keeping the tracked file identical to
upstream and putting everything host-specific in .env means git pull
never has anything of yours to conflict with.
# Updating the updater itself
omnimux_updater.py runs as a plain systemd service on the host, outside
docker compose, so it isn’t restarted by the update it triggers. If a future
release changes this file, sudo systemctl restart omnimux-updater after
pulling picks up the change.
# Uninstall
sudo systemctl disable --now omnimux-updater
sudo rm /etc/systemd/system/omnimux-updater.service /etc/omnimux/updater.env
sudo systemctl daemon-reload
Optionally clear UPDATER_TOKEN= back out of .env. Either way the web UI
falls back to hiding the update banner entirely once the socket is gone.