BookLogr: a self-hosted shelf that leans on OpenLibrary for metadata
A simple, self-hosted service to keep track of your personal library 📚
At a glance
- What is it?
- BookLogr is a small self-hosted web app for tracking the books you own, read, or intend to read, with SQLite or PostgreSQL underneath and an optional public profile. Its main dependency is also its main constraint: most metadata comes from OpenLibrary lookups.
- Who is it for?
- Adopt BookLogr if you want a private catalogue you control, you are comfortable with a project that states it is under active development and that you should expect bugs and breaking changes, and your books are mostly findable through OpenLibrary. Do not adopt it if your collection is dominated by editions OpenLibrary does not carry, or if you need a stable data model you will not have to migrate.
- Can I use it commercially?
- Yes. Apache-2.0 is a permissive licence: you can use, modify and sell software built on it, as long as you keep its copyright and licence notices.
- Is it still maintained?
- Yes. The repository last received commits 3 days ago.
- What is it written in?
- Mainly JavaScript, according to GitHub's language statistics.
Answers come from the project's GitHub data, last synced on September 15, 2026, and from our analysis. They are not legal advice.
DEEP OPEN-SOURCE ANALYSIS
The problem BookLogr addresses, and who it is actually for
Most people who own a few hundred books end up with a spreadsheet, or with a commercial service that treats their shelf as inventory for a recommendation engine. BookLogr sits between those. The README describes it as "a simple, self-hosted service to keep track of your personal library", and the framing sentence on the project page is about control: the service "ensures that you have complete control over your data". That is the pitch, and it is a narrow one. The intended user runs their own hardware, wants the catalogue to live on that hardware, and does not need social features beyond an optional public view of the shelf. The feature list is deliberately domestic: reading states (Reading, Already Read, To Be Read, Did not finish), a current page number, half-star ratings from 0.5 to 5, short notes and saved quotes. Nothing here is aimed at libraries, book clubs, or anyone who needs lending records or multi-user permissions. The repository topics include both flask and react, and the primary language is listed as JavaScript, so expect a split frontend and backend rather than a single-server-rendered application.
How the pieces fit: a lookup service, a database, and a public view
The mechanism that matters most is the metadata lookup. According to the README, books are found "by title or isbn" and the lookup is "Powered by OpenLibrary". So the flow is: you enter a title or an ISBN, BookLogr queries OpenLibrary, and you pick from what comes back. That record becomes the spine of the entry, and everything else (list assignment, page progress, rating, notes, quotes) hangs off it. The README also states you can "Manually add books that are not found in the OpenLibrary", which is the escape hatch for anything the lookup misses. Storage is either SQLite (described as the default) or PostgreSQL, so the deployment shape ranges from a single file on disk to a separate database server. Two features change the data flow outward rather than inward. The first is the public profile: the README says you can "Share a public profile of your library with others", and the project description adds that this display is optional. The second is Mastodon integration, which "Automatically share[s] your reading progress". Both mean the app can emit data to parties other than you, which is worth noting in a project whose selling point is privacy. Export exists in CSV, JSON, and HTML, which is the practical counterweight: whatever the app does with your data, you can get it out in a readable form.
Getting it running: where the real instructions live
The README does not contain the install commands. It says BookLogr "is made to be self-hosted and run on your own hardware" and then points to the Getting Started guide at booklogr.app/docs/Getting%20started for "step-by-step instructions". That is the honest state of the repository: the install path is documented on the project site, not in the README, so I cannot reproduce the exact docker or pip commands here without inventing them. What the README does commit to is the database choice. SQLite is the default, PostgreSQL is supported, and the switch is a configuration decision you make before first run because it determines where your catalogue lives. There is a demo instance at demo.booklogr.app and a status page at status.booklogr.app if you want to see the interface before installing anything. Development instructions are on the GitHub wiki rather than in the README, and translations are handled through Crowdin, with an in-context translation interface at translate-live.booklogr.app for people who want to work on strings inside the running UI. If you are evaluating rather than deploying, the demo plus the Getting Started page will tell you more in ten minutes than the README will.
The OpenLibrary dependency is the design, and the risk
BookLogr outsources its bibliographic data. That keeps the codebase small and means you are not maintaining a book database, but it also means the quality of your catalogue is bounded by what OpenLibrary has indexed, particularly for the ISBN you happen to own. Editions, printings, and translated titles are where lookup services tend to diverge from the physical object on your shelf, and the README's answer to that is manual entry, not a fallback metadata source. Manual entry is a reasonable escape hatch for a handful of books and a poor one for a shelf of several hundred. There is a second-order cost too: a lookup-based workflow assumes network access at the moment you add a book. Nothing in the supplied material describes an offline or bulk-import path from an existing catalogue, so if you already have a spreadsheet of a thousand titles, the README does not tell you how to bring it in. Export is documented; import is not. That asymmetry is worth checking in the Getting Started guide before you commit to migrating.
Active development is stated plainly, and it has consequences
The README carries a callout that says the project is under "active development" and that you should "Expect bugs and breaking changes". That is unusually direct, and it should shape how you deploy. The release history supports the warning: v1.11.0 and v1.11.1 landed two days apart in June 2026, and v1.12.0 followed in September 2026. A patch release two days after a minor release usually means something needed fixing quickly. For a personal shelf this is manageable. For anything you would call an archive, it means pinning a version and reading release notes before upgrading, because a breaking change to the schema is a breaking change to the database file you have been curating. The project also asks for sponsorship to cover monthly hosting costs, which is a normal model for a self-hosted app with a documentation site, a demo, and a status page, but it is worth understanding that the public infrastructure (docs, demo, translation tooling) depends on that funding rather than on the code you run locally.
Licence, and what Apache-2.0 does and does not settle
BookLogr is licensed under the Apache License, Version 2.0, and the README points to the LICENSE file for the full text. Apache-2.0 is a permissive licence with an explicit patent grant, which matters if you plan to run a modified copy in a context where that grant is relevant. It does not obligate the maintainer to keep the hosted documentation, demo, or translation service online, and it does not give you any claim on the OpenLibrary data your catalogue is built from, which is a separate service with its own terms. If you fork and redistribute, the licence terms travel with the code. This is a description of the licence identifier and its general shape, not legal advice; read the LICENSE file and, if the distinction matters to you, talk to someone qualified.
What BookLogr is not, and what to use instead
BookLogr is a personal shelf tracker, not a library management system. If you need circulation, patrons, holds, or MARC records, this is the wrong tool and the feature list makes that obvious: there is no lending, no user roles, and no acquisitions workflow. The closer alternative is Calibre, which takes the opposite approach on the central question. Calibre is a desktop application that owns your ebook files and maintains its own local metadata database, with an optional content server for access over the network. BookLogr owns no files. It stores records about physical or digital books and pulls bibliographic detail from a remote service on demand. That difference decides the choice: if your library is a folder of ebook files you want to read and convert, Calibre is built for that and BookLogr is not. If your library is a shelf of paper books and you want a web page you can open from a phone to check whether you already own something, BookLogr's lookup-and-record model fits better, and the absence of file management is a feature rather than a gap. A third path, a plain spreadsheet, remains competitive for small collections and has no upgrade cost at all.
Who should adopt it, and what to verify first
BookLogr fits a self-hoster with a personal collection, a machine to run it on, and a tolerance for a project that says outright it will break things. The SQLite default keeps the deployment to a single file, which is the lowest-friction option if you are trying it rather than committing to it. The public profile and Mastodon sharing are the two features that make this more than a private database, and they are also the two that deserve a deliberate decision rather than a default. If your collection skews toward editions OpenLibrary does not carry, or you need to import an existing catalogue in bulk, the README does not describe how that works, and that gap should be resolved before you start typing titles in by hand. Check the Getting Started guide for the actual install commands, confirm which database you are configuring, and read the release notes for the version you pin, because the project's own warning about breaking changes is the most useful sentence in the repository.
Editorial conclusion
Adopt BookLogr if you want a private catalogue you control, you are comfortable with a project that states it is under active development and that you should expect bugs and breaking changes, and your books are mostly findable through OpenLibrary. Do not adopt it if your collection is dominated by editions OpenLibrary does not carry, or if you need a stable data model you will not have to migrate. Before committing, verify three things: whether your database is SQLite or PostgreSQL and how you will back it up, whether the public profile feature is enabled by default or opt-in, and what the current release notes say about breaking changes since the version you plan to pin.
Community notes