Help expand the LXC app catalog — share your working detectors

[MacRimi]

Hi everyone 👋

The LXC Updates tab can update the OS and the apps in a container in one guided pass. For each tracked app, ProxMenux needs to know how to read the installed version from inside the CT and where to check the latest upstream release — that config lives in the App tab → Track Upstream Version section when you register the app.

There are two catalog files in the repo that feed this feature:

• json/app_tracking_hints.json — the curated seed catalog I maintain (~50 apps, with logos, websites, default ports). Used by the UI to pre-fill the form when you register a known app.
• json/runtime_verified_overrides.json — runtime-verified detectors. Each entry is a detector that's been proven to work on a real container. This is the one designed for community contributions.

If you've registered an app in your ProxMenux and gotten the version detection + upstream check working, that detector belongs in the overrides catalog. If you'd like to share it, it'll be added to the verified apps catalog and made available to all users.

Doesn't matter how the app was installed — community-scripts helper, official upstream script, manual build, anything. The catalog cares about the detector, not the installer.

One app per reply, please. Makes it easy to follow up on each.

Template — copy this into your reply and fill in what applies

Click the copy button on the block below, paste it into your reply, and fill in the values you set on the App tab for your app. Delete the lines that don't apply to your method — for example, if you use dpkg, keep only Package identifier; the rest of the method-specific block goes away.

- **App name:** 
- **Installed via:** _(dpkg / apk / Binary / file / python distribution / command / manual)_

**Method-specific fields** (keep only the ones that appeared in your form):
- **Package identifier:** 
- **Binary path:** 
- **Binary args:** 
- **File path:** 
- **Regex (with capture group):** 
- **Python interpreter path:** 
- **Distribution name:** 
- **Command:** 
- **Installed version:** 

**Upstream source:**
- **Upstream version source:** _(GitHub repo / HTTP JSON endpoint / Docker Hub image)_
- **GitHub repo:** 
- **GitHub source:** _(releases / tags)_
- **Endpoint URL:** 
- **JSON path:** 
- **Docker Hub image:** 
- **Tag regex:** 

**Optional:**
- **Installed version regex:** 

Wrap paths and regex values in backticks so special characters render correctly. Example: `/opt/appname/version.txt` and `v?(\d+\.\d+\.\d+)`.

Examples — how filled contributions look

Three real examples covering the most common cases. Match your app to the closest one:

Example 1 — dpkg method (app installed via an apt package)

• App name: Cockpit
• Installed via: dpkg
• Package identifier: cockpit
• Upstream version source: GitHub repo
• GitHub repo: cockpit-project/cockpit
• GitHub source: releases
• Tag regex: (?i)(?:v|release[-_/]?)?(\d+(?:\.\d+){1,3}(?:[-+._][0-9A-Za-z.-]+)?)

Example 2 — Binary method (app installed via an upstream script that drops a binary into /opt)

• App name: AdGuard Home
• Installed via: Binary
• Binary path: /opt/AdGuardHome/AdGuardHome
• Upstream version source: GitHub repo
• GitHub repo: AdguardTeam/AdGuardHome
• GitHub source: releases
• Tag regex: v?(\d+\.\d+\.\d+)

Example 3 — file method (installed version read from a file inside the container)

