Filestash: a storage-agnostic file manager that speaks every protocol

The problem Filestash solves: too many storage protocols, one browser tab

Most teams do not standardise on one storage protocol. A single department can end up with an SFTP box from a vendor, an S3 bucket from a cloud migration, an SMB share on a NAS, and a WebDAV endpoint from a SaaS tool. Each has its own client, its own credentials, and its own way of presenting a directory tree. Filestash's stated goal is to collapse that into one interface: the README describes it as having started as a storage-agnostic Dropbox-like file manager that speaks every storage protocol, listing SFTP, S3, SMB, WebDAV, IPFS, FTP and NFS, with a link to everything else.

The audience is therefore not the individual developer who wants a nicer file browser on their laptop. It is the person who has to give other people access to heterogeneous storage: an IT administrator running a small file service, an integrator wiring a customer's existing NAS into a web portal, or a team that wants a self-hosted alternative to handing everyone a cloud account. The README frames the project as four separate products (a web client, a native client for device sync, a native client for agents, and gateways that expose storage over other protocols), which tells you the maintainer thinks of Filestash as a platform rather than a single binary.

Plugin-first architecture and how the three products fit together

The design principle is stated plainly in the README: "anything that's not a fundamental truth of the universe lives in a plugin". The claimed benefit is a lean core with replaceable opinions, so that unusual requirements are answered with a plugin rather than a fork. The repository layout backs this up. There is a server directory, a public directory, a cmd entry point, an embed.go at the top level, and a docker directory. The Go module is github.com/mickael-kerjean/filestash, and the dependency list in go.mod is unusually broad for a file manager: cloud.google.com/go/storage, the Azure azblob SDK, aws/aws-sdk-go, go-smb2, pkg/sftp, go-webdav, go-git, go-ldap, go-redis, lib/pq and mattn/go-sqlite3 all appear. That is what a storage-agnostic core looks like from the inside: each protocol is a separate client library pulled in behind a common interface.

The same pattern shows up on the authentication side. The dependency list includes SAML, Duo Universal, TOTP via pquerna/otp, LDAP and JWT libraries. The README gives a concrete example of how far this goes: a virtual filesystem that delegates authentication to a WordPress site and uses its roles to drive RBAC authorization. That is a specific, verifiable mechanism rather than a marketing claim, and it is the clearest illustration of the plugin philosophy in the documentation.

The products are distinct. The web client is the browser file manager. The native client for humans is a separate repository, mickael-kerjean/fdrive, with screenshots for mac, Windows, Linux and Android. A native client for agents provides a shared folder that syncs for agents. The gateways expose storage over protocols such as SFTP, S3, FTP, WebDAV, MCP and AS2. Note that the native client lives outside this repository, so anyone evaluating Filestash as a whole is really evaluating two codebases with different release rhythms.

Installing Filestash from source and connecting a first backend

The repository ships a Makefile rather than a documented package. The README links to an install-and-upgrade documentation page for configuration, but the build path visible in the repository is the Makefile itself. Its all target runs init then build. The init target runs go get ./... followed by go generate -x ./server/..., which means code generation is part of a normal build, not an optional step. The build target compiles cmd/main.go with the fts5 build tag and writes the binary to dist/filestash, appending .exe when GOOS is windows.

make init
make build

Running those two targets in order is the sequence the Makefile defines. The result is dist/filestash (or dist/filestash.exe on Windows). Because the build tag is fts5 and sqlite3 is in the dependency list, expect cgo and a C toolchain to be involved; the Makefile does not say so, but the build tag and the sqlite3 driver are the evidence.

The docker directory at the top level is where container builds live. The Makefile does not define a docker target, so a reader who wants the container path should read the files in docker/.

For a first real use, the shape of the workflow is: start the binary, open the web client in a browser, and add a storage backend. The README points to the demo at demo.filestash.app and to the storage plugin documentation for the full list of backends. Which fields a given backend needs depends on that plugin's documentation, and the README does not enumerate them. What it does make clear is that the web client is only one access path: the same storage can be re-exposed through a gateway over SFTP, S3, FTP, WebDAV, MCP or AS2, and the README links to a worked SFTP gateway example.

