Stash's four install channels, its unsigned binaries, and its FFmpeg floor

Four download channels, and each one carries a different platform floor

The installation table gives four distinct paths, and they are not interchangeable. Windows gets stash-win.exe, macOS gets Stash.app.zip, Linux gets stash-linux for amd64 with more architectures linked from the releases page, and Docker is reached through the instructions in docker/production/README.md alongside a sample docker-compose.yml. Every platform also has a second link marked Development Preview pointing at the latest_develop release, so the table hands you two builds per platform rather than one.

The floors underneath them move. As of version 0.27.0, Windows 7, 8, Server 2008 and Server 2012 are no longer supported and at least Windows 10 or Server 2016 is required. On macOS, version 0.29.0 requires macOS 11 Big Sur or later and version 0.32.0 requires macOS 12 Monterey or later, and older macOS versions can still be run through Docker.

That last clause is worth noticing on its own. Docker is not only a hosting choice here; it is how the project keeps a superseded hardware floor reachable after the native binary abandons it. A reader who assumes Docker is a server-only option meets it again as the documented path for a Mac that cannot run the current application. Step-by-step instructions for every channel live at docs.stashapp.cc/installation rather than in the README itself.

The Windows and macOS binaries are unsigned, so the first launch needs a manual bypass

On Windows or macOS, running the app might present a security prompt since the application binary isn't yet signed. The documented workarounds are per machine and per user: on Windows, click "more info" and then the "run anyway" button, and on macOS, Control+Click the app, click "Open", and then "Open" again.

Neither fix changes the binary. Nothing you do produces a signed application, so what you are really doing is telling the local gatekeeper to ignore one file on one machine. On a workstation you administer yourself that is a ten second click. On a shared machine, a centrally managed corporate Mac, or anywhere Gatekeeper or SmartScreen policy is enforced by someone else, the bypass is not yours to perform and the download simply will not open.

For anyone evaluating Stash this is the first thing to test, because it is where works-on-my-laptop and works-on-the-users-laptop come apart. If the plan is to hand the Mac app zip or the Windows executable to anyone outside your own hardware, budget for signing work the project does not do, or take the Docker path and accept the different platform floor that comes with it.

Stash 0.32.0 and the macOS 12 requirement

The newest tagged release is v0.32.0 from 2026-11-02, following v0.31.1 from 2026-04-13, with a rolling latest_develop build sitting on top of it. The macOS notes say that as of version 0.32.0 Stash requires macOS 12 Monterey or later, having required macOS 11 Big Sur or later since version 0.29.0.

So what the Latest Release link installs on a Mac today is 0.32.0, and the Monterey rule is the one that binds it. A Mac that cannot run macOS 12 is left with the Docker path, which the README says can still run older versions.

FFmpeg is a hard prerequisite, and setup offers to download it for you

Stash requires FFmpeg. If you do not have it installed, Stash will prompt you to download a copy during setup, and Linux users are recommended to install ffmpeg from their distro's package manager. This is the only third-party prerequisite the README names, and its position tells you where the work happens in a tool that indexes both video and image formats.

Two consequences follow. First, a first run is not purely configuration. It is a setup dialogue that can reach out and fetch a binary, so on a machine behind a proxy, on an air-gapped host, or anywhere outbound downloads are blocked, that prompt is where an install stalls. Having ffmpeg present before the first launch removes the stall, and on Linux the distro package keeps your system's own update cycle in charge of the binary instead of a copy fetched at setup time.

Second, ffmpeg is external, so its version is not pinned by Stash. What you see out of the index is a function of two version numbers rather than one, and after a Stash upgrade the first question about changed thumbnail or transcoding behavior is which side of that pair actually changed.

StashDB is one stash-box among many, and community scrapers behave differently

Stash pulls metadata such as performers, tags, descriptions and studios from outside sources, and it offers two shapes of source that do not behave alike. StashDB is the crowd-sourced repository maintained by the Stash team, running on the open source stash-box software and focused primarily on mainstream digital scenes and studios; connecting it lets Stash automatically identify much of a typical collection, and access runs through an invite code. Several community-managed stash-box databases can be connected in a similar manner, each serving a slightly different niche and following its own methodology.

Then there are scrapers. Many community-maintained ones can be downloaded, installed and updated from inside the running application at Settings → Metadata Providers → Available Scrapers → Community (stable). The project's own wording is that these can be trickier to use than a stash-box because every scraper works a little differently.

