v3.8.0 — Install it without Docker

Docker is no longer the only way in. Every release from this one on carries a
Linux archive that installs NextExplorer as a systemd service, for x86_64 and
arm64, with the Node runtime inside it.

tar -xzf nextexplorer-3.8.0-linux-x64.tar.gz
cd nextexplorer-3.8.0-linux-x64
sudo ./install.sh

That is the whole of it. Nothing has to be installed first, and nothing is
compiled.

What is in the archive, and what is not

In it: the application, the built interface, the Node runtime, and the
official 7-Zip build — the one with the RAR codec, which the builds
distributions package do not have. Every native module in this tree has a
published prebuild for Node 24 on glibc, so no compiler is needed and none is
looked for.

Not in it: five tools your distribution already packages, each worth a
feature rather than the program:

Tool	Without it
ffmpeg	no video thumbnails, no stills from HEIC photos, no media durations
ripgrep	searching inside files falls back to a slower path
pdftotext	PDFs are not read into the search index
perl	RAW photo metadata is not read
rsync	large copies and moves lose their progress reporting

The script finds which are missing, says what each one buys, and offers to
install them through apt, dnf, pacman or zypper — one at a time, so a
name your distribution does not carry costs that one line rather than the whole
set. Install them later and they are picked up on the next start.

Updating, which is the same script

sudo nextexplorer-upgrade

It reads the latest release, downloads the archive for this machine, checks it
against the checksum published beside it, and hands over to that release's own
install script. Your configuration file, your database and your files are left
alone; the program is replaced wholesale, so a file that left the release stops
being installed. --check reports what there is and changes nothing.

Unpacking a newer archive and running ./install.sh again does exactly the
same thing. Running it twice changes nothing the second time.

Nothing updates on a timer. Updating a file server is a decision somebody
makes, not something that happens to them overnight.

What systemd does that the container had to do by hand

The unit names the account, so there is no PUID, no PGID and no chown -R
— a hundred and twenty lines of entrypoint replaced by four lines of
configuration. It is also hardened: the whole filesystem is read-only to the
service except its own two directories and the volumes. A volume outside
VOLUME_ROOT therefore wants a line in a drop-in, and a path that does not
exist stops the service instead of being quietly unwritable.

Two protections are deliberately left off, with the reason written in the unit:
V8 compiles as it runs and needs writable executable memory, and hardware video
decoding needs /dev/dri.

One behaviour changes, and it is a default rather than a footnote

The browser terminal is off. In the image it opens a shell inside the
container; here it would open one on the machine, as the account the service
runs as. TERMINAL_ENABLED=true in the configuration if that is what you want.

Where things live

/opt/nextexplorer	the program, the runtime and 7-Zip — replaced on every update
/etc/nextexplorer/nextexplorer.env	your configuration, written once and never touched again
/var/lib/nextexplorer	the database and the keys — back this up
/var/cache/nextexplorer	thumbnails and the search index, all disposable
/srv/nextexplorer	the volumes, one per folder inside it

sudo ./install.sh --uninstall removes the program and the service, and keeps
every file of yours.

On Alpine, and on Windows and macOS

The bundled runtime is linked against glibc, so on Alpine or another musl
system the script says so and stops rather than failing later — the Docker
image is the answer there. There is no release here for Windows or macOS.

Why not a single binary

Issue #9 asked for a
standalone binary and said an archive would do. It is an archive, and it will
stay one: Node's single-executable support cannot embed a native addon, and
there are three in this tree — the SQLite driver, the image processor and the
terminal — each with its own shared libraries. A "single binary" would be a
self-extracting archive that unpacked them at every start and still called out
to ffmpeg, 7z and rg as separate programs. FileBrowser Quantum ships one
file because Go compiles to a static binary with no native dependencies; that
is a property of the language, not a matter of effort.

How this is tested before it is published

The same workflow that publishes the images builds the archive, on every push
to main and on every release. Before anything is attached to a release it is
installed for real: on a runner with systemd, as root, checking that the
service answers with this version and that the bundled 7-Zip is reachable
through the unit's own PATH — then again inside a bare Debian and a bare
Fedora, where the package manager has to do its part and no Node exists at all.
Thirteen tests drive the install script in a sandbox for what matters on an
update: a configuration file somebody edited survives, the database and the
volumes survive, two identical runs change nothing, and an archive built for
another architecture is refused rather than unpacked.

Documentation: Install without Docker

The images are unchanged in this release and carry the same application:

ghcr.io/cerede2000/explorer:3.8.0
ghcr.io/cerede2000/explorer:3.8.0-lean