Update node.js to 22.16.0

[gilmoremp]

Feature Description

Pulling the latest update still shows an outdated node.js of 22.15.1. Homebridge prompts for an update to node.js 22.16.0.

[n0rt0nthec4t]

yep.. and also homebridge-ui..

[NorthernMan54]

Publish is kicked off

I'm also going to simplify the workflow and notifications around this a bit with the following changes

Concept - Use dependabot to track versions, and create PR's when updates are needed. This is 100% do-able, just need to get everything into NPM for version tracking. Then it will manage a package.json for the versions etc. See homebridge-apt-pkg for an example of this in action.

This package is dependant on homebridge-apt-pkg and ffmpeg-for-homebridge. ffmpeg-for-homebridge is already a npm package, just homebridge-apt-pkg is not a npm package, but a deb package.

Steps

1 - Publish stub npm package for homebridge-apt-pkg, and have it update with each release

2 - Change builder process to use versions from package.json, rather than the current process of just latest

3 - Setup dependabot to manage package.json and create PR's when new versions are available.

4 - Setup an automated build trigger for when the dependabot PR is merged.

[NorthernMan54]

Also going to add this file to the Docker image - root@docker-desktop:/homebridge $ cat /manifest.md Homebridge Docker Package Manifest

Package	Version
Ubuntu	24.04
NodeJS	v22.12.0
Homebridge-Config-UI-X	4.65.0
Homebridge	latest *
homebridge-apt-pkg	1.4.0
ffmpeg for homebridge	v2.1.6

• Note: Homebridge is only updated to latest on a new installation, refreshing an existing installation does not update Homebridge version. To update the Homebridge version please use the UI.

PS That's a test version hence the older versions - Used apt 1.4.0 as a base

[n0rt0nthec4t]

HomeBridge and Homebriudge UI updates needed :-)

[NorthernMan54]

In flight - https://github.com/homebridge/docker-homebridge/actions/runs/15559014508

[n0rt0nthec4t]

Thanks.. I thought it was all automated now

Question, why dont we do a Homebridge version update in the docker container? Since this is a self contained container, I think it should be considered for that to happen..

[NorthernMan54]

I had started automation then got distracted by NodeJS 24

https://github.com/homebridge/homebridge-config-ui-x/pull/2451

Will be getting back to this in a day or so

[NorthernMan54]

What is updated in each version is something we want to discuss with the community. As the homebridge version is managed outside of the docker image. The docker image manages /opt/homebridge, ie NodeJS and config-ui-x, while homebridge lives under /var/lib.

@JustJam had some thoughts as well.

[n0rt0nthec4t]

My Thinking is since the apt-pkg is updated with homebridge version also, the docker image should be kept consistent ie: the entire echo system inside..

[NorthernMan54]

The tracking of apt is ready - https://www.npmjs.com/package/@homebridge/homebridge-apt-pkg

[NorthernMan54]

@justjam2013 what's your thoughts ?

[justjam2013]

My view is that each Docker image should specify the versions of Ubuntu, NodeJS, Homebridge-Config-UI-X, Homebridge, and ffmpeg that it delivers. That makes each Docker image a known-good configuration on a clean install.

As Homebridge UI and Homebridge can be updated from within Homebridge UI, my suggestion was to check the installed versions:

• If the installed version is older than the version in the Docker image, then update to the Docker version
• If the installed version is newer than the version in the Docker image, then do not downgrade to the Docker version

Ideally it would be nice for the user to be able to choose if the Docker image version overwrites the installed versions. This would make it easier to rollback to a previous configuration. Maybe that might be a setting in Homebridge UI available for Docker environments only.

See the issue Update Homebridge version and Homebridge UI versions to Docker image versions, if Docker image version(s) ahead of current versions(s), with associated PR.

[n0rt0nthec4t]

I think it's important to emphasise that a Docker container should reflect a cohesive, up-to-date, and known-good environment — not just for new installs, but for existing volumes too. If the Docker image ships with newer versions of Homebridge or Config UI, it's usually because those versions are tested and compatible. Letting existing installs fall behind the image defeats the purpose of using Docker to simplify maintenance. I agree with the idea of comparing installed vs. image versions at startup and upgrading when appropriate. This ensures consistency, avoids fragmentation between users, and reduces support complexity. For those who want to opt out or prefer pinning specific versions, an environment variable like HOMEBRIDGE_AUTOUPDATE=false would give flexibility — but the default behavior should be to keep everything updated when the image updates. After all, users who don’t want Docker to manage upgrades can always manage installs manually — but for everyone else, automatic updates aligned with the container image are exactly the kind of maintenance Docker is meant to make painless.

[justjam2013]

reduces support complexity

@n0rt0nthec4t yes! This! 100%!

For those who want to opt out or prefer pinning specific versions, an environment variable like HOMEBRIDGE_AUTOUPDATE=false would give flexibility

My thoughts when I wrote "Ideally it would be nice for the user to be able to choose if the Docker image version overwrites the installed versions." was that the user could choose whether the Docker image overwrites the installed version only when a newer version is installed, but it would always overwrite an older version.

As you say:

the Docker image ships with newer versions of Homebridge or Config UI [that] are tested and compatible