That difference is the operational one. A stash-box is a database connection with a shared shape and a sign-up flow, so behavior settles once you are connected. A scraper is code you install per site, with per-site behavior, and you own the outcome when one drifts or breaks. For a large import, the consequence is that the stash-box layer is configured once while the scraper layer is something you keep returning to.

The develop branch and its rolling build

The default branch is develop, not main, and the build published under the tag latest_develop identifies itself as v0.32.0-1-g944dd694 with the description Latest development build. Read that string literally: it is v0.32.0 plus one commit, ending at commit 944dd694. The last push recorded for the repository is 2026-11-02, the same day v0.32.0 was released.

So the rolling build and the stable tag can describe the same codebase at different points. Anyone reading the version number off a running instance needs to know which of the two channels produced it, because a behavior difference between two machines may be nothing more than one on latest_develop and one on v0.32.0.

The repository is not in trouble, and it is not archived. Its top-level layout shows the ordinary machinery of a Go project under active work: a Makefile, a cmd directory, an internal and pkg split, a graphql directory, generated client configuration in .gqlgenc.yml and gqlgen.yml, linting through .golangci.yml, and a docs directory. What the branch choice means for you is narrower. Cloning gets you develop; for a reproducible build, check out a specific tag or commit.

A cgo build with sqlite build tags, cross-compiled through a compiler image

Building from source turns on cgo and appends two SQLite extensions. The module declares its identity and language level in go.mod:

module github.com/stashapp/stash

go 1.25.0

The Makefile exports one flag unconditionally and adds its tags to whatever the environment already carries:

export CGO_ENABLED := 1

The two tags appended are sqlite_stat4 and sqlite_math_functions, and the Makefile notes they can be extended through the GO_BUILD_TAGS environment variable. What cgo is for shows up in go.mod, which requires github.com/mattn/go-sqlite3, so the database layer is a C library bound into the binary rather than a pure Go one. The same dependency list carries a browser driver (chromedp and cdproto), a JavaScript runtime for Go (goja), image hashing and image processing libraries, gorilla/websocket, chi for HTTP, and GraphQL client and generator packages, which is a plausible shape for a scraper-driven organizer.

Cross-compilation goes through a container. The Makefile defaults COMPILER_IMAGE to ghcr.io/stashapp/compiler:latest for that purpose, so producing a binary for a platform you do not build on makes Docker part of the build toolchain and not only a deployment option.

Configuration arrives by file, environment and flag, and the README names none of them

The dependency list in go.mod is effectively a map of how Stash is configured, even though the README never hands you the settings themselves. It requires github.com/knadh/koanf/v2 with a YAML parser and three providers: one for environment variables, one for files, and one for command line flags. A running instance can therefore take configuration from a YAML file, from environment variables, or from flags, with koanf merging the sources rather than choosing one.

The build side follows the same habit. The Makefile reads LDFLAGS, GO_BUILD_FLAGS and GO_BUILD_TAGS from the environment, accepts OUTPUT to rename both binaries at once or STASH_OUTPUT and PHASHER_OUTPUT to rename them individually, and takes STASH_SOURCEMAPS to emit UI source maps. It also detects a Windows shell from SHELL and switches its own variables, from rm -f to del /s /q and from a $(HOME)/.local prefix to one under the Windows user profile, which is how a single Makefile survives both platforms.

None of those variable names are documented in the README, and the repository listing contains no sample configuration file. For a reader the consequence is that the interface amounts to one address and nothing more: the app is available by default from http://localhost:9999, with no hostname, no certificate and no transport security mentioned in that section. Anything beyond the default loopback interface has to come from the documentation site or from reading the koanf providers, and a self-hosted install on a shared network is exactly where that gap bites.

Editorial conclusion

Stash suits a collection you host on your own hardware and control yourself, at the cost of an unsigned binary, a mandatory FFmpeg, and per-scraper inconsistency you have to absorb. Before committing, confirm that your machine meets the floor for v0.32.0, which needs macOS 12 Monterey or later on a Mac and Windows 10 or Server 2016 on Windows, and read the AGPL-3.0 license yourself rather than assuming the README summarizes it.

Frequently asked questions

Official sources

1. License: AGPL-3.0
2. Project website
3. README
4. Releases
5. stashapp/stash on GitHub