Open-source alternatives to Pocket: 4 read-it-later and bookmarks tools compared

Extracted text, a bookmark row, an archived copy, and a tagged pile

Pocket is a read-it-later service: you save articles from a browser or phone, read them later in a clean view, and tag them. People look elsewhere for three reasons. The saved library lives with the vendor. Full-text search and permanent copies are paid features. And shutdowns and product changes happen at the vendor's discretion.

The third reason is the one a self-hosted tool answers, and the first two are the ones that decide which tool. Every project here stores URLs. They differ in what else they keep.

wallabag/wallabag keeps extracted text. Its README describes a web application that saves pages for later reading and extracts the content so you will not be distracted by pop-ups, and the extraction itself is delegated to three named libraries, Graby, php-readability and ftr-site-config. That is the closest match to what Pocket does, and it is also the option that stores the least: a clean reading view of the article as it was when you saved it, with no copy of the page itself.

sissbruecker/linkding keeps a bookmark row and a note. The feature list is clean UI optimised for readability, tags, bulk editing, Markdown notes, read it later functionality, sharing with other users or guests, automatic titles, descriptions and icons, and an option to archive the site as a local HTML file or on the Internet Archive. What it does not do is index the contents of pages for search, which our analysis of linkding names as the reason not to choose it for that.

linkwarden/linkwarden keeps a copy. The README makes preservation the reason the project exists, tying it to link rot, and its first feature is automatically capturing a screenshot, a PDF and a single HTML file of each page. On top of that it adds a reader view with highlighting and annotation, an optional Wayback Machine snapshot, optional local AI tagging, collections and sub-collections, per-member permissions and public sharing.

karakeep-app/karakeep keeps everything and organises it. The README describes links, notes, images and PDFs in one place, automatic fetching of titles, descriptions and images, full page archival using monolith, automatic video archiving, OCR for images, full text and semantic search of the stored content, LLM-based automatic tagging and summarization with local models through ollama, a rule-based engine, lists you can collaborate on, and mobile offline reading.

Instapaper and Raindrop.io are the other two names in these searches and neither is here. Instapaper is a hosted service, which is the reason people leave. Raindrop.io appears in Karakeep's own README as a polished open source bookmark manager that supports links, images and files but is not self-hostable, which puts it in the same position.

Left out, and worth saying why: the browser bookmark synchronisers, which solve a different problem and share nothing with a reading queue, and the note-taking applications, which are far more than somewhere to put a link.

Choosing by scenario: one reader, a shared collection, a company with rules, a developer wiring it into a workflow

The deciding question is how much you intend to keep, and who else has to read it.

One reader who wants the Pocket experience on their own server should look at wallabag/wallabag. It extracts the article, it has clients for the phone and the browser, and our analysis of wallabag frames it as the right tool for someone who does not want a vendor holding their reading history. The cost is a PHP application and the discipline of running it.

One reader who wants a tag-based store and nothing more should look at sissbruecker/linkding. One container, a REST API, tags, and a decision about SQLite or Postgres. Our analysis of linkding is the useful part: it is the wrong tool if you need to search inside page contents, and it says so plainly.

A shared collection where the point is that links will not rot should look at linkwarden/linkwarden. The screenshot plus PDF plus single-file capture is what makes it different, and the README adds collaboration, per-member permissions and public sharing on top. Our analysis of Linkwarden frames the audience as engineers, researchers and small teams who need a permanent searchable archive, and adds the honest condition that three Docker services on a modest VPS is a real cost.

A personal archive that you want searchable and automatically filed should look at karakeep-app/karakeep. It is the only one of the four that combines full text and semantic search with automatic tagging, and the only one that will use a language model to do the filing. Our analysis of Karakeep is direct that if you will not send content to an LLM and do not want to run ollama locally, that is a reason to skip it.

A developer wiring this into a workflow has three of the four available. linkding and Linkwarden both publish a REST API, and Karakeep lists a REST API and multiple clients. wallabag is the one to check first if you need clients the project maintains, since its Android and iOS apps and browser extension are first-party.

