Kintara is a self-hosted document library and reader that runs in Docker and watches a folder you already have. Drop PDFs, Markdown, or text files into the directory and it indexes them automatically, extracts searchable text and metadata, generates thumbnails, and makes the whole library available through a browser or installable PWA. It has libraries, collections, tags, full-text search, highlights, favorites, reading progress, private library sharing, and GitHub OAuth.
I have been working on Kintara for a few months, and the architecture actually changed pretty dramatically while I was building it. Kintara originally had a Tauri desktop shell, but I eventually realized that isn't what I wanted at all. So I ripped the desktop layer out and rebuilt it around one Rust server that serves both the API and frontend. Now I can point Kintara at a NAS folder and open the same library from my desktop, laptop, tablet, or phone.
The thing I really love about this app is the optional AI features. I added an option to use OpenAI or Gemini, and with so few tokens being spent, it's a fraction of a cent to use most of them, aside from the cover image generation, which is bit more, but makes the library look so much prettier! 😄
Anyway, I wanted AI to be a tool inside the library rather than taking the thing over, and I wanted it to be fully optional, so if you're one of those "Ew, AI is in this app" people, you just don't turn it on and it's like it doesn't exist. What the AI can do is summarize documents, suggest metadata and fill in those blank spaces, generate cover images for docs that don't have a cover, search the library for docs, or you can just chat with it about your docs.
Find is a pretty great AI feature I think. Instead of letting the model vaguely tell you that something appears "somewhere in the document," Kintara asks for actual passages with page numbers, verifies the quote against extracted page text on the server, then verifies it again against the rendered PDF. If the quote cannot actually be located, it gets dropped.
But I think the thing I’ve ended up appreciating most is the AI metadata suggestions. A lot of my library consists of documents with incomplete, inconsistent, or completely useless embedded metadata, and fixing that manually gets old super fast. Kintara can read the document and suggest a title, author, summary, keywords, DOI, ISBN, and publication year. Then it displays the suggestions and I choose which fields I want, apply them to the form. It sounds like a stupidly small convenience until you’re staring at a library with hundreds of files. Then it’s kinda just amazing.
At this point Kintara has grown into one of those projects where I started out thinking, "I just want a nice way to organize my documents that's not overcomplicated", and somehow I ended up with filesystem watching, OAuth, multi-user permissions, and threw in image generation cause why not?
So if you have accumulated an actual ton of pdfs and markdown files, and it sounds interesting to you, try it out and let me know what ya think! It's open source I've published a Docker image too.
GitHub: https://github.com/pinkpixel-dev/kintara
Docker Hub: https://hub.docker.com/r/pinkpixeldev/kintara
Top comments (12)
I've been working my own thumbnail project trying to be excellent for self hosted nas situations. This week I added pdf support, so I'm always interested in seeing how others tackle this. I ended up with a similar
pdftoppmpath with Poppler to keep my own Rust project Apache 2.Your work on the end-to-end usage is inspiring me to continue my own. 🆒
That’s awesome, and funny that we ended up on such a similar path with Poppler too. pdftoppm has worked really well for Kintara, and keeping the licensing straightforward was a big part of that decision for me too.
Self-hosted/NAS projects have such a weirdly specific set of problems once you get past the basic functionality, so I always enjoy seeing how other people approach them. Definitely keep going with yours, especially if you’re already adding PDF support. I’d love to see where you take it! 🙂
I haven't been sharing the link much yet. In some ways it feels like it will never be "ready", but realistically it probably is more than ready for some. I'm hoping to post more soon.
thumbrella.dev/
Nice! This is awesome. I can definitely see the overlap now, especially around PDF handling, native dependencies, and the self-hosted side of things.
I really like the tiered architecture too. Supporting that many formats without turning the whole server into one giant dependency pile seems like a smart way to handle it.
Kintara only needs thumbnail generation as one piece of the app, so it’s interesting seeing someone tackle that same problem as the actual product. Thanks for sharing it, I’m definitely going to check out the repo some more.
The NAS-first pivot is the right call. Desktop shells are nice until you want the same reading state on a tablet and a laptop. I like that the AI part sits on top of the library instead of owning it.
It's so cool! 😸⭐
Thanks so much!!
The part about verifying AI-generated passages against both extracted text and the rendered PDF is what caught my attention.
I like the architectural choice of treating the model as a source of suggestions rather than the source of truth. The same principle seems to make the metadata features much safer too: AI proposes, the user decides, and the application remains responsible for what actually gets persisted.
It makes me wonder how far this pattern could go. Could the same “suggest → independently verify → apply” pipeline become a general interface for AI features in document systems, rather than having each AI feature implement its own trust model?
That separation feels much more scalable than trying to make the model itself perfectly reliable.
That is pretty much exactly how I have been thinking about it. I like keeping the AI as a source of suggestions and letting the application remain the authority on what is actually valid and what gets persisted.
The passage verification is probably the clearest example. The model can suggest a quote and page, but Kintara does not trust that just because it came back in structured output. It verifies it against the extracted page text, and then the reader verifies it again against what pdf.js actually rendered before it can become a highlight.
I think that suggest → verify → apply pattern could definitely work as a more general framework for AI features. It keeps the model useful without making the rest of the application dependent on the model being perfectly reliable, which I have been trying to preserve throughout Kintara.
really neat project ill go drop a star ^_-
really neat github profile your nectar mcp his interesting and solid i did not try it but the way it build his solide nice job
Thank you! Really appreciate it!
There is a nice operator angle here: the best implementation is often the one that makes a bad state obvious early. A clear signal, an owner, and a reversible response path beat a more sophisticated design that fails silently.