• App name: Tandoor
• Installed via: file
• File path: /opt/tandoor/cookbook/version_info.py
• Regex (with capture group): TANDOOR_VERSION\s*=\s*["']v?(\d+\.\d+\.\d+)
• Upstream version source: GitHub repo
• GitHub repo: TandoorRecipes/recipes
• GitHub source: releases
• Tag regex: v?(\d+\.\d+\.\d+)

Notice how each example only keeps the method-specific line that applies: dpkg shows only Package identifier, Binary shows only Binary path, file shows File path + Regex. All the other lines from the template are deleted in each case.

Fast path — if you're comfortable with JSON

If you'd rather just paste your app's config file directly, this works too:

cat /etc/proxmenux/apps/<vmid>.json

I'll extract the detector-shaped subset for the catalog myself.

Important — keep it generic

Please make sure the paths you share don't contain personal info: no IP addresses, no VMIDs, no hostnames, no personal directories like /home/yourname/…. Use the canonical location the upstream installer places things at (/opt/appname/, /etc/appname/, etc.). If reproduction context helps me understand what you tested — kernel version, distro, unusual setup — put it in the reply prose, not in the technical fields.

What happens next

Your contribution ships with the next beta and becomes the default for anyone with the same app.

Contributors get credited in the release notes.

Thanks.

[SystemIdleProcess]

FYI, community-scripts if they are able to will write a flat file at /root/ with . which will have the version. Just a simple file + regex pointed to it with regex (\d+.\d+.\d+) should work. There are cases where the . will be a directory used by the app so it may have a slightly different filename.
But I've had updates fail and the new version that didn't actually get installed be in that file so next when I re-ran update command it stated there was no updates available.

[SystemIdleProcess]

Is there support when using Docker Hub image to specify tag? e.g. portainer/portainer-ee:lts
I prefer to run the LTS versus the latest. This is for my docker LXC that has portainer be also.

[MacRimi]

Yes, there is, precisely for that.

[SystemIdleProcess]

Yes, there is, precisely for that.

[MacRimi]

Sorry, I misread your setup — my bad.

Portainer itself isn't implemented as a source for version detection in ProxMenux — I haven't wired it as an upstream option.

What I meant was to use Docker Hub to pull the version tag. For Portainer LTS that would be:

• Upstream version source: Docker Hub image
• Docker Hub image: portainer/portainer-ee (just the image name — no :tag shorthand here)
• Tag regex: a pattern that matches only the LTS-versioned tags on that repo

The Docker Hub image field takes just the image name (portainer/portainer-ee). The :lts filter part lives in Tag regex — that's what picks which tags qualify as valid versions.

[SystemIdleProcess]

It's okay. I'm sorry, I'm still confused on how to get this to work. I'm doing docker exec on /portainer and if I put just lts as tag filter on upstream version pointed to Docker Hub image then it can't detect the local version. I assume it's using the filter.
Had to switch to github and put v?(\d+.\d+.\d+)(\slts)? as the tag filter.

[MacRimi]

Sorry for taking a while to get back to you — I haven't had a chance to sit down and properly reply until now. Thanks for the feedback and ideas.

On the Portainer LTS setup: Portainer isn't in the catalog. The original idea was to update only the apps that run natively inside the LXC — though it's true that it would be relatively easy to also capture the versions of Docker images when the LXC is running Docker and get update notifications for those images too.

Including Docker Hub as an upstream source was meant to give an additional way to identify app versions beyond GitHub, not to specifically target dockerized apps.

• Tag regex is what filters which tags on that repo count as valid versions — it has to both match the tags you want to track and expose the version in the capture group.

On the field being confusing: your feedback is really valuable and it's making me rethink this whole side of the flow to make it easier to use for other users.

On how the update actually runs: two paths are supported.

• If the CT was installed by a community-scripts helper (detected via /usr/bin/update or the HELPER_SLUG env), the combined "Apply OS + " button runs that helper's update script inside the CT — same command you'd run manually. This button only shows up when the app is registered on the App tab and being tracked.
• If an app is registered but wasn't detected as installed by a Proxmox PVE helper-script, the option to manually enter a command to update it appears; once that command is entered, the "Update app" button becomes active. That's how it works today, but I'm thinking it would be nice for more advanced users to be able to define their own update command for an app registered from a helper-script-installed CT too — that way the option to edit the update method would always be available.

Thanks again — this back-and-forth is directly shaping what's in 1.2.4.2.

[SystemIdleProcess]

I took out what I thought wasn't needed from the original files. All of these were installed via community-scripts so most point to the version file it creates and then the github repo for the app. I know some of these were already in there, sorry about the duplication, I couldn't remember which was which. SearXNG is the only one I had to do manual on, I just couldn't figure out how to detect current version. The docker one has portainer with lts version check. I only modify the Plex url for plexpass based on what I found in PlexUpdate which I've been using for a while now to automatically update Plex.

tunarr.json
dispatcharr.json
dashy.json
seerr.json
kavita.json
audiobookshelf.json
plex.json
profilarr.json
tracearr.json
tautulli.json
kapowarr.json
shelfmark.json
sonarr.json
radarr.json
lidarr.json
byparr.json
sabnzbd.json
qbittorrent.json
prowlarr.json
homepage.json
searxng.json
open-webui.json
ollama.json
mealie.json
actualbudget.json
anchor.json
gitea.json
docker-portainer_lts.json
rackula.json
apprise-api.json

[SystemIdleProcess]

I was wrong about Plex. It appears the only way to get the PlexPass version is to pass X-Plex-Token in the header.

[SystemIdleProcess]

Working on the SearXNG local version and I can't seem to get the installed version check to work. I'm trying to use python distribution method.
locally this works
/usr/local/searxng/searx-pyenv/bin/pip show searxng 2>/dev/null | grep -i version
Returns: Version: 2026.8.20+487d7a96e
But when I set ProxMenuX with the following it doesn't error but no version is returned only the upstream.
Python interpreter path:
/usr/local/searxng/searx-pyenv/bin/python
Distribution name:
searxng

Tag regex is v?(\d+\.\d+\.\d+[-+]\w+)

[MacRimi]

Awesome!!! What great work. It has been very enlightening for me. Many thanks for taking the time to do the tests.

I’ve used your results and I’m going to release a new beta version where the process of identifying an app is much easier.

Also, if the LXC is Docker, it will even be possible to update the Docker images.

Great job, thank you very much.

[SystemIdleProcess]

Did you see my issue with SearXNG and pip? Can you help me troubleshoot why I'm not getting a Installed version or error from it?

[MacRimi]

try this to see if it works for you

"searxng": {
  "operational": true,
  "install_scope": [
    "community-script",
    "manual-if-same-venv"
  ],
  "detector": {
    "installed_via": "python_dist",
    "python_path": "/usr/local/searxng/searx-pyenv/bin/python",
    "distribution": "searxng",
    "installed_regex": "(\\d+\\.\\d+\\.\\d+\\+[0-9a-f]+)"
  }
}

[TCBWZA]

Hi @MacRimi

I have been working on a personal script for managing my LXCs. You can find it at lxc-upgrade.sh you may find ideas (or have suggestions for me : ) ), currently I run this and it keeps my LXCs up to date. I have not got as far as running the update command if it exists as I am still investigating how I want to approach it.