What each one asks you to run

The install commands on this page are mostly a starting point rather than the whole picture, and the gap between them is the operational difference.

wallabag/wallabag shows a git clone followed by make install, and the README then tells you to configure a virtual host. That last step is the one people underestimate: wallabag is a PHP web application, so it needs a web server, PHP and a database, and the requirements are documented at doc.wallabag.org rather than in the repository.

sissbruecker/linkding shows docker compose up -d, which matches our analysis of linkding describing it as a single Docker container with a database behind it. What the command does not tell you is the reverse proxy configuration, and that is where the analysis points: LD_CONTEXT_PATH and LD_CSRF_TRUSTED_ORIGINS in the sample environment file have to match how your proxy actually serves the app, or the interface breaks in ways that look like bugs.

linkwarden/linkwarden shows copying the sample environment file and then docker compose up -d, and our analysis of Linkwarden makes the environment file the important part: NEXTAUTH_SECRET and POSTGRES_PASSWORD have to be set before you start, and you should confirm the memory headroom for three concurrent services first. The README also points to community-maintained mobile clients, including My Links for iOS and macOS, LinkDroid for Android, LinkGuardian for Android and StarWarden for saving starred GitHub repositories, which is a hint about how much of the client surface is not first-party.

karakeep-app/karakeep shows pnpm install and pnpm web, which is a source build rather than a deployment. The deployed shape is documented on its installation page, and our analysis of Karakeep points out that the repository's sample environment file lists only DATA_DIR and NEXTAUTH_SECRET, so the full variable set has to come from the documentation. The heavier part is the stack it names: Puppeteer for crawling and Meilisearch for full content search, which is what the analysis means by needing a few gigabytes of headroom.

Across all four, the recurring costs are the same: a database, somewhere to store archived files if the tool keeps any, and a crawl or fetch worker.

Licences: two MIT, and two AGPL-3.0

Two of these four are MIT and two are AGPL-3.0, and the split is close to the split in what each tool does.

wallabag/wallabag and sissbruecker/linkding are both MIT. wallabag's README states it directly, with copyright attributed to Nicolas Lœuillet and the terms in COPYING.md. For a personal library on your own server, neither licence is a live consideration, and for a company modifying linkding to add an internal integration, the permissive position is the simpler one.

karakeep-app/karakeep and linkwarden/linkwarden are AGPL-3.0. For internal hosting without modification, again, nothing changes. For a company that modifies either and lets users reach the modified instance over a network, the source obligation applies. Our analysis of both projects treats this as a condition to check against how you intend to distribute what you build rather than as a blocker, which is the right way to hold it: the licence is a conversation about your distribution model, not a verdict on the tool.

One point applies to all four, and it is the one that matters more than the licence. A read-it-later library is a record of what you found interesting, which over time is a map of your work. Whether that map can be exported in a format you control is a more consequential question than which of these four licences you accept, and the answer differs: linkding documents Netscape HTML import and export, while the other three make you work out their own export path before you need it.

Bottom line

Pick wallabag/wallabag for the closest match to Pocket's behaviour on your own server, sissbruecker/linkding for a small tag-based store in one container, linkwarden/linkwarden when the page must survive the page disappearing, and karakeep-app/karakeep when you want full text search and automatic filing over a large personal archive. Before committing, check the PHP and database requirements for wallabag, match LD_CONTEXT_PATH and LD_CSRF_TRUSTED_ORIGINS for linkding, set NEXTAUTH_SECRET and POSTGRES_PASSWORD and check memory for Linkwarden, and confirm you are willing to give Puppeteer and Meilisearch the resources Karakeep needs.

Sources

1. Pocket official site
2. wallabag/wallabag repository
3. wallabag/wallabag README
4. sissbruecker/linkding repository
5. sissbruecker/linkding README
6. karakeep-app/karakeep repository
7. karakeep-app/karakeep README
8. linkwarden/linkwarden repository
9. linkwarden/linkwarden README