Everything worth asking before you trust us with a collection.

KolleK is an open source application for cataloguing collections. You record what you own, item by item and physical copy by physical copy, with photos, documents, values, and history, and you either run it on your own server or use an instance somebody else runs. It is released under the MIT licence.

Private collectors who have outgrown a spreadsheet, first. Households, clubs and small organisations work too, because an account can hold several people with different roles. It is not institutional collection management software, and it does not try to be.

Any kind. A new account starts with twelve ready made collection types (comics, trading cards, vinyl records, CDs, DVDs, coins, stamps, books, action figures, video games, watches and wine), and you can edit any of them or write your own from scratch.

Yes, and nothing in the code limits how many. Each collection has its own name, emoji, description, currency, and its own categories and sets.

An item is the thing in the abstract: a title, a model, an edition. A copy is one physical object you actually own of that item, with its own condition, location, price paid, and history. Three of the same comic is one item with three copies. It is the single most important idea in KolleK.

Yes. An item can be a name and a photo, or a record with custom fields, several copies, valuations, insurance, loans, maintenance, provenance and attached documents. The fields you never define never appear.

Yes, in seven: English, French, Spanish, German, Brazilian Portuguese, Simplified Chinese and Japanese. Each person picks their own language, and the documentation and this public site are translated as well.

No. There is no native app for iOS or Android, and none is in the codebase today. KolleK is a web application you open in a browser.

Yes. Every screen is laid out down to phone width, and adding photos uses your device's normal file picker, which on a phone includes the camera.

Yes, under the MIT licence, with the full application source public on GitHub. That licence cannot be revoked for the code that is already published.

Yes, and it is the main supported way to run it. A Docker Compose stack starts the web server, a queue worker, a scheduler and the database, and nothing is held back from the self-hosted version.

The software is the same, and so is the feature set: nothing is locked behind a plan, and no feature is held back from the self-hosted version. What differs is who runs the server, applies the updates and keeps the backups, and that a hosted account holds ten items for free before it has to be unlocked. A self-hosted instance has no such limit.

Self-host, if you are comfortable running a small Docker stack and taking responsibility for its backups. It is free, and your data never leaves your machine. If you would rather not run anything, use a hosted instance.

Yes. You keep ownership of everything you add, and the terms of use say so. On the hosted service we store and process it to run the service, nothing else, and we do not train anything on it.

Partly, and this is the honest gap in the product today. You can export a collection type definition as JSON and the list of open loans as CSV. There is no item level or whole collection export yet. If you self-host, the complete answer is a backup of the database and the storage volume, which holds everything.

Not through the app yet, because item export does not exist. Until it does, moving means asking the operator of your hosted instance for a database and file dump and restoring it into your own installation.

Same answer in the other direction: there is no import path for items yet. Two instances can be merged only at the database level, by whoever operates them.

A self-hosted instance keeps running exactly as it is. It calls home to nothing, needs no licence check, and the MIT licence means nobody can take the code away. On a hosted instance, you can delete your account and everything in it whenever you like.

On Laravel Cloud, with the database on Turso and Cloudflare in front for DNS, caching and protection. Depending on those providers, your information may be processed in a country other than your own, and we do not currently offer a choice of region.

Laravel Cloud for the application, Turso for the database, and Cloudflare for DNS, routing, TLS and abuse protection. They process data on our behalf as infrastructure providers, and the privacy policy lists them by name.

Self-hosting is free, and costs you whatever your own server costs. On the hosted service an account holds ten items for free, and unlocking it for good is a single payment of $49. Checkout is not open yet, so nothing can be bought today, but the screens that explain the limit are already in the application.

No, and there is no mechanism for one. Nothing in KolleK can charge a card on a schedule. The commitment is one payment that unlocks an account permanently, never a rental.

It removes the item limit on a hosted account, and pays for the operational side of running one: the servers, the updates, the backups and the support. It does not unlock features, because every feature is already in the application however you run it.

Yes. There is no trial, no reduced tier, and no licence key to buy. The MIT licence on the published code cannot be withdrawn later.

