unsubbed.co

Fess

Fess lets you run powerful and deployable Enterprise Search Server entirely on your own server.

Self-hosted enterprise search, honestly reviewed. Built on OpenSearch, ships its own crawler, and costs nothing to license.

TL;DR

  • What it is: Open-source (Apache 2.0) enterprise search server built on OpenSearch, with a built-in web/file/data crawler and browser-based admin UI [1].
  • Who it’s for: Ops teams, IT departments, and technical founders who need to make internal documents, wikis, or websites searchable — without paying Algolia prices or assembling an Elasticsearch stack from scratch [2].
  • Cost savings: Algolia’s paid tiers start around $0.50 per 1,000 searches and climb fast at volume. Fess runs on any Java or Docker environment; a $6–10/mo VPS is the only recurring bill [1][2].
  • Key strength: Genuinely broad crawling surface — web servers, file systems, Windows shares, and 15+ data stores including Confluence, SharePoint, Slack, S3, and Salesforce — all configurable through a browser UI without touching config files [1].
  • Key weakness: 1,095 GitHub stars is modest for an enterprise tool, documentation is almost entirely in Japanese or terse English, and third-party reviews in English are nearly nonexistent — which is both a flag and an opportunity [1].

What is Fess

Fess is a full-text search server. You point it at your content — a website, a file share, a SharePoint instance, a Slack workspace — and it crawls, indexes, and exposes a search UI on top of OpenSearch. The tagline on the website is “easily set up in just 5 minutes,” which is accurate if you’re running Docker and already know what you want to crawl [2].

The core idea is that running OpenSearch (or Elasticsearch) yourself is straightforward, but building the crawler, the admin UI, the access-control layer, the file format parsers, and the search front-end on top of it is where teams bleed weeks of engineering time. Fess ships all of that pre-assembled [1][2].

The project is maintained by CodeLibs, a Japanese open-source organization. It’s released under the Apache License 2.0 — genuinely permissive, no commercial redistribution restrictions, no “fair-code” asterisks [1]. As of this writing it has 1,095 GitHub stars, which is small for a tool of this scope. The explanation is partly language barrier: the project has been active for years and the Japanese-language community around it is substantially larger than what GitHub stars reflect. The latest release is 15.5.0, pushed in February 2026, indicating active maintenance [2].

Fess’s closest spiritual ancestor is the enterprise search appliance — the kind of thing that large organizations used to buy from vendors like Autonomy or Endeca. Fess does the same job without the license fee or the proprietary lock-in.


Why people choose it

Independent English-language reviews of Fess are scarce — that’s just the reality of a Japanese-origin project with modest GitHub visibility in English markets. What follows is drawn from the official documentation, README, and the tool’s own feature surface.

The case for Fess comes down to three things.

It indexes what other tools can’t reach. Most search-as-a-service offerings index web content or databases. Fess also crawls Windows shared folders, local file systems, Git repositories, Confluence and Jira instances, Dropbox, G Suite, Office 365, Salesforce, SharePoint, and Slack [1]. That’s the list that matters when someone says “I want to search everything we have” and “everything” isn’t just a website.

It handles access control. Fess supports BASIC, DIGEST, NTLM, and FORM authentication for crawling protected pages, and differentiates search results based on login status. SSO integration via Active Directory and SAML means search results can be filtered to what a user is actually allowed to see — which is non-trivial to implement on top of a raw OpenSearch cluster [2].

The license is clean. Apache 2.0 means you can deploy it internally, embed it in a commercial product, or offer it to clients without contacting a lawyer. This matters when you’re building a product on top of it or deploying it for an enterprise client who has a legal team [1].

The obvious trade-off is that Fess is Java-based, which means the memory footprint is meaningful (plan for at least 2–4GB RAM), and the documentation assumes you know what you’re doing. This is not a tool you hand to a non-technical founder with a weekend to spare.


Features

Based on the GitHub README and official website [1][2]:

Crawler:

  • Web page crawling with support for custom request headers, domain handling, path conversion [2]
  • File system crawling including Windows shared folders [1]
  • Data store connectors: Confluence/Jira, Box, CSV, Database, Dropbox, Elasticsearch, Git, Gitbucket, G Suite, JSON, Office 365, S3, Salesforce, SharePoint, Slack [1]
  • File format support: Microsoft Office (Word, Excel, PowerPoint), PDF, ZIP, and others [1]
  • OCR integration for image-based text extraction [2]
  • Scheduler for automated crawl runs, configurable in the admin UI [1]

Search:

  • Faceted search and drill-down filtering [2]
  • Label-based result classification [2]
  • Auto-complete and query suggestions [2]
  • Location-based search with map integration [2]
  • Cached document display and thumbnail previews [2]
  • Responsive design, works on mobile [2]
  • JavaScript snippet for embedding search into existing websites [2]

Security:

  • BASIC, DIGEST, NTLM, FORM authentication for crawling [2]
  • Login-status-aware result filtering [2]
  • Active Directory and SAML SSO [2]

