Guide to search in Filestash

Search is not a “one size fits all”, which is why Filestash delegates that decision to a plugin so you can pick the best solution for your own needs in line with our philosophy of a plugin-driven architecture. The default ships as a simple recursive implementation. Not because it’s the most powerful, but because we wouldn’t want Filestash indexing your content continuously by default, costing you CPU, network resources, and real money if you’re on a large S3 bucket where AWS charges per API call and for bandwidth. The options are:

Option 1: null: not every use case requires search. If you don’t define a search plugin, the search bar disappears entirely.

Option 2: plg_search_stateless: the default for every build. Not the most powerful option, but it’s stateless, there is no index to maintain and it makes no assumptions about where an index lives, how it gets populated, or whether there’s a cost to building one.

Option 3: plg_search_sqlitefts: the default choice for basic full-text search capabilities. The largest instance we run with this plugin indexes 55 million objects on S3 that are updated continuously by an ERP system in the background. At that scale, fine-tuning the indexer configuration matters. Under the hood the plugin runs its own crawler through four phases:

  1. discovery: maps the filesystem tree and tracks new files and folders. Visits and filesystem operations are used as hints to prioritise what the crawler processes next. You can also trigger this phase via the workflow engine if you want tight control over when it runs.
  2. indexing: extracts file content and feeds it into the full-text search index. There are many options for content extraction. Reach out if you need OCR or more specialised processing.
  3. maintenance: keeps the index from going stale by reflecting the current state of the filesystem.
  4. pause: backs off when there is nothing to do to avoid unnecessary load.

Option 4: plg_search_semanticsearch: a thin wrapper on top of plg_search_sqlitefts that uses an LLM to translate natural language queries into FTS queries, so you don’t need to be an expert in the SQLite FTS5 extension to run precise searches.

Option 5: plg_search_elasticsearch: for organisations that already have an Elasticsearch cluster and want to use it as their Filestash search backend.

Option 6: plg_search_solr: same idea as option 5, but for Solr.

Beyond these options, some plugins can also hook into the search engine to power smart folder functionality. plg_widget_recent, for example, keeps track of your activity and exposes a Recent folder that accepts natural language queries, letting users ask things like: “show me all the raw images I worked on today ordered by size”.

How to make your own search plugin: a search plugin in Filestash implements a single interface:

type ISearch interface {
	Query(ctx App, basePath string, term string) ([]IFile, error)
}

Create your own and register it by calling Hooks.Register.SearchEngine. That’s exactly how all the plugins above are built.