# Installation

Pick the path that matches how far you want to go. Trying it out?
[**Minimal**](#minimal) is one command, and you are signed in five minutes later.

| Path | What you get | Best for |
|---|---|---|
| [**Minimal**](#minimal) | One container, SQLite, a local folder. No external services. | Trying it out, small/personal use |
| [**Full stack (Compose)**](#full-stack-docker-compose) | filex + PostgreSQL + Redis + an S3 server + Caddy (auto-HTTPS); an ONLYOFFICE Document Server optional. | Real self-hosting, teams |
| [**Kubernetes (Helm)**](#kubernetes-helm) | Helm chart with toggles for the same components. | Clusters |
| [**App stores**](#app-stores) | Ready-made packages for Umbrel, CasaOS, Runtipi, Unraid, Portainer. | Home servers / NAS |
| [**Binary**](#binary) | A single static binary. | No Docker, systemd, edge devices |

All paths end at the same place: the app at `…/admin` (the operator's door) or at
`…/drive` (the neutral door, for the accounts you hand out). Both open **Home** -
your storages, what you opened last, what you starred - with the admin panel one
click away from the explorer's header for whoever is allowed it, and both start
with a first-run admin account (see [First run](#first-run)).

**Images.** `ghcr.io/brf-tech/filex:latest` is the full-featured image
(thumbnails for image/video/pdf/office included). `…:slim` is a smaller image
without the thumbnail toolchain - thumbnails then degrade to placeholder cards.
The binary inside both is identical; only the runtime tooling differs.

---

## Minimal

The fastest way to a running instance - SQLite, embedded search + thumbnails,
one local storage folder, nothing external.

```bash
docker run -d --name filex -p 5212:5212 \
  -e FILEX_PUBLIC_URL=http://localhost:5212 \
  -e FILEX_DEFAULT_STORAGE_DRIVER=local \
  -e FILEX_DEFAULT_STORAGE_PATH=/srv/files \
  -v filex-data:/data \
  -v "$PWD:/srv/files" \
  ghcr.io/brf-tech/filex:latest
```

The two `FILEX_DEFAULT_STORAGE_*` variables are what make the explorer show
something. Without them filex boots with no storage at all and the UI says
*"No storage configured"* - correct, and a poor first minute. With them, the
folder you bind at `/srv/files` is seeded as a **local** storage named `Files`
on first boot, so your files are there when you log in.

> `/data` and `/srv/files` are different things and should not be the same
> directory: `/data` is filex's own state (SQLite database, search index,
> thumbnail cache, first-run secret), `/srv/files` is content. A named volume
> for the first and a bind mount for the second keeps them apart.

Open <http://localhost:5212/admin> and grab the first-run password from the logs
(`docker logs filex`).

Prefer Compose? Use [`deploy/compose/docker-compose.minimal.yml`](../deploy/compose/docker-compose.minimal.yml):

```bash
cd deploy/compose
docker compose -f docker-compose.minimal.yml up -d
docker compose -f docker-compose.minimal.yml logs -f      # first-run creds
```

It mounts `./files` into the container at `/srv/files` and seeds it as the
default **local** storage, so anything you drop into `deploy/compose/files`
shows up in the explorer with no setup at all. More drivers - S3, SFTP,
WebDAV, FTP, SMB - are added from the admin UI (see [STORAGE.md](STORAGE.md)).

> Set `FILEX_PUBLIC_URL` to the URL people actually open. Behind a reverse proxy
> that's your `https://…` domain - it's baked into share links, the OIDC
> redirect, and the callbacks of an ONLYOFFICE Document Server, if you connect
> one.

**Office documents.** To edit Word, Excel and PowerPoint files, install the
**Office editor app** once you are signed in (*Admin → Plugins → Apps*, or
from the [filex Apps](https://apps.filex.sh) store): it edits them in the
browser, alone or together, and needs no other container; from its 0.4.0 it
also brings the office engine filex runs on the server for office thumbnails
and the apps' office conversions. filex does not install it by itself. See
[ONLYOFFICE.md → The Office editor app](ONLYOFFICE.md#the-office-editor-app).

---

## Full stack (Docker Compose)

A production-shaped, one-command stack: filex + **PostgreSQL** (database) +
**Redis** (queue) + an **S3 server** (Versity S3 Gateway) + **Caddy** (reverse
proxy with automatic HTTPS), and optionally **ClamAV** (antivirus - the filex
image ships no scanner, so it runs as its own container under the `clamav`
profile) and an **ONLYOFFICE Document Server** (the `onlyoffice` profile).
Files in [`deploy/compose/`](../deploy/compose/).

**1. Configure.**

```bash
cd deploy/compose
cp .env.example .env
$EDITOR .env          # set domains + secrets
```

Set `FILEX_DOMAIN` and strong secrets (`openssl rand -hex 24`).
`COMPOSE_PROFILES` picks the add-ons; the default runs draw.io and the S3
server.

> **Zero-touch config.** The admin account, SSO/LDAP/header auth, SMTP, branding
> and an initial storage can all be set through `FILEX_*` env in `.env`, so the
> stack comes up already configured (no first-run UI clicks). See
> [CONFIGURATION.md](CONFIGURATION.md) (Authentication + Zero-touch seeding) and
> the [`deploy/compose/`](../deploy/compose/) examples.

**2. DNS.** Point `FILEX_DOMAIN` (and the domain of every add-on you turned
on) at the host. Open ports **80 and 443** so Caddy can issue certificates.

**3. Launch.**

```bash
docker compose -f docker-compose.full.yml --env-file .env up -d
docker compose -f docker-compose.full.yml logs -f filex      # first-run creds
```

Caddy fetches HTTPS certs automatically; open `https://<FILEX_DOMAIN>/admin` (your
users: `https://<FILEX_DOMAIN>/drive`).

**4. Wire the bundled S3 server as a storage** (the `versitygw` profile). It
makes the bucket `FILEX_DEFAULT_STORAGE_S3_BUCKET` names (default `filex`) on
start; seed it as the default storage with Option A in `.env`, or **Storages →
Add** an S3 storage:

- endpoint `http://versitygw:7070` (filex reaches it over the internal network)
- `path_style` = true, `region` = `us-east-1` (part of the signature: `auto` is
  refused)
- `bucket` = `filex`, `prefix` = `files`
- `access_key` / `secret_key` = your `S3_ACCESS_KEY` / `S3_SECRET_KEY`

What it is, and how to move off the MinIO an older stack bundled:
[STORAGE.md → A local S3 server](STORAGE.md#a-local-s3-server).

**5. Office documents.** Install the **Office editor app** (*Admin → Plugins
→ Apps*, or the [filex Apps](https://apps.filex.sh) store): Word, Excel and
PowerPoint files then open in it, in the browser, with no Document Server
([ONLYOFFICE.md → The Office editor app](ONLYOFFICE.md#the-office-editor-app)).

**Optional: an ONLYOFFICE Document Server** - the Office editor app (0.4.0)
does what one did for filex (office thumbnails, the apps' office conversions,
the older `.doc`/`.xls`/`.ppt` formats and `.csv`); connect one to edit in
it, or for the fonts added to it
([ONLYOFFICE.md → Where it differs from a Document Server](ONLYOFFICE.md#where-it-differs-from-a-document-server)). Add `onlyoffice` to `COMPOSE_PROFILES`, uncomment
`ONLYOFFICE_DOMAIN`, `FILEX_ONLYOFFICE_URL` and `ONLYOFFICE_JWT_SECRET` in
`.env` (the **`ONLYOFFICE_JWT_SECRET` must be identical** between filex and
the Document Server - the compose file already wires the same variable to
both), point `ONLYOFFICE_DOMAIN` at the host, and run the `up -d` again. The
image is pinned to the version filex is tested against (`ONLYOFFICE_IMAGE`
picks another). See
[ONLYOFFICE.md → The ONLYOFFICE Document Server](ONLYOFFICE.md#the-onlyoffice-document-server-optional)
and [STORAGE.md](STORAGE.md).

> **Want a lighter "full"?** Delete the services you don't need from the compose
> file and drop the matching `FILEX_*` env from the `filex` service - everything
> is additive.

---

## Kubernetes (Helm)

The chart is in the BRF-Tech Helm repository, published with every release. It
deploys filex with a PVC for `/data` and an Ingress, and can pull in PostgreSQL,
Redis and an S3 server (Versity S3 Gateway) as optional dependencies, and wire
filex to an ONLYOFFICE Document Server you run yourself. Office documents need
none: install the Office editor app.

```bash
helm repo add brf-tech https://helm.brf.sh
helm repo update

# Minimal: filex + SQLite + a local PVC.
helm install filex brf-tech/filex \
  --set ingress.host=files.example.com
```

The same chart is on the GitHub Container Registry, with no `helm repo add`:

```bash
helm install filex oci://ghcr.io/brf-tech/charts/filex \
  --set ingress.host=files.example.com
```

**Full stack.** `values-full.yaml`, shipped inside the chart, turns on the
bundled dependencies:

```bash
helm pull brf-tech/filex --untar          # writes ./filex/values-full.yaml
helm install filex brf-tech/filex -f filex/values-full.yaml \
  --set ingress.host=files.example.com
```

An ONLYOFFICE Document Server you run (pin `onlyoffice/documentserver:9.4.0.1`,
JWT on) is wired with `--set onlyoffice.enabled=true`,
`--set onlyoffice.url=https://office.example.com` and
`--set onlyoffice.jwtSecret=<its JWT_SECRET>`.

**Versions.** The chart has its own version; its `APP VERSION` is the filex
release it installs (the image tag follows it unless you set `image.tag`).
Without `--version` you get the newest. To pin one, and to upgrade later with
your settings kept in a values file:

```bash
helm search repo brf-tech/filex --versions      # CHART VERSION and APP VERSION
helm install filex brf-tech/filex --version <chart version> -f my-values.yaml
helm repo update
helm upgrade filex brf-tech/filex --version <chart version> -f my-values.yaml
```

With OCI, `--version` takes the same chart version.

`helm show values brf-tech/filex` prints every setting with its comment. Key
toggles: `postgresql.enabled`, `redis.enabled`, `onlyoffice.enabled`,
`versitygw.enabled`, `persistence.size`, `ingress.*`, `basePath`,
`trustedProxies`, `resources`. The chart's source is
[`deploy/helm/filex/`](../deploy/helm/filex/); from a checkout,
`./deploy/helm/filex` works wherever these examples say `brf-tech/filex`.

`trustedProxies` sets `FILEX_TRUSTED_PROXIES`, the proxies whose
`X-Forwarded-For` filex believes - a
[seed](CONFIGURATION.md#variables-that-seed-a-stored-setting) since 0.57:
written into the **Sign-in security** list at the first start, so a later
`helm upgrade` that changes it needs the page or `kubectl exec <pod> --
filex settings reseed login.trusted_proxies`. Empty, it is `auto`: in a pod, the pod's own
interface subnet - a node's `/24` with flannel, the pod alone (`/32`) with
Calico or Cilium - so an ingress controller on **another node** is not trusted
and every visitor would resolve to its address. List your cluster's pod
network, keeping `auto`: `--set trustedProxies="auto, 10.244.0.0/16"` (or the
ingress controller's range); a CDN in front of the ingress is listed too. The
**Sign-in security** page names a peer that sends forwarded addresses without
being trusted ([CONFIGURATION.md → Trusted proxies](CONFIGURATION.md#trusted-proxies)).

To serve filex under a path of the host instead of its root
(`https://files.example.com/filex/`), set `basePath`: the chart sets
`FILEX_BASE_PATH` and routes that path on the Ingress, passing it through
unchanged - don't add a rewrite/strip annotation
([Serving filex under a sub-path](DEPLOYMENT.md#serving-filex-under-a-sub-path)):

```bash
helm install filex brf-tech/filex \
  --set ingress.host=files.example.com \
  --set basePath=/filex \
  --set publicURL=https://files.example.com/filex
```

> **Zero-touch config.** Auth (OIDC/LDAP/header), the first admin, SMTP, branding
> and a default storage can all be supplied as `FILEX_*` env in the chart values,
> so a fresh release boots fully configured with no admin-UI setup. See
> [CONFIGURATION.md](CONFIGURATION.md) (Authentication + Zero-touch seeding) and
> the [`deploy/helm/filex/`](../deploy/helm/filex/) values examples.

---

## App stores

Ready-made packages for the common home-server platforms live under
[`deploy/`](../deploy/) - each directory has a README with install steps.
All of them run the same single container (SQLite + local storage) and end at
the same [first run](#first-run).

- **Umbrel** - [`deploy/umbrel/filex/`](../deploy/umbrel/filex/): the Umbrel
  App Store package, proposed in
  [getumbrel/umbrel-apps#6375](https://github.com/getumbrel/umbrel-apps/pull/6375);
  login is `admin@local` + the password Umbrel shows for the app.
- **CasaOS / ZimaOS** - [`deploy/casaos/`](../deploy/casaos/): compose with
  the `x-casaos` store metadata (app id `sh.filex.filex`); paste it via
  *Install a customized app*.
- **Runtipi** - [`deploy/runtipi/filex/`](../deploy/runtipi/filex/): dynamic
  compose app; the install form asks for the (optional) first admin.
- **Unraid** - in **Apps** (Community Applications): search for `filex`, from
  *BRF Tech's Repository*
  ([BRF-Tech/unraid-templates](https://github.com/BRF-Tech/unraid-templates)).
  The template is [`deploy/unraid/filex.xml`](../deploy/unraid/); map a share
  to `/srv/files` and set the Public URL.
- **Portainer** - [`deploy/portainer/`](../deploy/portainer/): App Templates
  v3 JSON; add the raw URL under *Settings → App Templates*.
- **TrueNAS** - an app for the community train is proposed in
  [truenas/apps#6515](https://github.com/truenas/apps/pull/6515); it lives in
  that repository, not under `deploy/`.

---

## Binary

filex ships as a single static binary (CGO-free) for linux/macOS/Windows ×
amd64/arm64. Download the archive for your platform from the **Releases** page,
extract, then:

```bash
./filex serve
```

Configuration is via `FILEX_*` environment variables (see
[CONFIGURATION.md](CONFIGURATION.md)) or a `config.yaml`
(`filex serve --config /path/to/config.yaml`, or the `FILEX_CONFIG` env). Data
goes to `~/.filex` by default (override with `FILEX_DATA_DIR`).

**systemd** (Linux):

```ini
# /etc/systemd/system/filex.service
[Unit]
Description=filex file manager
After=network-online.target
Wants=network-online.target

[Service]
Type=simple
User=filex
ExecStart=/usr/local/bin/filex serve
Restart=on-failure
RestartSec=5s
Environment=FILEX_DATA_DIR=/var/lib/filex
Environment=FILEX_LISTEN=127.0.0.1:5212
Environment=FILEX_PUBLIC_URL=https://files.example.com

[Install]
WantedBy=multi-user.target
```

```bash
sudo useradd --system --home /var/lib/filex --create-home filex
sudo install -m 0755 filex /usr/local/bin/filex
sudo systemctl enable --now filex
```

Put it behind a reverse proxy for TLS (see [Behind a reverse proxy](#behind-a-reverse-proxy)).

**Thumbnail tools (optional).** The binary draws image, SVG, text and archive
thumbnails by itself. Video, audio, PDF and HEIC/AVIF previews need programs on
`PATH`; on Debian or Ubuntu:

```bash
sudo apt install ffmpeg ghostscript poppler-utils \
  imagemagick libheif-plugin-libde265
```

Office documents are not a program here: they are edited in the Office editor
app, and their previews and the apps' office conversions (the Convert app's
Word/Excel/PowerPoint/OpenDocument targets) come from an office engine - the
one the Office editor app brings (0.4.0), run on the server, or an ONLYOFFICE
Document Server you connect under **External services**
([ONLYOFFICE.md](ONLYOFFICE.md#the-office-engine-without-a-document-server)). filex runs no LibreOffice, even one
installed on this machine.

⚠ `libheif-plugin-libde265` is the HEVC decoder a HEIC photo needs. Ubuntu
24.04's `libheif1` only *suggests* it, so `apt install imagemagick` alone
leaves ImageMagick listing HEIC and decoding none. filex checks at start by
decoding a sample: **About** then shows **HEIC photos: Not found** and the
photos are listed under **Admin → Tools → Thumbnail repair** with the package
to install. Restart filex after installing any of these. See
[thumbnails.md](thumbnails.md#generators--required-tools).

### Build from source

Requires Go 1.25+, Node 20+, pnpm 9+.

```bash
git clone https://github.com/BRF-Tech/filex.git
cd filex
pnpm install
pnpm run build:all      # packages -> admin UI -> embed -> Go binary
./bin/filex serve
```

`CGO_ENABLED=0` means you can cross-compile without a C toolchain
(`GOOS=linux GOARCH=arm64 go build ./backend/cmd/filex`).

---

## ARM (arm64)

Every release builds these and runs them on arm64 machines before publishing:

| | arm64 |
|---|---|
| Server + CLI binary | Linux, macOS and Windows: `filex-<os>-arm64` and the `.tar.gz` / `.zip` archives |
| Docker images (`ghcr.io/brf-tech/filex`, full and slim) | multi-arch - `docker pull` picks arm64 by itself |
| Desktop app - Linux | `filex-desktop-arm64.AppImage`, `filex-desktop-arm64.deb`, `filex-desktop-aarch64.rpm`, and the Snap Store (`sudo snap install filex-app` picks arm64) |
| Desktop app - Windows on Arm | `filex-desktop-arm64.exe` (installer) and `filex-desktop-portable-arm64.exe`; the app updates itself to the arm64 build |
| Desktop app - macOS | Apple Silicon only (no Intel build) |
| Homebrew | the CLI (`filex`) on Apple Silicon and on Linux on Arm; the desktop app (`filex-app`) on Apple Silicon |
| winget | the CLI (`BRFTech.filex`) on Windows on Arm - winget picks the arm64 build by itself |

On an Arm machine the app's *Get the desktop app* offer (and its copy in
Settings) leads with the arm64 file and the download list on
[filex.sh](https://filex.sh/#downloads) highlights it, from what the browser
reports (Chromium's client hints, Firefox's `aarch64`). A browser that does not
say (Safari, Firefox on Windows) is offered the x64 file with the arm64 one
beside it. The desktop downloads, with their links: [DESKTOP.md → Download](DESKTOP.md#download).

---

## First run

On the very first start (empty user table) filex creates an admin account and
prints the password **once**:

```
  ─── First run detected ─────────────────────────────────────
  Admin user created:
    Email:     admin@local
    Password:  <generated 16-char password>
  Saved to:  <data-dir>/.first-run.txt (mode 0600, shown ONCE)
  Change at: /admin/dashboard?settings=1
```

The account's username is **`admin`**, whatever its email: the SFTP, FTPS and
sign-in forms accept either. `admin` is reserved - no other account can take
it, and a later account whose email starts with `admin@` becomes `admin2`.
(Installs created before v0.43.0 keep the name their first administrator
already has, usually `admin2`.)

That last line is a deep link, not a page: the account fields live in the
**user-settings dialog** behind the avatar menu, and a dialog has no address of
its own to print. Sign in at `…/admin`, open it, and change the password under
**Account**. Lost the password? Reset from the CLI:

```bash
filex admin random-password --email admin@local
# in Docker:  docker exec filex filex admin random-password --email admin@local
```

Enable TOTP 2FA per user under **user settings → Security**. Add SSO/LDAP via
[SSO.md](SSO.md) / [CONFIGURATION.md](CONFIGURATION.md). On a binary install,
people can also sign in with the Windows or Linux account of the machine filex
runs on ([OS-LOGIN.md](OS-LOGIN.md); the Linux one is not for Docker). Wrong
passwords are limited from the first start - put your own address on the
allow-list before you need it
([sign-in attempt limits](CONFIGURATION.md#sign-in-attempt-limits)).

---

## Behind a reverse proxy

filex serves everything from **one origin** on port `5212` - the SPA, the API,
public share (`/s/…`) and file-drop (`/d/…`) pages, `/embed.js`, the realtime
WebSocket at `/api/ws`, `/healthz`.
Forward `/` to `filex:5212` and:

- set `FILEX_PUBLIC_URL` to the external `https://…` URL,
- pass the real client IP (`X-Real-IP` / `X-Forwarded-For`) - used for audit,
  file-drop rate limiting and the sign-in attempt limit, and believed only from
  a trusted proxy (`FILEX_TRUSTED_PROXIES`; by default `auto`: this machine
  and, in a container, the other containers on its network - list a proxy on
  the host in front of the container, on another machine, or a CDN in front of
  your proxy; since 0.57 the variable seeds the **Sign-in security** list at
  the first start, and that list wins after it -
  [Trusted proxies](CONFIGURATION.md#trusted-proxies)),
- allow large bodies (e.g. `5G`) and long timeouts for uploads,
- allow WebSocket/SSE upgrades - `/api/ws` (the socket an open explorer runs
  on; blocked, it silently falls back to re-listing every 12 s) and the MCP
  stream at `/api/ai/mcp` - and pass the real `Host` header, because the
  same-origin upgrade is origin-checked,
- enable gzip for the admin SPA.

The bundled Caddy config ([`deploy/compose/Caddyfile`](../deploy/compose/Caddyfile))
already does all of this; an nginx example is in [DEPLOYMENT.md](DEPLOYMENT.md).

**Under a path instead of a host of its own** - `https://example.com/filex/` -
set `FILEX_PUBLIC_URL=https://example.com/filex` (its path becomes the base, or
set `FILEX_BASE_PATH=/filex`) and have the proxy forward `/filex/…` **with the
path unchanged**: Caddy `handle`, not `handle_path`. Caddy and nginx examples:
[DEPLOYMENT.md → Serving filex under a sub-path](DEPLOYMENT.md#serving-filex-under-a-sub-path).

---

## Data & backup

Everything filex owns lives under `FILEX_DATA_DIR` (`/data` in Docker):

- `instance.sqlite` - the database (unless you use PostgreSQL/MySQL),
- `search.bleve/` - the full-text index (rebuildable),
- `thumbs/` - the thumbnail cache (regenerable; released when a file is purged,
  and swept for orphans every `FILEX_THUMBS_SWEEP_INTERVAL`),
- `cache/` - the read cache for slow storages (disposable),
- `uploads/` - staging for chunked and resumable uploads. ⚠ Until a transfer
  commits, this is the file's only copy - it is not disposable while one is in
  flight,
- `ssh/` and `ftps/` - the SFTP host keys and the FTPS self-signed certificate,
  generated on the first boot that enables those listeners. Regenerable, but
  regenerating them is a **changed host key**: every client that has connected
  before refuses the next connection until somebody clears it,
- `plugins/`, `dav/` - installed storage-plugin binaries and the WebDAV lock
  store,
- `.first-run.txt` - the initial admin secret.

Back up the **database** (the SQLite file, or your Postgres), your **storage
backends**, and ⚠⚠ **`FILEX_SECRET_KEY`** if you set one - it seals the S3
access keys, so a restored database without the matching key has access keys
that no longer verify. See
[Backup & restore](DEPLOYMENT.md#backup--restore). The search index and
thumbnail cache can be rebuilt (`POST /api/admin/search/rebuild`,
`filex thumb backfill`), so backing them up is optional.

---

## Upgrading

Pull the new image (or binary) and restart - **migrations run automatically on
startup**. Back up the database first. To roll a schema back one step manually:
`filex migrate down`.

⚠ **A Compose stack or Helm release that bundled MinIO** (before 0.50): the
bundled S3 server is now Versity S3 Gateway, and MinIO's data has to be copied
across. Nothing is deleted for you, and the chart refuses to render until you
have kept the old volume - follow
[STORAGE.md → Moving off the bundled MinIO](STORAGE.md#moving-off-the-bundled-minio)
before you upgrade.

---

## Nightly builds

To try what the next release brings before it ships:

```bash
docker pull ghcr.io/brf-tech/filex:nightly              # the server, the newest
docker pull ghcr.io/brf-tech/filex:nightly-20261014     # one night's, kept
sudo snap install filex-app --edge                      # the desktop app (x64 and arm64)
```

The desktop app of the same night, for Windows (x64, arm64), macOS and Linux
(AppImage, `.deb`, `.rpm`; x64 and arm64), is at
**[filex.sh/nightly](https://filex.sh/nightly/)**: the night, the commit, a
download per platform and the checksums. The last nights are kept as OCI
artifacts:

```bash
oras pull ghcr.io/brf-tech/filex-desktop-nightly:nightly            # the newest night's packages
oras pull ghcr.io/brf-tech/filex-desktop-nightly:nightly-20261014   # one night's
```

A nightly is the tip of the source after the nightly test run passed on it -
every suite, every browser - built only on a night with a change since the
last one: the server image (the full one, x64), the snap on the Snap Store's
`edge` channel ([DESKTOP.md → The Snap Store's channels](DESKTOP.md#the-snap-stores-channels))
and the desktop packages, made from the same public tree. The desktop
packages are not signed: Windows SmartScreen and macOS Gatekeeper warn
before they open one (on macOS: right-click the app, *Open*).

**Which commit it is**, read off the image itself:

```bash
docker run --rm --entrypoint /usr/local/bin/filex ghcr.io/brf-tech/filex:nightly --version
docker inspect --format '{{json .Config.Labels}}' ghcr.io/brf-tech/filex:nightly
```

The version is the next minor as a pre-release, with the night and the commit
(`0.57.0-nightly.20261014+2ca25999`); the admin panel's *About* shows it too,
and so does filex.sh/nightly (the desktop packages and the snap carry the
same, cut to the Snap Store's 32 characters when it is longer). The
labels say the same commit (`org.opencontainers.image.revision`), the
released public commit it was built on (`sh.filex.nightly.public-base`: a
nightly is that release plus what [CHANGELOG.md](../CHANGELOG.md) lists under
*Unreleased*) and its night's test result (`sh.filex.nightly.tests`).

> ⚠ **Not supported, and not for the data you keep.** A nightly may carry a
> database migration the release it is heading for still changes, and a
> release's own migration may not run cleanly over it: going from a nightly
> back to a release is not a supported path. Run it on a copy - a fresh
> volume, or a backup restored for the purpose ([Data & backup](#data--backup)).
> An instance on a nightly is offered the release it leads to when that ships
> (the version sorts below it, [UPDATES.md](UPDATES.md)); a newer nightly is
> a `docker pull` of `:nightly` again. A desktop app from filex.sh/nightly does
> not update itself to the next nightly: download the next one.

---

## See also

- [CONFIGURATION.md](CONFIGURATION.md) - every `FILEX_*` variable
- [STORAGE.md](STORAGE.md) · [SSO.md](SSO.md) · [ONLYOFFICE.md](ONLYOFFICE.md)
- [DEPLOYMENT.md](DEPLOYMENT.md) - reverse proxy, HTTPS, scaling, backup