Shaarli: A Single-User Bookmark Service That Stores Everything in Flat Files

The problem Shaarli solves is one person's link pile, not a team's knowledge base

Most bookmarking tools assume more than one user. They ship accounts, roles, sharing scopes, and a database that has to be provisioned, backed up, and migrated. Shaarli points the other way. The README calls it a minimalist link sharing service you install on your own server, and it states the design goal directly: personal (single-user), fast and handy. That parenthetical is the whole product decision. There is no team model to configure away, because there is no team model. If you have ever kept a decade of links in browser bookmarks and watched them vanish with a profile reset, the target use case is obvious. You want the archive on hardware you control, in a format you can read without the application. The repository topics list bookmarking, bookmarks, bookmarks-manager, and self-hosted, which matches the README's framing. It is not a read-later service with a recommendation feed, and it is not a social bookmark network. It is a private index of URLs that one person maintains.

Database-free means the storage layer is the data model

The README's one-line description is the architectural claim: database free. Shaarli is written in PHP, and the absence of a database server is not a footnote, it is the constraint that shapes everything else. There is no schema to migrate and no ORM layer between the application and the bytes on disk. The practical consequence for an operator is that a backup is a file copy and a restore is a file copy back. You do not need to sequence a dump against a running service or worry about a half-applied migration. The cost is on the query side. Anything a relational engine would give you for free, such as joins across tags, aggregate counts, or indexed full-text search, has to be handled in PHP over the stored data. The README does not document the internal file layout in the excerpt available here, so the exact on-disk format cannot be confirmed from this material. What can be confirmed is the design intent: the project presents database freedom as a feature, and the documentation site at shaarli.readthedocs.io is where the storage details would live. Treat that documentation as required reading before you plan an import of an existing bookmark export, because the file format is the interface you will be scripting against.

Getting it running: the README points at documentation and a container image

The README's Quickstart section is short. It links to the documentation at https://shaarli.readthedocs.io, the change log at CHANGELOG.md, and the issue tracker for bugs, feature requests, and discussion. It does not inline an install command. What it does provide is a demo instance at https://demo.shaarli.org, with the credentials demo and demo, and a note that the demo runs the latest development version and is updated and reset daily. That is the fastest way to see the interface before you install anything, and the daily reset means you should not treat it as storage. For installation, the repository ships a Docker path: the README carries a Docker repository badge pointing at the GitHub container registry under the shaarli organization, and the badges reference a release tag v0.16.5 and a master branch labelled v0.16.x. The CI and Trivy release workflows are linked from badges as well, which tells you the project runs automated checks on pushes and on releases. Beyond that, the README excerpt does not list PHP version requirements, web server configuration, or the exact docker run invocation. Those are on the readthedocs site. If you are evaluating Shaarli for a server you already run, budget time for the documentation rather than expecting a copy-paste command in the repository front page.

The single-user design is a limitation, not a missing feature

It is tempting to read personal (single-user) as a v1 constraint that a later release will lift. The README presents it as the design. That has consequences you should accept up front. There is no account provisioning, no per-user permission model, and no natural way to give a colleague write access to a subset of your links. If two people want a shared collection, the honest options are to run two instances or to pick a different tool. The second limitation follows from the first: with flat-file storage and no query engine, behaviour at scale is bounded by how the application walks that data. The README makes no claim about how many bookmarks an instance handles comfortably, and this review will not invent a number. If your archive is in the tens of thousands of entries and you expect fast tag intersections or substring search, that is a case to test on your own data before migrating, because the architecture gives you no index to lean on. A third point is worth stating plainly: the repository metadata reports the licence as NOASSERTION. The README says Shaarli is Free Software and directs you to the COPYING file for a detail of the contributors and licenses for each individual component. A per-component licence breakdown means the project is not a single uniform grant, and that has to be read, not assumed.

What you are choosing instead: a database-backed bookmark manager

The obvious alternative class is a bookmark manager backed by a relational database, of which the wider self-hosted ecosystem has several. The difference is not cosmetic. A database-backed manager can offer multi-user accounts, shared collections with per-user visibility, and server-side search that scales with an index rather than with a directory scan. It can also enforce referential integrity when you delete a tag or merge two entries. What it cannot offer is Shaarli's operational simplicity. With a database in the stack you gain a second service to install, a connection string to manage, a dump-and-restore procedure for backups, and a migration step on every upgrade that touches the schema. Shaarli's flat-file approach collapses all of that into copying files. The choice therefore comes down to which cost you would rather pay: the recurring operational cost of running a database, or the functional ceiling of an application that has no query engine. Neither answer is universally right. A solo archivist who backs up to a synced folder will find Shaarli's model easier to reason about. A small team that wants shared tags and per-user access will spend more time working around Shaarli than it would spend administering a database.

Maintenance, releases, and the licence question you have to resolve yourself

The release history in the repository metadata shows v0.16.5 and v0.16.4 both dated 2026-07-31, and v0.16.3 dated 2026-05-28. Two releases on the same day usually means the first had a defect serious enough to warrant an immediate follow-up, though the metadata alone does not say why. Read the CHANGELOG.md entry for that date before you pin a version. The cadence across the v0.16.x line is roughly monthly to bi-monthly in that window, and the last push to the repository is dated 2026-09-04, so the project is active. The master branch badge is labelled v0.16.x, which indicates the development line tracks the same minor series rather than jumping ahead. On upgrades, the database-free design works in your favour: there is no schema migration to plan, so the risk is concentrated in file format changes and in the PHP runtime the new version expects. Check the change log for both. On licensing, the repository reports NOASSERTION and the README defers to COPYING for a per-component breakdown. That is not a legal opinion and this review will not give one. It is a concrete instruction: open COPYING, identify the components your deployment actually uses, and confirm the terms cover your use. If you redistribute Shaarli or bundle it into a product, that file is the document that matters.

Editorial conclusion

Adopt Shaarli if you are one person who wants a private link archive on your own server and you would rather copy a directory than run a database. Do not adopt it if you need multi-user accounts, shared team collections, or full-text search across a large corpus, because the README describes the project as designed to be personal and single-user, and the storage model is flat files rather than an indexed store. Before committing, verify three things: the COPYING file, since the repository metadata reports the licence as NOASSERTION and the README points to that file for a per-component breakdown; the Docker image tag and its pull source, because the README links to a container registry rather than describing a versioned release process; and the upgrade path across the v0.16.x line, since three releases landed within roughly five months.

Official sources

1. Issues
2. Project website
3. README
4. Releases
5. shaarli/Shaarli on GitHub