A self-hosted instance has no quotas at all. On the hosted service the only quota is on items: an account holds ten for free, accepts five more as a grace, and then stops accepting new ones until it is unlocked. Nothing already added is ever deleted, hidden or made read-only. Collections, members, photos and documents are not counted either way. The remaining limits are per file (10 MB for a photo, 12 MB for a document) and whatever disk you give the instance.

No, and we say so before you pay rather than in the small print. A reversal costs a project this size the payment fee, the chargeback penalty and an afternoon of paperwork. If anything goes wrong, email us and we will fix it. If you would rather not pay at all, self-hosting is free and always will be.

It may, for future purchases. The terms of use say a completed one-time purchase is not repriced retroactively and does not turn into a subscription.

No. Self-hosting involves no account with us, no sign-up and no payment step. You clone the repository, or pull the image, and run it.

When hosted plans are sold, VAT and sales tax depend on where you are and are shown at checkout before you pay, as the terms of use describe.

There is no per-seat charge and no separate tier, so a household and a thirty person organisation would pay the same. If you need an invoice or procurement paperwork, get in touch.

Nothing you record is visible outside your account: there is no public link and no discovery of any kind. Inside an account, be aware that every member can currently browse every collection in it. The per-collection visibility setting is saved but not enforced yet.

No. The privacy policy states it plainly, and there is no advertising model here that would need it.

No. There are no advertising trackers, no third-party analytics and no pixels in the application. Operational logs (requests, errors, security events) are kept to run and debug the service.

Yes. Names, descriptions, identifiers and notes are encrypted by the application with your instance's key before they reach the database, and traffic is over TLS. It is not end-to-end encryption: whoever runs the instance holds the key and can read the data.

If you self-host, you do. The key is the APP_KEY in your own environment file, and nobody else ever sees it. On the hosted service, we hold the application key and infrastructure providers do not receive it.

They operate the systems that store and carry it, as infrastructure providers acting on our behalf. They are not given the application encryption key, and they get no right to use your collection for anything of their own.

For DNS, TLS termination, caching and protection against denial of service and other abuse. It keeps a small project fast and reachable without a team of infrastructure engineers behind it.

Two-factor authentication with recovery codes, passwordless magic link sign-in, passwords checked against known breaches, alert emails for sensitive events (a new device, a new IP address, failed sign-ins, an API key created or revoked), role based permissions on every write, revocable API keys, and an audit trail of who changed what. There is no single sign-on, no hardware key support, and no screen for managing active sessions.

Yes, with any standard authenticator app, and a set of one-time recovery codes issued when you turn it on.

The sensitive fields are encrypted by the application before they are written, so they are still encrypted inside any database dump, including yours. Beyond that, hosted backups are kept for operational recovery only, and self-hosted backups are protected by whatever you protect them with.

Report it privately by email to the maintainer rather than in a public issue, and it gets looked at before anything else. There is no bug bounty, and no formal disclosure timetable to promise you.

Yes. You can delete your own user from your profile, and an owner can delete the whole account with everything in it. There is also an option to have your user deleted automatically after a long stretch of inactivity. Deletion works its way out of backups on their normal rotation.

Collections, items and the copies you own, photos, documents, categories, tags, locations, conditions, sets and series, and, on each copy, transactions, valuations, insurance records, loans, maintenance records, provenance events and location history.

Yes, several per item, in any order, with one marked as the main one. Each upload is resized into smaller variants for browsing, and a photo can be up to 10 MB. The account also has a photo library that shows every image in one place.

Yes. A document attaches to a copy or to one of its records (a transaction, a valuation, an insurance record, a loan, a maintenance record, a provenance event). PDFs, images, Word and Excel files, CSV and plain text are accepted up to 12 MB, and you can also record a document that lives at an external URL.

Yes. Valuations are a history rather than one number, each with a type and a confidence level, so you can see how a copy moved over time. Purchases and sales are transactions, insurance is its own record with policy details, and the paperwork attaches to any of them.

Not yet. Exporting is limited to collection type definitions as JSON and open loans as CSV. Item and whole collection export is a known gap, tracked on the feature status page in the documentation.

