By LK Wood IV · Published 2026-07-25 · Updated 2026-07-25 · ~11 min read · St. Louis County, MO

TL;DR · Decide whether you want to read or to organize

  • Pocket is gone — shut down 2025-07-08, data deleted from 2025-11-12 (not the October 8 date most write-ups repeat).
  • The export was URLs only. Mozilla's CSV did not contain your article text, so no migration carries your saved reading across.
  • Want to read? Readeck (0.22.3, AGPL-3.0) or wallabag (2.6.14, MIT) — both extract and store the readable article.
  • Want to organize links? linkding (1.45.0, MIT — one container on SQLite) or Shiori (1.8.0, MIT, single Go binary).
  • Want archive-everything at scale? That is the bookmark-manager end — see Karakeep vs Linkwarden.

Versions checked 2026-07-25 against each project's release API. Check the changelog before copying a compose file.

Decision diagram for self-hosted read-it-later apps in 2026: if you want to read articles later, choose Readeck 0.22.3 AGPL-3.0 or wallabag 2.6.14 MIT, both of which extract and store readable article text; if you want to organize links, choose linkding 1.45.0 MIT which is a single container on SQLite with archiving only in the latest-plus image, or Shiori 1.8.0 MIT which is a single Go binary; if you want to archive and organize at scale, that is the bookmark-manager end covered by Karakeep and Linkwarden. A banner notes Pocket shut down on 2025-07-08 and deleted data from 2025-11-12, and that its export contained URLs only.

What actually happened to Pocket

Mozilla announced the phase-out on 2025-05-22, writing that it had “made the difficult decision to phase out two products: Pocket, our read-it-later and content discovery app, and Fakespot” (Mozilla). The service shut down on 2025-07-08 and dropped into export-only mode.

Here is the part almost every write-up gets wrong. The original announcement said data would be deleted after October 8, 2025, and that date is what got copied across the internet. It was superseded. Mozilla’s own support article states plainly: “As of November 12, 2025, user data export has been disabled, and all user data has been queued for permanent deletion” — the same date the Pocket API was switched off (Mozilla Support, via Internet Archive). If you are reading this in 2026 wondering whether your list is still recoverable: it is not.

Two details matter more than the dates, because they shape what a replacement can actually do for you:

The export was a CSV of links. Mozilla’s instructions told users to click “Export CSV file” at getpocket.com/export, and the support article is explicit that the file contains the URLs of saved items rather than the article text (Mozilla Support, via Internet Archive). Ten years of saved reading came back as a spreadsheet of addresses.

Every official escape route was another cloud. Mozilla published a list of “third-party services that we understand support the import of Pocket data” — GoodLinks, Futurwise, Instapaper, Matter, Raindrop.io and Readwise — while explicitly stating it had not vetted them (Mozilla Support, via Internet Archive). Every one is hosted. Not a single self-hosted option appeared — which is the whole reason this page exists.

Read-it-later or bookmark manager? Answer this first

Most “Pocket alternative” lists quietly mix two different products, and it is the single biggest source of disappointment when people migrate.

  • A read-it-later app is built around consuming an article. It extracts the readable text, strips navigation and ads, and gives you a reader view — the thing Pocket actually was.
  • A bookmark manager is built around organizing and preserving links, usually with a full-page snapshot so the page survives link rot. Excellent at recall; not necessarily a nice place to read.

Self-hosting threads keep re-litigating this, with people pointing out that a given “Pocket alternatives” roundup is mostly bookmark managers, and others arriving at the same conclusion after trying half a dozen tools. If your goal is “I want to read these six articles on the couch tonight,” a bookmark manager will technically store them and still leave you unsatisfied.

This page covers the reading end, plus the lightweight link-organizers people most often reach for as Pocket replacements — some of which describe themselves as bookmark managers, and are included here precisely because that overlap is where the confusion lives. What this page does not try to settle is heavyweight archival at scale: the two strongest options there get a dedicated head-to-head in Karakeep vs Linkwarden, which resolves the organize-versus-archive split within that category.

The tools, by the job they do

Readeck — the closest thing to “Pocket, self-hosted”

Readeck describes itself as an app that “lets you save the precious readable content of web pages you like and want to keep forever” (Readeck on Codeberg). That framing is the point: it is a reader first, an archive second.

Current stable is 0.22.3, released 2026-04-16, under AGPL-3.0, with the repository actively updated as of this writing (verified via the Codeberg API on 2026-07-25). It is the tool that comes up most often in self-hosting threads as the recommendation over the heavier options, usually on resource-efficiency grounds — though that is community sentiment, not a benchmark.

wallabag — the veteran, and the one with real export

