Faved: A Self-Hosted Bookmark Manager Built Around Nested Tags
Free open-source bookmark manager with customisable nested tags. Super fast and lightweight. All data is stored locally.
At a glance
- What is it?
- Faved is an MIT-licensed bookmark manager with a PHP 8 and SQLite backend and a React frontend. Its distinguishing feature is nested tags, which let folder hierarchies from Chrome, Safari, Firefox and Edge survive an import instead of collapsing into a flat list.
- Who is it for?
- Faved fits people with large, folder-heavy bookmark collections who want the data on their own disk and are willing to run a PHP 8 and SQLite stack. It does not fit anyone who wants a managed sync service with no server to administer, or who needs a documented public API before adopting.
- 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 41 days ago.
- What is it written in?
- Mainly TypeScript, 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 Faved Targets: Folder Structure That Survives Import
Most bookmark tools treat tags as a flat namespace. A browser export does not. Chrome, Safari, Firefox and Edge store bookmarks in nested folders, and a flat tag list flattens that hierarchy on the way in. Faved's answer is the nested tag: the README gives the example of placing Go and Python under Programming Languages then Backend. That is a tree, not a list, and the import path preserves it. The README states that importing from those four browsers keeps the original folder structure because the folder tree maps onto nested tags. The same claim is made for migrations from Raindrop.io and Pocket, where original collections and tags are retained. This is the specific problem the project solves, and it is a narrower problem than bookmarking in general. If your collection is a few dozen links you save and forget, nesting adds a taxonomy you will not maintain. If your collection is thousands of links accumulated across browsers over years, the hierarchy is the only thing that makes it searchable, and losing it is the reason people abandon a migration halfway.
Architecture: PHP 8, SQLite and a React Frontend in One Repository
The repository layout is conventional server-rendered MVC with a separate single-page frontend. The README lists controllers, a framework directory, models, views for HTML templates, public for web-accessible files, and storage for the database. The credits section names the stack: TypeScript, React, Tailwind, Shadcn UI and Vite on the frontend, PHP 8, SQLite and Apache on the backend. The language tag on the repository says TypeScript, which reflects where most of the source lines live, but the server side is PHP. That combination matters for deployment. There is no separate database service to provision, because SQLite is a file inside storage. There is no Node process to keep alive in production, because Vite is a build-time tool. A single Apache host with PHP 8 and a writable storage directory is the whole runtime. The README describes self-hosting as having no external dependencies, and the architecture supports that claim: the only state is the SQLite file. It also means horizontal scaling is not on the table. Two application servers pointed at one SQLite file is not a configuration the project describes, and nothing in the material suggests it is supported.
Tag Behaviour: Rollup, Pinning and the Cost of a Deep Tree
The tagging model has a few behaviours worth understanding before you commit to it. Tags carry a colour and a description, with icons listed as coming soon in the README, so the visual metadata is partially implemented. The sidebar supports searching and filtering tags, and frequently used tags can be pinned. The interesting switch is tag rollup, described as optional, which includes items from child tags when you view a parent. Rollup is what makes a deep tree usable: without it, clicking Programming Languages shows nothing if every bookmark actually sits under Backend or Go. With it, the parent becomes an aggregate view. The trade-off is that rollup changes what a tag click means, and the setting is global rather than per-tag as far as the README describes. A collection where one branch should aggregate and another should not has no documented way to express that. Bulk actions are also tag-aware: the README lists bulk tagging alongside bulk deleting and refetching, which is the mechanism for retrofitting structure onto an imported collection that arrived with messy folders.
Running It: What the README Actually Gives You
Here the documentation is thin in a way worth flagging. The README's get started section does not contain an install command. It links to a self-hosting installation page and to a cloud signup, and that is the extent of it. The topics list includes docker, so a container image is plausibly part of the self-hosting path, but the README does not show a docker run or docker compose invocation, and I am not going to invent one. What the README does establish about the runtime is the stack: PHP 8, SQLite and Apache, with the database living under storage and web-accessible assets under public. Anyone evaluating this should open the installation page before assuming a one-line container start. The same applies to updates: the README links to a dedicated updating page rather than describing the procedure inline. That is a reasonable documentation split for a project with a hosted product alongside the open source code, but it means the repository alone is not sufficient to deploy. The browser extension is published on the Chrome Web Store, and the README describes a bookmarklet as the extension-free alternative, plus Apple Shortcuts for the iOS and macOS share sheet. Those are the three capture paths named.
Where Faved Is the Wrong Tool
Two limitations stand out from the material. First, there is no public API in the README. For a self-hosted tool, the API is often the reason to self-host: you want to script against it, feed it from a scraper, or wire it into a notes system. Faved's documented integration surface is the Chrome extension, the bookmarklet, and Apple Shortcuts. Those cover manual saving well and programmatic access not at all. If your use case is automated ingestion, this is the wrong project as documented. Second, automated tagging is listed as planned, not shipped. The README marks it explicitly. So the promise of a self-organising collection is not something you can evaluate today. Third, the single-file SQLite backend is a real constraint on backup and concurrency strategy. It is also the reason setup is simple, so it is a trade rather than a defect, but anyone planning to run this for a team should note that the material describes a personal bookmark manager, not a shared one. There is no mention of multi-user accounts, permissions, or sharing in the README.
Alternatives: Raindrop.io and the Sync-Service Model
Raindrop.io is the comparison the README itself invites, since it names Raindrop.io and Pocket as migration sources. The difference in approach is structural. Raindrop.io is a hosted service: your bookmarks live on someone else's infrastructure, sync happens automatically across every client, and there is nothing to administer. Faved inverts that. Data lives in a SQLite file on your host, and the README states plainly that all data is stored locally. You get control of the file and responsibility for the host. The nested tag model is also a deliberate departure: Raindrop's collections and tags are separate concepts, while Faved merges the folder tree into the tag tree so that a browser import maps cleanly. There is a hosted Faved option at app.faved.to for people who want the software without the server, which the README describes as zero setup with automatic backups, so the project does not force the self-hosting choice. The honest framing is that Faved's self-hosted mode competes on data ownership and on import fidelity, not on sync convenience. If automatic multi-device sync is the feature you care about most, the hosted tier or a service like Raindrop.io is the more direct answer.
Licence, Maintenance and Upgrade Cost
The project is MIT licensed, which is permissive: you can use, modify and redistribute it, including in commercial settings, provided the licence and copyright notice are preserved. That is a statement about the licence text, not legal advice, and anyone embedding Faved in a product should read the LICENSE file in the repository rather than take this paragraph as counsel. On maintenance, the release cadence is visible: v2.9.0 in March 2026, v2.9.1 in June, v2.10.0 in August, with the last push to main on the same day as the most recent release. That is a steady minor-release rhythm rather than a frozen project. The practical cost for a self-hoster is the upgrade path, which the README delegates to a dedicated updating page. Because the backend is PHP with a SQLite file, upgrades plausibly involve both code replacement and any schema migration the release carries, but the README does not describe the mechanism, so the updating page is required reading before you deploy. The absence of external dependencies keeps the surface small: no Redis, no Postgres, no message broker to version alongside the app.
Editorial conclusion
Faved fits people with large, folder-heavy bookmark collections who want the data on their own disk and are willing to run a PHP 8 and SQLite stack. It does not fit anyone who wants a managed sync service with no server to administer, or who needs a documented public API before adopting. Verify two things first: the exact Docker invocation on the installation page, since the README only links to it, and the update procedure on the updating page, because the changelog shows three releases between March and August 2026 and self-hosted upgrades are the maintenance cost you are signing up for.
Community notes