(I placed this comment in our last interaction but I'm not sure if you saw it.)

PS On a docker host you may want to test for a WatchTower container, this tool automatically updates containers, if it is present you only need to worry about the standard OS stuff.

[MacRimi]

Thanks for sharing this — it's a well-thought-out script. Two things I especially like: the package-manager auto-detect covers six families (apt / apk / dnf / yum / pacman / xbps), broader than what ProxMenux handles today, and the way you track which CTs were stopped so you can restore that state at the end — a detail a lot of pass-through scripts skip.

The OS-update side in ProxMenux is actually pretty close in spirit to what you've built. If you want to compare notes, the equivalent lives in scripts/lxc/apply_updates.sh — it handles the OS branch and, when the app is registered on the App tab, also the app branch (community-scripts wrapper or a user-defined command). Different design goals from a personal script, but the OS section will feel familiar.

One small thing you might want to try: switching apt-get upgrade to apt-get dist-upgrade in the apt branch — same fix I ended up applying in ProxMenux after your report on issue #299. Without it, packages that need dep changes stay kept back after point-release Debian rebuilds.

On the WatchTower point — good catch. A Docker LXC running WatchTower doesn't need ProxMenux touching the containers at all, only the OS layer. Detecting it upfront and stepping aside for the images it owns fits well with what I've been thinking about for the Docker side.

Thanks again for sharing — there are ideas in it I'll take into consideration for future improvements.

[MacRimi]

Hi @SystemIdleProcess, @TCBWZA and @Vaso73,

I've spent these past days thinking about how to improve this side of things. The first beta was an initial approach, and your comments and observations — especially @SystemIdleProcess's thorough analysis — helped me rethink both the App and Updates tabs.

The app catalog now includes more than 300 apps from the Proxmox PVE Helper-Scripts collection, while the option to register manual or custom apps is still there. The Updates tab also gained a lot: even when an update method is detected automatically, you can modify it and adapt it to your setup. For LXCs with Docker Engine installed, the flow doesn't only track Docker's own version — it also inventories the images running inside and their versions, so you'll receive notifications when a new image release is available and you'll be able to update Docker images either manually or on a schedule, per image if you prefer.

I'm hoping to release beta 2 in a few days for you to try it out.

[SystemIdleProcess]

I was wondering if it would be possible to have the ability to toggle the verbose output when executing the community-scripts update.

Related to the update I noticed on most of the python apps that I get a lot of output like this:

find: ‘/opt/anchor/server/node_modules/.pnpm/@standard-schema+spec@1.1.0’: No such file or directory
find: ‘/opt/anchor/server/node_modules/.pnpm/node-gyp-build@4.8.4’: No such file or directory
find: ‘/opt/anchor/server/node_modules/.pnpm/@tsconfig+node10@1.0.12’: No such file or directory
find: ‘/opt/anchor/server/node_modules/.pnpm/@electric-sql+pglite@0.4.1’: No such file or directory
find: ‘/opt/anchor/server/node_modules/.pnpm/call-bind-apply-helpers@1.0.2’: No such file or directory
find: ‘/opt/anchor/server/node_modules/.pnpm/@types+http-errors@2.0.5’: No such file or directory
find: ‘/opt/anchor/server/node_modules/.pnpm/memfs@3.5.3’: No such file or directory
find: ‘/opt/anchor/server/node_modules/.pnpm/@nestjs+mapped-types@2.1.1_@nestjs+common@11.1.18_class-transformer@0.5.1_class-validat_475d6c8721c64fe7340bf5ea93eb5cea’: No such file or directory
find: ‘/opt/anchor/server/node_modules/@eslint’: No such file or directory
find: ‘/opt/anchor/server/node_modules/.bin’: No such file or directory
find: ‘/opt/anchor/server/test’: No such file or directory
find: ‘/opt/anchor/server/prisma’: No such file or directory

[SystemIdleProcess]

same for homepage but different

find: ‘/opt/homepage/.next/standalone/node_modules/.pnpm/@babel+runtime@7.29.7’: No such file or directory
find: ‘/opt/homepage/.next/standalone/node_modules/.pnpm/oauth4webapi@3.8.6’: No such file or directory
find: ‘/opt/homepage/.next/standalone/node_modules/.pnpm/cpu-features@0.0.10’: No such file or directory
find: ‘/opt/homepage/.next/standalone/node_modules/.pnpm/tslib@2.8.1’: No such file or directory

there are lot more lines of similar paths for both of them I just grabbed some for each.