wallabag is the veteran option here. It is explicitly a content-extraction app — its README describes saving a web page and keeping only readable content, built on the Graby and php-readability extraction stack (wallabag README).

Current stable is 2.6.14, released 2025-10-07, under the MIT license, with commits on the default branch as recently as 2026-07-24. It is a PHP application requiring PHP 7.4+ and a PDO database — SQLite, MySQL/MariaDB, or PostgreSQL (requirements) — and the documented Docker quick-start runs on SQLite (installation).

Two things wallabag has that most of this field does not: in-article annotations and highlights (annotations docs), and per-article export to ePUB, PDF, XML, JSON and CSV, including exporting a whole category at once (download docs). If you want saved articles on an e-reader, that is the feature to look at. It also ships first-party Android and iOS apps plus the wallabagger browser extension.

Honest counterweight, from self-hosting threads rather than the docs: wallabag’s initial setup gets criticised for requiring an OAuth client ID and secret on top of a username and password, and one long-time user reported Android sync degrading past roughly fifteen thousand saved articles. Both are single data points, but the scale ceiling is the only concrete one anyone named in this space.

linkding — minimal, fast, and archiving is opt-in

linkding is positioned as a minimal, fast, Docker-first bookmark manager, and it is the tool the community reliably names when someone asks which is snappiest. Current stable is 1.45.0, released 2026-01-06, under the MIT license, on a steady cadence (five stable releases between 2025-08-16 and that date). It is a Django app using SQLite by default, with PostgreSQL optional (no MySQL), and its image runs on ARM including Raspberry Pi.

The detail that surprises people: server-side archiving is not in the base image. HTML snapshots live in the latest-plus variant, which drives singlefile-cli against a headless Chromium, and whose documentation asks for at least 1 GB of RAM to run that Chromium (linkding archiving docs). linkding can also push pages to the Internet Archive instead of storing snapshots locally. So the “linkding is light” reputation applies to the base image — which is not the archiving one.

Shiori — one Go binary, slow and steady

Shiori is a bookmark manager distributed as a single Go binary, usable as a CLI or a web app, and explicitly modelled on Pocket (Shiori README). It does archive page content by default, parsing readable content and storing an offline copy. Current stable is 1.8.0, released 2025-09-26, MIT licensed, with SQLite by default and PostgreSQL/MySQL/MariaDB available.

The honest caveat is velocity: the project’s own FAQ describes it as maintained but slow-moving, with a single primary active maintainer (Shiori FAQ), and the browser extension is self-declared beta. The last stable release is the oldest of the four here — though the default branch had commits as recently as 2026-07-10, so this is a pace-and-bus-factor risk, not an abandoned project.

Footprint and capability, side by side

Versions verified 2026-07-25 from each project’s release API.

Readeck 0.22.3wallabag 2.6.14linkding 1.45.0Shiori 1.8.0
Primary jobRead saved articlesRead + annotate + exportOrganize links fastOrganize links, single binary
LicenseAGPL-3.0MITMITMIT
Latest release2026-04-162025-10-072026-01-062025-09-26
Stores readable textYesYes (Graby extraction)Base image: no; latest-plus: HTML snapshotYes, offline archive by default
DatabaseSee Readeck docsSQLite / MySQL / PostgreSQLSQLite default, PostgreSQL optionalSQLite default, PostgreSQL / MySQL
Notable extraReader-first designePUB export, annotationsInternet Archive integration, ARM/PiCLI + web from one binary
Documented RAM figurenone publishednone published≥1 GB for latest-plus (Chromium)none published

Nobody in this category except linkding publishes a RAM figure, and linkding’s is specifically for the archiving image. Treat any “uses only X MB” claim you read elsewhere as unverified unless it names a version and a workload.

What the Pocket export actually gives you

If you still have a CSV you exported before 2025-11-12, understand what it is before you plan a migration.

It is a list of URLs and metadata. Your new app will re-fetch each page itself — which means the result depends entirely on whether those pages still exist and still serve their content to a server-side fetcher. Pages that died, went behind a paywall, or now require JavaScript in the years since you saved them will not come back. One self-hoster hit exactly this warning while importing into Readeck; another reported a painless import into Karakeep. Both are single data points, and they are not contradictory — the import mechanics differ by tool, but the missing-article-text problem is Pocket’s, not the importer’s.

The lesson generalises past Pocket: a service that only stores your links is one shutdown away from being a list of 404s. That is the argument for running a tool that extracts and stores the article text — Readeck, wallabag, Shiori’s default archive, or linkding in its archiving image — rather than one that keeps only the URL.

Gotchas the project docs don’t mention