Only a collection type definition, from the JSON that the export produces. There is no spreadsheet or CSV import for items, so today a collection is entered by hand or through the API.

The hosted service keeps backups for operational recovery. They exist so the service can be restored, not as a self-service undo, and they are not a substitute for your own records.

Yes, with no add-on to buy. They are operational backups of the whole instance rather than per-account snapshots you can browse.

You are, entirely. Everything lives in two places: the database volume and the storage volume that holds photos and documents. Back both up with whatever tooling you already trust, and keep a copy of your APP_KEY, because the encrypted data is unreadable without it.

Collections, items, copies, categories and sets go to the trash and can be restored for 30 days by default, after which a daily job removes them for good. Photos, documents and history records are deleted immediately and cannot be recovered from inside the app.

Yes. Emptying the trash removes what is in it straight away, and deleting the account removes everything belonging to it.

Yes. A type describes what a kind of collection holds, and every collection using it inherits those fields. Edit the ones that ship with a new account, or build your own, and export the definition as JSON to reuse it elsewhere.

Yes, in six kinds: text, number, date, yes/no, a select list of your own options, and a rating out of five. Fields sit in named groups so a long form stays readable, and both fields and groups can be reordered.

All five, and they are independent. Categories nest inside a collection, locations nest as deep as you like (a shelf in a box in a room), tags are shared across the whole account, a set tracks completion against a target count, and a series groups items that belong together.

Yes, and that is the point of separating items from copies. Each copy carries its own identifier, condition, location, acquisition date, price paid and history.

Yes, in both directions: what you have lent out and what you have borrowed in. A loan records the other party, the dates, the due date and the condition the copy left and came back in, and the open loans of either direction download as CSV.

Yes. Provenance events form a dated chain on a copy, each with its own type, the party involved, a description and any documents you attach.

Yes. Maintenance records carry the kind of work, the date, the cost, who did it and the paperwork that came back with it.

Yes. Valuations record what a copy is worth over time and where that figure came from. Transactions record what was paid or received, when, and with whom. Amounts are stored in the currency of the collection.

Yes. Photos are managed on the item and from an account-wide library that shows every image you have uploaded. Documents are managed on the copy or record they belong to, and every one of them turns up in search.

Yes. One search covers items, copies, collections, photos, loans, locations, sets, series, categories, tags and documents, and results are grouped by kind. It works even though the underlying text is encrypted, because words are indexed as hashes rather than stored in the clear.

Yes, per collection: totals, value over time, acquisitions per month, breakdowns by category, condition and location, the most valuable items, and how far your sets are from complete. There is no account-wide roll-up screen yet, and the dashboard shows recent activity instead.

Yes. An owner invites by email and picks the role at that moment. The invitation is claimed with a link, and there is no charge per member.

Three: owner, editor and viewer. Owners manage members, settings and deletion, editors create and change records, viewers only read. An account always keeps at least one owner, so the last one cannot be removed or demoted.

Yes. Everyone in an account works on the same collections, and every action is logged with who did it, so the activity feed and an item's history show where a change came from.

Not yet. A collection carries a visibility setting, and it is saved, but nothing enforces it and there is no public link, so a collection marked public is not reachable from outside the account at all.

Not from other members of your own account, for the same reason: visibility is recorded but not enforced today. Anyone you invite can see every collection in the account, so keep genuinely separate things in separate accounts for now.

Yes, immediately, by an owner. Access ends there and then, and what the person recorded stays in the account.

Yes, that is what accounts and roles are for. One thing to plan around: a person belongs to exactly one account, and an email address can only have one user, so somebody cannot join a club account and keep a personal one.

The application has a support section where you open a thread and get replies in place. It is switched off unless the instance operator turns it on, so on a self-hosted instance it is normally not there.

Docker Engine 24 or newer with the Compose plugin, and enough disk for your photos and documents. A small VPS or a machine at home is plenty. The stack starts the web server, a queue worker, a scheduler and MySQL.

Yes, and it is the recommended path. Copy the example environment file, generate an application key, and bring the stack up. The full guide lives in the repository and in the self-hosting section of the documentation.

