Koillection: a self-hosted catalog for collections that no existing metadata source describes
Koillection is a self-hosted service allowing users to manage any kind of collections.
At a glance
- What is it?
- Koillection is a PHP and Symfony collection manager that ships without any built-in metadata lookup, on the premise that you will model the fields yourself or write a scraper. It is a good fit for odd collections and a poor fit for anyone who wants a media server to identify items automatically.
- Who is it for?
- Adopt Koillection if your collection has no public metadata source, if you are willing to define fields and write an HTML scraper, and if you can run PHP with MySQL 8.0 or later, MariaDB 10.0 or later, or PostgreSQL 10.0 or later. Do not adopt it if you expect a tool to identify a barcode or a title and fill in the record for you: the README states plainly that no pre-built metadata download exists.
- Can I use it commercially?
- Yes. MIT 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 7 days ago.
- What is it written in?
- Mainly PHP, 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 collections Koillection was built for
Most cataloguing software assumes your items already exist in somebody else's database. A DVD has a barcode and a matching entry. A book has an ISBN. Koillection starts from the opposite assumption. Its README describes it as a self-hosted collection manager "created to keep track of physical (mostly) collections of any kind like books, DVDs, stamps, games" and then states the constraint that defines the project: it "doesn't come with pre-built metadata download".
That single sentence decides the audience. If you collect stamps, postcards, mineral specimens, board game miniatures, or local pressings that no aggregator indexes, the absence of a metadata provider is not a gap. It is the reason the tool can represent your items at all. You decide which fields exist, and the software stores what you enter. The README frames the alternative directly: you "can tailor your own HTML scraper, or you can add your own metadata freely". Two paths, one manual and one scripted, and neither of them involves a shipped provider list.
The secondary audience is the person who already has a spreadsheet. Koillection is a web application with a database behind it, which means sorting, filtering and browsing happen in a browser instead of in rows of cells. What it is not is a discovery tool. Nothing in the material suggests Koillection will find an item for you.
What the stack tells you about the mechanism
The repository topics name the components: symfony, api-platform, php, mysql, postgresql. The README badges give version floors: PostgreSQL 10.0 or later, MariaDB 10.0 or later, MySQL 8.0 or later, plus a Packagist PHP version badge. So the shape is a Symfony application over a relational database, with an HTTP API exposed through API Platform.
The API is the part worth pausing on. Because API Platform generates endpoints from the application's own resource definitions, the API surface follows the data model you build rather than a fixed schema imposed by the project. That is consistent with a tool where the user defines the fields. It also means the API is a first-class way to get data in and out, which matters for anyone migrating from a spreadsheet or from another cataloguer.
Scraping sits alongside the API as a separate concern. The README points to a dedicated Scraping page in the wiki, which implies scrapers are configured rather than coded into the application core. The README does not specify the scraper format, the selector syntax, or whether scrapers are per-collection or global. I cannot confirm those details from the supplied material, and anyone planning to rely on scraping should read the wiki page before assuming a particular workflow.
Installation, updating, and the backup instruction that is not boilerplate
The README contains no installation commands. It says only: "See the Installation page in the wiki", and the same for updating and scraping. The wiki is described in the README as "under construction", which is worth weighing if you are evaluating how quickly you can get a working instance. The concrete commands live outside the material available here, so I will not invent a docker run line or a composer invocation.
What the README does state, in a section titled Warning, is a backup instruction with unusual specificity: "Please back up your database, especially when updating to a new version. I do my best to test new versions, especially when they contains data migrations but some edge cases may escape my vigilance." The author repeats it as a standalone line: "Please do back up your database." Repetition like that is a signal. Version 1.8.4 shipped on 2026-08-23, roughly three weeks after 1.8.3 on 2026-06-25, and 1.8.2 before that on 2026-06-15. Three patch releases inside a minor line within about two months means the upgrade path is exercised often, and each of those steps is a point where a migration could meet data the author did not anticipate.
A practical consequence: treat the database dump as part of the upgrade procedure, not as a separate habit. If you cannot restore a dump, you cannot safely take a patch release.
Where Koillection is the wrong tool
The clearest failure case is the one the README advertises. If your collection consists of commercially released films, music, or mainstream books, the items are already described in public databases, and the work of entering them by hand is pure duplication. Koillection will hold that data happily. It will not fetch it. A tool that resolves a title or a barcode to a populated record removes hours of typing that Koillection leaves in place.
The second failure case is the scraper that quietly stops working. A custom HTML scraper depends on the markup of whatever site it targets. When that site is redesigned, the scraper returns nothing or returns the wrong fields, and because the scraper is yours, there is no upstream maintainer to fix it. The README presents scraping as an option without describing a fallback or a validation step. Budget for the possibility that a scraper needs repair after a target site changes.
The third is operational. This is a PHP application with a relational database behind it, not a single static binary. You are running a web service and a database, and you are responsible for both. The README's own warning about migrations is the honest version of that responsibility: the author tests releases but cannot cover every data shape in the wild.
How this differs from a media server
The obvious comparison is a media server such as Jellyfin or Plex. The difference is not a feature checklist. It is where the item description comes from. A media server is built around agents and providers: you point it at files or discs, it queries a metadata service, and the record is populated for you. The system's value is partly in that lookup.
Koillection inverts the direction. Its README says it "doesn't come with pre-built metadata download", so the description originates with you, either typed or scraped from a page you chose. That inversion is why Koillection can represent a stamp or a mineral specimen and a media server cannot: there is no provider to query for those things, so a provider-driven design has nothing to offer. It is also why Koillection is worse than a media server for a DVD shelf. For films and albums, the provider-driven approach does the work; for everything else, there is no provider to drive.
A second, quieter difference is the data model. A media server ships a fixed schema for movies, episodes, tracks and artists. Koillection's schema is something you assemble, which is what makes the API Platform layer meaningful: the endpoints describe your model, not the vendor's.
Licence, translations, and what maintenance actually costs
Koillection is MIT licensed, per the repository metadata and the licence badge in the README. MIT is permissive: it allows use, modification and redistribution with the licence and copyright notice retained. That is a statement about the licence text, not legal advice, and it does not cover the terms of any site you scrape or any metadata you enter from elsewhere. Those are separate questions with separate answers.
The project is not archived and the default branch is 1.8, which matches the 1.8.x release line. Release cadence in the material shows patch releases arriving weeks apart, so the maintenance cost of following the line is a periodic upgrade plus a database backup. The README also documents an active translation effort through Crowdin, with Chinese Simplified, Dutch, English, French and Spanish listed at 100% and German, Italian, Polish and both Portuguese variants at 99%. If your users work in a language outside that set, the README invites you to open a discussion on GitHub or Crowdin to have a new language added, which is a request rather than a self-service step.
The cost that does not appear in any release note is the scraper. It is your code, it depends on someone else's HTML, and it has no maintenance schedule except the one you impose. That is the real ongoing expense of running Koillection with automated metadata rather than typing it in.
Editorial conclusion
Adopt Koillection if your collection has no public metadata source, if you are willing to define fields and write an HTML scraper, and if you can run PHP with MySQL 8.0 or later, MariaDB 10.0 or later, or PostgreSQL 10.0 or later. Do not adopt it if you expect a tool to identify a barcode or a title and fill in the record for you: the README states plainly that no pre-built metadata download exists. Before committing data, verify three things: that your database is backed up, because the README asks for a backup especially when updating to a version containing data migrations; that the wiki's Installation page covers your deployment shape, since the README delegates installation and updating there entirely; and that your own scraper still returns parseable HTML, because when a target site changes its markup there is nothing in Koillection to fall back on.
Community notes