Administration:

  • Full browser-based admin UI — crawl targets, scheduling, user dictionaries, synonym dictionaries [1][2]
  • Search log and click log aggregation [2]
  • REST API for external integration and access token management [2]
  • Plugin system for extending functionality [2]

Deployment:

  • Runs on any OS with a Java runtime [1]
  • Docker and Docker Compose images published on ghcr.io [1]
  • Packages available as deb, rpm, and zip [1]
  • Built on OpenSearch; can be configured to use an existing Elasticsearch cluster [2]

Pricing: SaaS vs self-hosted math

Fess itself: $0. Apache License 2.0, no commercial restrictions [1].

Infrastructure to run it:

  • A VPS with 2–4GB RAM: $6–15/mo (Hetzner, Contabo, Vultr)
  • Your time to set it up and maintain it

What you’re replacing:

Algolia: Free tier is 10,000 searches/month. Build tier runs $0.50/1K searches after that. At 100K searches/month you’re paying ~$45–50/mo just for search queries, before counting record storage. At 1M searches/month the bill is in the hundreds. Enterprise pricing is contact-sales [pricing data not publicly listed; estimate from Algolia’s public tier structure].

Swiftype (Elastic): $79–$299/mo for hosted site search. Enterprise: custom.

Google Cloud Search: Discontinued.

Coveo, Sinequa, Attivio: Enterprise pricing, six-figure annual contracts common.

Concrete math for a mid-sized internal deployment:

Say you have 50,000 internal documents (policies, wikis, project files) and 200 employees running searches. On Algolia at that volume you’d spend $50–200/mo depending on your search query volume. On Fess self-hosted on a $10/mo Hetzner VPS: $10/mo. Over three years, that’s roughly $1,800–7,200 in SaaS savings, not counting the data-sovereignty benefit of keeping sensitive internal documents off third-party infrastructure.

The commercial support tier, branded N2 Search, is available for organizations that need guaranteed SLAs, deployment help, and performance tuning — pricing is not public and requires contacting CodeLibs [2]. If you need support, budget for it. If you’re running this yourself, there’s no licensing cost at any scale.


Deployment reality check

The fast path:

git clone https://github.com/codelibs/docker-fess
cd docker-fess/compose
docker compose up -d

The search UI is available at http://localhost:8080/ and the admin UI at http://localhost:8080/admin/ with default credentials admin/admin [1]. The “5 minutes” claim holds for a local evaluation. Getting it production-ready takes longer.

What you actually need:

  • A Linux server with at least 2GB RAM (4GB recommended; OpenSearch is memory-hungry)
  • Docker and docker-compose, or a Java 17+ runtime
  • A reverse proxy (Caddy or nginx) for HTTPS if you’re exposing it
  • A domain or internal DNS entry
  • Reasonable disk space for the search index (plan for 2–5x the size of what you’re indexing)

What can go sideways:

  • Java memory tuning. OpenSearch’s JVM heap defaults are fine for evaluation but will need adjustment for production workloads. If you don’t configure ES_JAVA_OPTS, you’ll hit OOM errors under load.
  • Crawl authentication setup. Configuring NTLM for Windows shares or SAML for SSO is not a one-click operation. The documentation exists but is sparse in English. Budget extra time if your use case requires authenticated crawling.
  • Documentation language gap. The project’s primary community is Japanese-speaking. The English docs cover the basics but leave gaps for edge cases. If you get stuck, Google Translate applied to Japanese forum posts at discuss.codelibs.org is genuinely your best resource [2].
  • No managed hosting option. Unlike Algolia or Elastic Cloud, there’s no “pay and get a running instance.” You own the infrastructure entirely. That’s the point, but it means you need someone comfortable with Linux and Docker.

Realistic time estimate for a technical user: 1–3 hours to a working Docker deployment with a test crawl. For authenticated crawling of an enterprise data store (SharePoint, Confluence): 4–8 hours including troubleshooting. For a full production setup with HTTPS, SSO, and scheduled crawls: a full day.


Pros and Cons

Pros

  • Genuinely Apache 2.0 licensed. No usage restrictions, no commercial redistribution limits, no hidden enterprise tiers in the core. Use it however you need [1].
  • Broadest data store coverage in the open-source category. Confluence, SharePoint, Slack, S3, Salesforce, Office 365, Git, Dropbox — all in one tool, configured through a browser [1]. No other free-to-use search server matches this breadth out of the box.
  • Access-control-aware search. Result filtering based on login status and SSO integration with Active Directory and SAML is a serious enterprise feature that’s normally found only in paid products [2].
  • Browser-based admin UI. You don’t edit config files to add a crawl target or adjust a synonym dictionary. This matters when the person maintaining it isn’t a developer [1][2].
  • Actively maintained. Four releases in the past year (15.2 through 15.5), with 15.5.0 landing February 2026 [2].
  • Built on OpenSearch. You get the full power of OpenSearch’s query engine — relevance tuning, aggregations, facets — without having to build the crawling and ingestion layer [1].
  • REST API included. External systems can trigger index updates and consume search results via JSON [2].