These come from self-hosting community threads rather than documentation. Each is one or a few data points — corroborate before betting on them.

  1. Paywalled and JS-heavy pages need the browser, not the server. The recurring workaround is the SingleFile browser extension: your logged-in browser renders the page, then pushes that snapshot into the app. Server-side crawlers get blocked precisely because they are not you. This one is not folklore — linkding documents the SingleFile-to-API upload path directly (linkding archiving docs).
  2. Cookie banners get archived too. They are part of the rendered page, and users report consent overlays dominating captured copies at scale.
  3. Reddit archiving was broken across tools as of June 2026 — one user reported Karakeep, Readeck with SingleFile, Linkwarden and linkding all failing to render post content, with a maintainer replying in the same thread (r/selfhosted). Timestamped deliberately: this is the kind of thing that gets fixed, so re-check before assuming.
  4. “Archived” and “readable offline in the app” are different claims. One Karakeep user found the offline copy existed server-side but was not viewable in the iOS app. Test the phone path specifically.
  5. Resume-reading position is a feature people repeatedly miss. Its absence is cited across separate threads as the reason users abandoned an otherwise good tool.

Which one should you run?

Choose Readeck if you want the closest thing to what Pocket was — a reader-first app whose job is making saved articles pleasant to read, with a current release and an active repo.

Choose wallabag if you want the mature option, annotations, and above all ePUB export to get saved articles onto an e-reader. Accept a heavier PHP stack and a fiddlier initial setup.

Choose linkding if speed and a tiny footprint matter more than reading experience, and you either do not need local archiving or are willing to run the latest-plus image with the RAM that Chromium wants.

Choose Shiori if you want one binary, no database server, and a CLI — with open eyes about a single-maintainer pace.

Choose neither, and read the bookmark-manager comparison instead, if what you actually want is durable full-page archival with heavy organization across thousands of links. That is a different job, and Karakeep vs Linkwarden resolves it.

Whichever you pick, it belongs on the same box as the rest of your stack — see self-hosted apps that replace SaaS for how this fits alongside the other dozen services worth running, and back it up: a reading archive you never backed up is a reading archive you will eventually lose, which is exactly what the 3-2-1 backup rule is for.

Sources

Community reports. The gotchas section and the tool-by-tool caveats draw on r/selfhosted threads read via a front-end mirror; the canonical thread URLs are below. Each is community sentiment — usually one or a few data points — not an authority, and is labelled as such in the body.

Frequently asked questions

What happened to Pocket, and when was the data deleted?
Mozilla announced the phase-out on 2025-05-22 and shut Pocket down on 2025-07-08, leaving the site in export-only mode. The widely-repeated deadline of October 8, 2025 was superseded: Mozilla’s own support article states that user data export was disabled and permanent deletion began on 2025-11-12, which is also when the Pocket API was switched off. If you never exported, that data is gone.
Which self-hosted read-it-later apps can import from Pocket?
This is the most-asked question with the least clear answer, and the honest one has two parts. Several tools accept the Pocket CSV — but the export Mozilla produced contained links and metadata only, not the text of your saved articles. So an import restores your reading list, then your new app re-fetches each page itself. Anything that had already gone offline in the years since you saved it does not come back.
What is the difference between a read-it-later app and a bookmark manager?
A read-it-later app is built around consuming an article: it extracts the readable text, strips the page furniture, and gives you a clean reader view. A bookmark manager is built around organizing and preserving links, often with a full-page snapshot. The distinction matters because most ‘Pocket alternative’ lists are actually bookmark managers, which save the link but do not necessarily give you a pleasant place to read it.
Which self-hosted read-it-later app is the lightest?
linkding is the one self-hosting threads consistently call fastest — community perception, not a benchmark — and it is a single Django container on SQLite by default. The catch is that server-side archiving is not in the base image: it lives in the latest-plus variant, which drives a headless Chromium and whose docs ask for at least 1 GB of RAM. Shiori ships as a single Go binary with no separate database server. None of these projects except linkding publishes a RAM figure, so treat footprint rankings as directional.
How do I save paywalled or JavaScript-heavy pages?
Server-side fetchers get blocked, because the app’s crawler is not your logged-in browser. The workaround the self-hosting community keeps landing on is the SingleFile browser extension: your browser renders the page as you see it, then pushes that snapshot into the app. Expect cookie and consent banners to be captured too, since they are part of the rendered page — some users report them dominating archived copies.
Do these apps remember where I left off in an article?
Not reliably, and it is a real reason people bounce off self-hosted options. Resume-reading position is a Pocket feature whose absence gets raised repeatedly in self-hosting threads, including as the specific reason users left Karakeep. If picking up mid-article on a phone matters to you, verify that behaviour in a trial before you migrate a decade of saves into anything.