Where Filestash stops being the right tool

The plugin philosophy has a cost that the README does not dwell on. If everything is a plugin, then the quality and completeness of your experience depends on the plugin you pick, and the core can only be as good as the least finished integration. The README's own ambition, to support 100% of storage and authentication technologies on the market, is a statement of intent rather than a guarantee, and it is the kind of goal that is never quite reached.

The build is another boundary. go generate runs against the server tree during init, and the build tag fts5 plus the sqlite3 dependency imply a cgo toolchain. Anyone hoping for a pure static cross-compile from a minimal environment should verify that before planning a deployment pipeline around it; the Makefile does not offer an alternative path.

The native sync client is a separate repository. If your requirement is desktop or mobile sync rather than a browser file manager, you are adopting fdrive, not this repository, and you should evaluate it on its own terms.

Finally, the file-app plugins are broad but shallow in the sense that each covers a format family. The README lists photography formats, astronomy formats, GIS formats, data engineering formats such as parquet and arrow, and dev formats including sqlite and pcap. If your need is deep editing of one of those formats rather than viewing and organising files, a dedicated application remains the better choice.

Filestash compared with Filebrowser and Nextcloud

A common comparison is Filestash against Filebrowser, and the difference is architectural. Filestash is built around a plugin system whose explicit purpose is to avoid forking: storage backends, authentication providers and file viewers are all plugins, and the dependency list shows separate client libraries for S3, Azure Blob, SMB, SFTP, WebDAV, Google Cloud Storage and Git. The README's framing of gateways reinforces this: the same storage can be exposed over SFTP, S3, FTP, WebDAV, MCP or AS2, which is a different product category from a file browser that shows you a directory.

Against Nextcloud the distinction is scope rather than mechanism. Nextcloud is a collaboration suite with its own storage model and its own clients. Filestash does not store your files; it connects to storage you already have and presents it. That is the whole point of the storage-agnostic positioning, and it is also the reason Filestash will not give you calendars, document co-editing or a groupware layer. If your requirement is a collaboration platform, Filestash is the wrong shape. If your requirement is a single pane over storage that already exists in five different places, the plugin model is aimed exactly at that.

Licence, maintenance and what an upgrade actually costs

Filestash is licensed AGPL-3.0. For a self-hosted internal deployment this is usually unremarkable, but the AGPL's network clause matters if you expose a modified Filestash to users over a network. The README does not discuss licensing implications, and nothing here is legal advice; the point is that the licence is a design constraint you should resolve before building a product on top of the code. If you need to embed a file manager in a closed-source offering, AGPL-3.0 is the wrong licence and no amount of plugin architecture changes that.

The repository is not archived, and the last push was on 2026-10-29. That recency is the only maintenance signal: the repository has no published GitHub releases, so there is no version history to reason about, and the README links to install-and-upgrade documentation. Upgrading from source means re-running the Makefile targets, which regenerates code and rebuilds the binary. A team running Filestash in production should keep the previous binary before upgrading.

The dependency surface is the real upgrade cost. go.mod pins a large set of SDKs, including pre-release modules such as go-git v6.0.0-alpha.3 and several fork-maintained packages under the mickael-kerjean namespace. Every one of those is something that has to keep compiling as the Go toolchain and the upstream SDKs move.

Editorial conclusion

Adopt Filestash if you need one browser-based file manager over a mix of FTP, SFTP, S3, SMB, WebDAV or IPFS backends and you can live with AGPL-3.0. Do not adopt it if you need a permissively licensed component to embed in a closed product, or if you want a plain local-filesystem browser: the repository's plugin and storage lists are where that boundary sits. Before committing, verify which storage plugin you actually need, check that the AGPL-3.0 terms fit how you will distribute or host the software, and build from source with the Makefile to confirm the Go toolchain and cgo dependencies resolve on your platform.

Frequently asked questions

Official sources

1. Issues
2. License: AGPL-3.0
3. mickael-kerjean/filestash on GitHub
4. Project website
5. README