all-docs: a searchable document store with online preview

The problem: many documents, no way to search inside them

The stated problem is a small team with a large number of collaborative documents. The description puts files in cloud storage, SVN and other software, and then names the specific failure: the inability to quickly search for content within the documents.

That is a sharper problem than it first appears. Cloud storage can search file names, and SVN can search text in files it stores as text, but a Word document or a PowerPoint deck stored as a binary is a blob as far as both are concerned. A team that keeps its specifications, slide decks and spreadsheets in those systems ends up with a directory listing and a culture of asking a colleague where the file is.

The answer here is a dedicated knowledge base for storing documents such as PPT, Word and PNG files, which supports private deployment and retrieval. The Chinese description says the same thing more compactly: online preview, storage and sharing for documents, with full-text search over all document information.

The audience is therefore internal, not public. This is a self-hosted team knowledge base, and the fact that private deployment and retrieval are called out as features tells you the intended deployment is inside a company network rather than as a public file-sharing service.

MongoDB for files, Elasticsearch for the text

The architecture is stated in a few lines. MongoDB is chosen as the primary database to store documents and files. The backend is SpringBoot with MongoDB and ES, and the frontend is Vue with axios.

The split of responsibilities is what matters here. MongoDB holds the binary files and their metadata, which is a straightforward document store operation and avoids a separate object storage tier. Elasticsearch holds the extracted text so that a query can run across the contents of every file rather than across file names.

That means the pipeline has an extraction stage, and the repository layout shows evidence of it. There is an ocr.png at the top level next to the Dockerfile and the pom.xml, which points at image OCR as part of the indexing path, and a docs directory that presumably covers the formats handled. The topic list on the repository adds the confirmation: document, document-preview, elasticsearch, mongodb, spring-boot.

The consequence of this design is that two systems have to be correct, not one. If the extraction step fails for a file format, the document is stored and previewed but not searchable, and a user experiences that as a search that silently misses files. There is no indication in the documentation of how such partial failures are surfaced, so on a trial deployment it is worth searching for a term you know is inside a specific document of each type and checking that it comes back.

The quick start script and the broken deployment path

The Quick Start section is a shell script sequence, and it carries an important warning above it. The deployment method is described as temporarily invalid because of Docker Hub image pull issues, and the section is also marked as tested on Ubuntu 18.04 with a note to wait for CentOS support.

The sequence itself is:

# clone project
git clone https://github.com/Jarrettluo/all-docs.git

# switch user to root
su root

# switch work directory
cd document-sharing-site && cd docker

# chmod
chmod +x auto.sh

# start shell script
sudo ./auto.sh

There is an inconsistency in those instructions that a reader will hit immediately. The clone command names the all-docs repository, and then the working directory step changes into a directory called document-sharing-site. That is not a typo in the repository naming, since the README also links the frontend project as all-documents-vue and the backend project as document-sharing-site, but it does mean the quick start was written for the backend repository rather than the frontend one this page belongs to.

The separate deployment documents are the more reliable route. The README links four of them: deploy on Windows, deploy on Linux, deploy by Docker, and deploy by Docker Compose. Those are the documents to follow, and the fact that they exist per platform is a good sign for a private deployment, where a script that assumes a particular Linux distribution and root access is a liability.

What the Dockerfile tells you about the runtime

The Dockerfile in the repository root is short and it answers the deployment questions that the README leaves open. The base image is openjdk:8-jre-alpine, so the application is a Java 8 jar running on a JRE, with no JDK in the image. The jar is added from the build output at target/document-sharing-site-1.0-SNAPSHOT.jar and placed at /app.jar, with the entrypoint running java -jar /app.jar.

The service listens on port 8082, which is exposed in the image. That port is the one to point a reverse proxy at, and it is also the port to check when the container starts and nothing answers.

The most interesting line is the font installation. The image adds ttf-dejavu and fontconfig through apk, with a comment noting that the process is slow and pointing to a reference about the Alpine font issue, and sets LANG to en_US.UTF-8. Installing fonts in a document preview service is not decoration. Rendering a document to an image or a page in the browser needs real font metrics, and a container without fonts renders boxes or falls back to a default that reflows the layout, which then breaks any visual comparison or thumbnail you were counting on.

The MAINTAINER line points at the same contact address listed in the README. The image is Alpine based, so it is small, and the build is done outside the image from a Maven project given by the pom.xml, with a build_images.sh script at the repository root for producing the images.

Preview, search and the roadmap of what is missing

The preview section of the README is a set of screenshots with captions: the homepage, the list of documents, the search page, the upload page and a user's information page. That set of screens describes the whole product surface. Upload a file, browse a list, search across the corpus, and manage a user.

The roadmap lists what is planned, and it is worth reading as a description of the current limits. Record the last page number read by the user. Revamp the search page style. Allow users to bookmark documents. Support video files. Support permission management. Support a file tree. Support Mobi files.

Permission management is the one that decides whether this is usable for a real team. A shared knowledge base where every authenticated user sees every document is fine for a small group that already trusts each other completely, and it is not fine the moment one document should not be visible to one person. There is no role model described in the documentation, so the current state is a single shared space with accounts.

The remaining items are quality-of-life improvements rather than blockers. A file tree matters once a corpus passes a few hundred documents, bookmarks matter for a document everyone needs, and video support expands the scope of the preview service considerably.

The contributing section is standard fork, branch, commit, push, pull request, and it invites WeChat contact for customisation or private deployment requirements, which tells you the project is maintained by one person who does bespoke deployments for organisations that need them.

Where all-docs is the wrong tool

The first case is a team that needs real access control. Permission management is on the roadmap, so today the deployment gives you a document store where every user sees everything. If your documents include anything with a different audience, that is a blocker, not a gap.

The second case is a team that already has a good answer. If the documents are in Google Workspace, Microsoft 365 or a modern enterprise search product, those systems already index the contents of Office files, offer per-file permissions, and have no operation burden beyond the one you already carry. All Docs wins on self-hosting and on a purpose-built preview, and loses on everything else.

The third case is a deployment that cannot accept the operational surface. Two datastores plus an application means three things to back up, monitor and version, and the Elasticsearch index in particular has to be rebuilt or kept in step with MongoDB, since a document stored but not indexed is a document that exists and cannot be found.

The alternative worth comparing is a plain object store with a search index in front, for example a shared drive backed by a proper search service, where the preview is handled by the office suite itself through a link. The difference in approach is that All Docs does the extraction, the indexing and the rendering in one application you control, and you accept running the databases to keep that true. A file store plus an external search tool keeps each piece replaceable, at the cost of a more complicated user experience for people who just want to find a slide from last quarter.

Editorial conclusion

all-docs is worth evaluating for a small team whose shared documents are scattered across cloud storage and version control, because it puts full-text search over office file contents in one place with a browser preview. It is not the right fit for a team that needs permissions beyond a shared login, since permission management is still on the roadmap, nor for anyone unwilling to run MongoDB and Elasticsearch alongside the application. Before you deploy it, read the deployment documents in the deploy folder rather than the quick start script, because the README states that the shell-script deployment is temporarily broken by Docker Hub image pull failures, and change the default administrator credentials before exposing the instance to anyone.

Frequently asked questions

Official sources

1. Issues
2. Jarrettluo/all-docs on GitHub
3. License: MIT
4. Project website
5. README