Node.js 16 (EOL) usage – plans for upgrade?

[MickLesk]

Hi,

we are currently evaluating Fireshare for potential inclusion in our Community Scripts project. (https://github.com/community-scripts/ProxmoxVE)

During a quick review, we noticed that the project is still based on Node.js 16 (e.g. node:16.15-slim), which has been EOL for quite some time and no longer receives security updates.

Before proceeding further, we wanted to ask:

• Are there any plans to upgrade the runtime to a supported Node.js version (e.g. Node 22/24)?
• Is there already a roadmap or branch addressing dependency updates?

From our perspective, shipping or automating deployments based on an EOL runtime is problematic (security + maintenance).

Thanks in advance.

Feel free to ping @tremor021 or me.

[ShaneIsrael]

@MickLesk My plan has been to convert the project to a Vite project as soon as an issue appeared. Node is only used to build the frontend react, the backend is completely python.

[MickLesk]

python3.9 is the next topic ^^ its EOL since 2025. Is this planned to upgrade to 3.13 / 3.14?

[ShaneIsrael]

Here you go. It's been long overdue anyways so I figured this would be a good time to upgrade everything.

#516

[tremor021]

EDIT: disregard my comment, i probably worked on main branch, need to re-test

[ShaneIsrael]

@tremor021 if you are running with docker, use the shaneisrael/fireshare:develop build. The next production release will have the updates but I don't yet have an ETA on when that will be ready.

[tremor021]

Its all good, i already have a bare-metal script working. just a small error in the logs to fix, when i click scan library:

Mar 26 20:12:36 fireshare gunicorn[33794]: Job "fireshare_scan (trigger: interval[0:05:00], next run at: 2026-03-26 19:17:36 UTC)" raised an exception
Mar 26 20:12:36 fireshare gunicorn[33794]: Traceback (most recent call last):
Mar 26 20:12:36 fireshare gunicorn[33794]:   File "/opt/fireshare/.venv/lib/python3.14/site-packages/apscheduler/executors/base.py", line 131, in run_job
Mar 26 20:12:36 fireshare gunicorn[33794]:     retval = job.func(*job.args, **job.kwargs)
Mar 26 20:12:36 fireshare gunicorn[33794]:   File "/opt/fireshare/app/server/fireshare/schedule.py", line 13, in fireshare_scan
Mar 26 20:12:36 fireshare gunicorn[33794]:     Popen(["fireshare", "bulk-import"], shell=False)
Mar 26 20:12:36 fireshare gunicorn[33794]:     ~~~~~^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
Mar 26 20:12:36 fireshare gunicorn[33794]:   File "/root/.local/share/uv/python/cpython-3.14.3-linux-x86_64-gnu/lib/python3.14/subprocess.py", line 1038, in __init__
Mar 26 20:12:36 fireshare gunicorn[33794]:     self._execute_child(args, executable, preexec_fn, close_fds,
Mar 26 20:12:36 fireshare gunicorn[33794]:     ~~~~~~~~~~~~~~~~~~~^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
Mar 26 20:12:36 fireshare gunicorn[33794]:                         pass_fds, cwd, env,
Mar 26 20:12:36 fireshare gunicorn[33794]:                         ^^^^^^^^^^^^^^^^^^^
Mar 26 20:12:36 fireshare gunicorn[33794]:     ...<5 lines>...
Mar 26 20:12:36 fireshare gunicorn[33794]:                         gid, gids, uid, umask,
Mar 26 20:12:36 fireshare gunicorn[33794]:                         ^^^^^^^^^^^^^^^^^^^^^^
Mar 26 20:12:36 fireshare gunicorn[33794]:                         start_new_session, process_group)
Mar 26 20:12:36 fireshare gunicorn[33794]:                         ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
Mar 26 20:12:36 fireshare gunicorn[33794]:   File "/root/.local/share/uv/python/cpython-3.14.3-linux-x86_64-gnu/lib/python3.14/subprocess.py", line 1989, in _execute_child
Mar 26 20:12:36 fireshare gunicorn[33794]:     raise child_exception_type(errno_num, err_msg, err_filename)
Mar 26 20:12:36 fireshare gunicorn[33794]: FileNotFoundError: [Errno 2] No such file or directory: 'fireshare'

[ShaneIsrael]

How are you running this? Docker or running it via the local run scripts for local dev?

To me this looks like an incorrect setup if this is happening through docker (likely incorrect volume mounts) but if you are running it outside of docker you probably are not setting your environment variables correctly to setup the directories fireshare uses.

[tremor021]

FLASK_APP="/opt/fireshare/app/server/fireshare:create_app()"
ENVIRONMENT=production
DATA_DIRECTORY=/data
VIDEO_DIRECTORY=/videos
PROCESSED_DIRECTORY=/processed
TEMPLATE_PATH=/opt/fireshare/app/server/fireshare/templates
ADMIN_PASSWORD=admin
TZ=UTC
LD_LIBRARY_PATH=/usr/local/nvidia/lib:/usr/local/nvidia/lib64:/usr/local/lib:/usr/local/cuda/lib64:$LD_LIBRARY_PATH
PATH=/usr/local/bin:$PATH

these are the env vars used, as in Dockerfile. all directories get created correctly, not sure what else to look at

[Unit]
Description=Fireshare Service
After=network.target

[Service]
WorkingDirectory=/opt/fireshare/app/server
ExecStart=/opt/fireshare/.venv/bin/gunicorn --bind=127.0.0.1:5000 "fireshare:create_app(init_schedule=True)" --workers 3 --threads 3 --preload
Restart=always
EnvironmentFile=/opt/fireshare/fireshare.env

[Install]
WantedBy=multi-user.target

this is the systemd service, which starts correctly. web client is served via nginx's prod.conf and it works correctly. only thing i changed in nginx config is the user, from nginx to root as LXC containers run as root. config loads fine and nginx serves the frontend correctly

gonna poke around some more.
We dont use docker, we install it as bare-metal, by following your Dockerfile

[tremor021]

If you wanna see how we do it, this is the bash script i've created:
https://raw.githubusercontent.com/community-scripts/ProxmoxVED/refs/heads/main/install/fireshare-install.sh

[ShaneIsrael]

So looking at that error again it seems like the fireshare executable isn't being created or at the very least isn't being found by the system.

That's the why this is appearing underlined in your error log

Popen(["fireshare", "bulk-import"], shell=False)

When you initiate a scan, Fireshare needs to run the fireshare executable, but its not being found so the system is thinking you are trying to open a folder "fireshare".

I'm not really sure why thats happening in your script. All I can say is that outside of local dev inside a python virtual environment, fireshare was never really designed to be run outside of Docker. So you are kinda in a little bit of unknown territory.

[MickLesk]

Iwill take a look tomorrow. Bare Metal Installs are almost the same like docker, but without Docker. Its an executable Stack directly in the OS. In this Case Debian 13. -- I think its an little issue with the uv venv, we use mainly UV, because Python (pip) have "external managed" Issues with Debian (Break system packages). Many of the current projects we offer have already encountered this issue during their development, which is why many have switched to UV. There is then a "uv.lock" file, and we only perform UV sync. This saves a lot of steps and the performance is

[tremor021]

No, i was a bit stupid. The binary is created, all good :) Script is updated @MickLesk , all works fine now :)

[ShaneIsrael]

@tremor021 @MickLesk I just want to check, but is everything resolved? Can I close this issue?

[MickLesk]

Yeah we wait Just for the next Release and then we switch some functions, then its ready for our Community.

[tremor021]

@ShaneIsrael yes yes, all resolved. For some reason i completely disregarded the fact that i'm running the command inside python venv, so i didn't even bother to look for the binary there.

You can close this. Thanks for your time and effort