Updating to v26.1.17 from scratch - GHCR vs local build?

[seh2000]

Hi,

I’m trying to update NetAlertX to v26.1.17, and I’m a bit unsure about the correct way to install it from scratch.

The release page shows v26.1.17 as the latest version, but I’m not sure whether I should:

pull the image from GHCR using
image: ghcr.io/jokob-sk/netalertx:latest
or
use the compose file in the release that builds the image locally.

The reason I’m asking is that when I use the GHCR latest image, the Pi‑hole API login fails on Pi‑hole v6. Earlier this week the Pi‑hole API was working fine for me (as in our ICMP discussion), so I just want to make sure I’m using the right installation method.

If the recommended method is the local build from the release source, could you confirm the correct steps?
My understanding is: download the v26.1.17 source, extract it, run docker compose build, then docker compose up -d.
Just want to make sure that’s the intended workflow.

Could you also confirm whether the GHCR image is up to date?

Thanks for your help!
Steen

[jokob-sk]

Hi,

The production image is always older than the source code. See what will be available in the next release here #138

Open a new issue if you think there is a bug in the latest release that is not mentioned in the above issue or fixed in the netalertx-dev image which is always build from the latest source.

[seh2000]

Hi Jokob,

Thanks for the explanation about the production image being behind the source code — that helped me understand things a bit better.

I’ve been trying out the netalertx-dev image because I’m using the Pi‑hole API plugin with Pi‑hole v6, and I noticed something I wasn’t sure about. The frontend keeps showing this message in the browser console:

Setting with key "BACKEND_API_URL" not found
I added a settings.json file under /data/config, and the backend seems able to read it, but the frontend still doesn’t pick it up. I might be misunderstanding how the dev image handles this, so I just wanted to check whether this is expected behaviour at the moment.

This also ties a bit into my post the other day under ideas earlier this week about exposing “Ping Check” for devices detected only through the Pi‑hole API or ARP‑Scan — I’m mainly experimenting to understand how things work together.

If it’s something known or already being worked on, no worries at all. I just wanted to mention it in case it’s helpful.

Thanks again for all your work on the project!

Warm regards - Steen