Yes. It is a conventional Laravel application, so PHP 8.4 with the usual extensions, a database, a web server, a queue worker and a scheduler will do. You just get less help from us than the documented Docker path.

MySQL 8, which the Docker stack runs for you. SQLite works for local development, and other engines Laravel supports may work, but MySQL is what the project is tested and documented against.

Pull the newer image and restart the stack. Migrations run on boot, and they are written to be safe on an existing database, so your data and uploads are never reset by an upgrade.

They are yours to arrange. Back up the database volume and the storage volume, keep your APP_KEY somewhere safe, and test a restore occasionally. Nothing about backups happens automatically on your own instance.

Yes. Photos and documents go to the local volume by default, and pointing FILESYSTEM_DISK at any S3 compatible bucket moves them there. Files are still served through account-checked routes rather than public URLs.

Yes, through the mail settings in your environment file: any SMTP server, or Resend. Email defaults to the log file, so set this up before you invite anybody.

The MIT licence allows any change you like. The practical caveat is that a heavily patched instance is harder to upgrade, so contributing a change upstream is usually the better trade.

Community support, through GitHub issues and discussions. There is no paid support contract to buy, and that is the honest difference between running it yourself and having somebody run it for you.

Yes, a JSON API that mirrors the web application: the same actions and the same rules, roughly a hundred and fifty endpoints, with the reference published at /docs/api on every instance.

With a personal access token sent as a bearer token in the Authorization header, over HTTPS. You can also exchange an email and password for a token through the login endpoint.

Yes, from your profile settings, and you can revoke any of them individually. A key carries exactly the permissions your role has, and it has no scopes or expiry date today. You get an email whenever a key is created or destroyed.

Collections and their types, custom fields and groups, items, copies, photos, tags, categories, sets, series, locations, conditions, documents, transactions, valuations, insurance, maintenance, provenance, location history, loans, the trash, search, statistics, members and invitations. Reads and writes, subject to your role.

Yes: 60 requests a minute once authenticated, and 6 a minute on sign-in and registration to slow down guessing.

Halfway, and it is worth knowing which half. You can register endpoints and each gets its own signing secret, but no application event fires a webhook yet. The delivery machinery is ready and waiting for events to be wired up.

Yes. Anything the interface does, the API does, so importing a catalogue from a script or exporting one on a schedule is entirely possible today.

It is written next to the code, in the repository, and rendered into the reference you read at /docs/api, with a Markdown version of every section. A test fails the build when an endpoint has no documentation, which is what keeps the two together.

Please do. Bug reports, feature ideas, translations, documentation and pull requests are all welcome, and issues labelled "good first issue" are a friendly place to start.

In the GitHub issues for the project, or in the discussions if it is more of a conversation than a bug. Security problems are the exception: email those privately instead.

No. It records what you tell it. It has no way to confirm that an item is genuine, and it never claims to.

No. It stores the valuations you or a professional enter, with a note of how confident that figure is. It does not look up market prices or generate a value of its own.

No. It is a record-keeping tool, and the terms of use say as much. Decisions about coverage, tax and sale belong with the relevant professional.

No. A well kept record with receipts, photos and provenance is useful supporting evidence, but it is not proof of title, and anybody with access to the account can write anything into it.

For a private collector or a small group, often yes. For accession standards, conservation workflows or statutory reporting, no, and you should not plan around it doing so.

It is stored faithfully, mistake and all. Each item keeps a history of what changed and who changed it, so you can find the error and correct it.

The honest list: no item or collection export and import, per-collection visibility that is saved but not enforced, webhooks that never fire, no native mobile app, no single sign-on or session management, statistics per collection rather than for the whole account, and one account per person. The feature status page in the documentation keeps this list current.

There is no dated roadmap to point at, on purpose. The open issues on GitHub show what is being worked on, and the feature status page in the documentation says what is finished and what is not.

Through the support section inside the app where an instance has it switched on. Otherwise GitHub issues and discussions are the place, and one person reads them.

Email the maintainer privately rather than opening a public issue, so a vulnerability can be fixed before it is described in public. Reports made in good faith are welcome and are dealt with first.