Cons

  • Low English-language presence. 1,095 GitHub stars and near-zero independent English reviews means you’re flying without a community safety net if you encounter a problem the docs don’t cover [1].
  • Java memory footprint. OpenSearch underneath means you need real RAM. A $3/mo VPS is not going to cut it. Budget at least $8–15/mo for a reasonably sized instance [1].
  • Documentation is sparse. The English documentation covers installation and basic configuration. Advanced use cases — custom scoring, complex crawl filtering, NTLM authentication for Windows shares — require significant digging [1][2].
  • No hosted option. If you don’t want to manage infrastructure, there’s no first-party managed cloud tier. The commercial support offering (N2 Search) is consulting/deployment help, not SaaS [2].
  • UI is functional, not polished. The admin and search UIs work, but they’re utility-grade. Don’t expect the aesthetic polish of Algolia’s dashboard or Meilisearch’s UI.
  • Niche adoption means fewer plugins and community extensions. The data store connectors are well-maintained, but the broader plugin ecosystem is thin compared to Elasticsearch-native tooling.

Who should use this / who shouldn’t

Use Fess if:

  • You need to make internal documents searchable — SharePoint files, Confluence pages, shared drives, Slack archives — and you don’t want to pay Algolia or Elastic enterprise pricing.
  • You’re building an internal company search portal and data sovereignty matters (HR documents, contracts, internal financials should not pass through a vendor’s infrastructure).
  • You want a genuinely Apache 2.0 licensed search engine you can embed in a product or deploy for clients without a licensing conversation.
  • Someone on your team is comfortable with Java/Docker deployment and basic Linux ops.
  • You want SSO and access-control-aware search without building it yourself.

Skip it (use Meilisearch or Typesense) if:

  • You’re adding search to a public-facing website or application and need fast, developer-friendly integration with good SDKs. Fess is an enterprise search appliance, not a search-as-a-service library.
  • Your team has no one comfortable with Java or Docker. The setup overhead is real.
  • You want beautiful out-of-the-box search UI for end users. Fess’s search UI is functional but not impressive.

Skip it (use Algolia or Elastic Cloud) if:

  • You need guaranteed SLAs, 24/7 support, and managed infrastructure — and budget isn’t the constraint.
  • You’re not willing to own the infrastructure.

Skip it (use OpenSearch directly) if:

  • You have engineering resources to build a custom ingestion pipeline and search UI. OpenSearch directly gives you more control at the cost of more setup. Fess is the shortcut for teams that don’t want to build the surrounding infrastructure.

Alternatives worth considering

  • Meilisearch — developer-friendly, fast, clean UI, MIT-licensed. Best for application search (adding search to a product). No built-in crawler; you push documents to it. Much easier to deploy and integrate than Fess for web/app use cases.
  • Typesense — similar positioning to Meilisearch. Good SDKs, fast, cloud option available. Same caveat: no crawler, push-based indexing.
  • OpenSearch — what Fess is built on. Use OpenSearch directly if you want full control and are willing to build the ingestion pipeline yourself.
  • Solr — the older Java search server. More mature ecosystem than Fess, but also more configuration overhead and a steeper learning curve. Apache-licensed.
  • ManticoreSearch — MySQL-compatible, fast, good for structured data and log analytics. Different use case than Fess’s document crawling focus.
  • Zinc/ZincSearch — lightweight Elasticsearch alternative, minimal resource footprint. No built-in crawler.
  • Algolia — the obvious SaaS alternative. Excellent developer experience, great SDKs, hosted infrastructure. Expensive at scale; your data lives on their servers.

For the specific use case of “index everything inside my organization” — SharePoint, Confluence, file shares, email, Slack — Fess has no direct open-source competitor with equivalent data store coverage. The alternatives are either raw OpenSearch (build it yourself) or enterprise products that cost significantly more.


Bottom line

Fess is a serious tool that most Western developers have never heard of, primarily because it comes from the Japanese open-source ecosystem and has modest English-language marketing. If your problem is “I need enterprise search across a mix of file shares, SharePoint, Confluence, and web content, with access control, and I don’t want to pay five figures a year for it” — Fess is the most complete self-hosted answer available. The Apache 2.0 license is clean, the crawler coverage is genuinely broad, and the project is actively maintained.

The honest caveats: the documentation is thin in English, the Java memory footprint is real, and with 1,095 GitHub stars you’re not buying into a large community. You’re betting on a well-maintained tool with a smaller, primarily Japanese-speaking support network. For teams with the technical capacity to handle that, the trade-off is favorable. For teams that need hand-holding or managed infrastructure, look at Algolia or wait for a hosted Meilisearch tier to cover more of the enterprise feature set.


Sources

  1. GitHub — codelibs/fess — README, feature list, data store connectors, license, release history. https://github.com/codelibs/fess
  2. Fess Official Website — Feature overview, deployment options, commercial support tiers, release news. https://fess.codelibs.org/

Features

Integrations & APIs

  • REST API