If a user choose to customize their setup (for whatever reason) then they need to be responsible for managing any potential mismatches and incompatibilities. So maybe using the official Docker image is not appropriate for them.

If they still want to use the Docker image, then they can always downgrade versions from inside the UI to roll back, but they need to consciously take the steps to walk out of the garden. And it should say in bold in the HB & HB UI update modals that downgrading below the Docker image versions may cause incompatibilities and it is not recommended.

[justjam2013]

I have two Homebridge installs.

One is my "home" install, stable and boring, which uses the official Docker image. Unless there is a particular feature I want, I only update it when a new Docker image is published, then forget about it.

The other is my "dev" install. It's the wild wild west in there and it mostly runs betas. It gets upgraded, downgraded, frontgraded, backgraded, sidegraded, and slantgraded any time a new beta of HB or HB UI comes out, so I can test that my plugin doesn't break. I blew up the install once and had to restart from scratch. I do not expect the Homebridge devs to support my Frankenbridge. In fact I try to beat up on the betas, provide feedback, and maybe contribute fixes if and where I can.

[NorthernMan54]

What if we added another status item in the UI for Docker Image version ? So it would be visible when an update was available, and you could update.

( I was trying to think of how to visually lay it all out, As you have a docker container version, which contains an apt-package version and OS version and FFMPEG version, and the apt package contains NodeJS, Homebridge and the UI. ). Gets complicated

A comment was made about homebridge version, as it is not being updated by docker. Should we make it update ?

[justjam2013]

docker container: { os + ffmpeg + apt-package: { NodeJS + Homebridge + Homebridge UI } }

Like a set of matryoshka dolls. This maintains a consistent set of versions across apt-package and docker container releases.

The rest is nice-to-have, in my mind:

• another status item in the UI for Docker Image version update available
• an environment variable like HOMEBRIDGE_AUTOUPDATE=false
• be able to choose if the Docker image version overwrites the installed versions

[n0rt0nthec4t]

docker container: { os + ffmpeg + apt-package: { NodeJS + Homebridge + Homebridge UI } }

Like a set of matryoshka dolls. This maintains a consistent set of versions across apt-package and docker container releases.

The rest is nice-to-have, in my mind:

• another status item in the UI for Docker Image version update available
• an environment variable like HOMEBRIDGE_AUTOUPDATE=false
• be able to choose if the Docker image version overwrites the installed versions

THIS!!

I don't want to manually go in an update homebridge or UI versions in the container.

Docker versions can be maintained by release tags

[justjam2013]

This conversation extends this previous feature request: Update Homebridge version and Homebridge UI versions to Docker image versions, if Docker image version(s) ahead of current versions(s)

[NorthernMan54]

Stage 1 of improving the build and version tracking - #608

Thoughts before I merge this

[justjam2013]

Wow! I like that you used Dependabot to update the Docker container build based on apt-pkg. That's much better than my PR updating HB, HB UI, and Node versions by hand.

[NorthernMan54]

@n0rt0nthec4t To leverage the new version variables, my thought was to has the Docker image version update status be visible in the UI. First step is getting the version exposed. Am thinking that it should at least replace the UI, OS, and NodeJS version tracking.

[justjam2013]

Am thinking that it should at least replace the UI, OS, and NodeJS version tracking.

Maybe not replace, just in case people want to still update from within HB UI. But definitely indicate that there is a new Docker version for the ones who want to ignore the individual updates.

[n0rt0nthec4t]

Agreed, juts report on docker version and if an update to the docker version is available. Most people using docker would potentionaly maintain it with something like Portainer or watchtower (I do), so udpates happen in the background and generally never need to worry about them

[justjam2013]

Unlike my dev install, I like to control the updates on my home install. I use Homebridge Plugin Update Check to notify me when a new updates are available, so I will open a feature request and maybe a PR to update it to include a new Docker version.

[NorthernMan54]

And the beta build process is now active

https://github.com/homebridge/docker-homebridge/releases/tag/beta-2025-06-24

Going to wait for feedback on this, before doing the latest.

You can install this with the ‘beta’ tag

[NorthernMan54]

And this is the UI, after some initial playing around -

Thought was to remove NodeJS, Homebridge and UI status options when running in Docker or make them an item under docker and pop open when clicked

[justjam2013]

Completely removing NodeJS, Homebridge, and UI status options is too extreme. Moving them into a popup under Docker would be preferable. That way they are still available.

I would like to hear other opinions, but here are my thoughts:

• Updating NodeJS occurs outside the UI, so NodeJS should always be under Docker.
• Updating Homebridge and HB UI can occur from within the UI, so there should be a setting to display Homebridge and UI statuses (for the users that want to continue to update from the UI), or to place the Homebridge and UI statuses under Docker (for those users that only want to update when a new Docker version is available).

@n0rt0nthec4t @bwp91

[n0rt0nthec4t]

I'll go back to my original thoughts, all those updates to HB, UI, Node etc should be handled outside of teh docker container. The docker container should be "source of truth". I like teh thinking that the UI should just show the docker version and if an update is available

[justjam2013]

@n0rt0nthec4t what if someone still wants to update HB & HB UI? Should that be completely removed and not even available as a popup under docker?