Self-hosted Instapaper alternative: own your reading list with Wallabag

Read-later services keep teaching the same lesson at their users' expense. Omnivore shut down and told everyone to export. Pocket -- the default read-later app for over a decade -- has been sunset by Mozilla. Instapaper is still standing, but "still standing" is a status report, not a commitment, and features that used to be free have a habit of migrating behind paywalls across this whole category. The pattern matters because a reading list is not a queue you clear by Friday. It is a long-term archive of everything you meant to learn, built one article at a time over years -- and an archive deserves infrastructure with a longer horizon than a product team's next pivot.

Wallabag is the version you own. Save an article once and it stays saved -- not until an acquisition, not until a sunset announcement, but until you delete it.

What Wallabag is

Wallabag is an open-source read-it-later application. You save a link -- from a browser extension, a mobile app, or a bookmarklet -- and Wallabag fetches the page, strips away the ads, popups, cookie banners and layout debris, and stores the article as clean, readable text on your server. What you read later is the writing, not the website.

The storage detail is the one that separates it from a bookmarks folder: Wallabag keeps the extracted content itself, not just the URL. When the source page changes, disappears behind a paywall, or vanishes along with its publication, your copy is unaffected. The reading list doubles as a private library of everything that ever earned a place in it.

The features that actually matter

• Clean article capture. Pages are reduced to readable text and images -- no ads, no interstitials, no "subscribe to keep reading" overlays. Long reads become actually readable, on whatever screen you pick them up on.
• Tags and search. Tag articles as you save or after you read, and search across everything you have ever kept. A five-year-old article you half-remember is a query away, because the full text is in your database, not on a dead domain.
• Browser extensions and mobile apps. Saving is one click from the browser and a share-sheet tap from a phone. Reading syncs across devices, with your position kept, so the commute picks up where the desk left off.
• Annotation. Highlight passages and attach notes directly to the text. The margin scribbles that make a reading list worth revisiting live with the article, on your server, not in a feature tier.
• Export to real formats. Articles export to EPUB and PDF among other formats -- send a batch of long reads to an e-reader, or archive a finished research topic as a single document. Your library is portable even out of Wallabag itself.
• RSS feeds of your saves. Your unread list, your archive, your starred items -- each is available as a feed, which turns your reading list into a source other tools can consume: a feed reader, an automation, a static site.
• Imports from the services that left you. Wallabag ingests exports from Pocket, Instapaper and Omnivore, among others. The archive you built somewhere else comes with you instead of dying with the product.

An archive, not a cache

The quiet assumption behind every hosted read-later service is that your reading list is disposable -- a cache of recent intentions, fine to lose. Everything about the last few years argues otherwise. Links rot at a pace that makes a URL-only bookmark nearly worthless on a five-year horizon: publications fold, CMS migrations break paths, paywalls descend retroactively. The article you saved is often literally not there anymore.

A Wallabag instance inverts the failure mode. Because the extracted text lives in your database, the death of the source page costs you nothing. Because the whole application is open source and runs on your infrastructure, the death of a vendor costs you nothing either -- there is no company whose pivot can orphan your library. And because everything exports to open formats, even Wallabag itself is not a point of lock-in. That is what infrastructure you control actually means: every exit door is open, and none of them is behind you.

It also changes how you save. When the archive is permanent and searchable, saving stops being a guilty backlog and becomes filing. You are not promising to read everything by Sunday; you are building the reference library your future self will query.

Running it on Caliber Node

Wallabag is a one-click deploy from the Caliber Node catalog -- and it deploys ready to sign in. The first-run database setup that self-hosters commonly hit with Wallabag is already done by the time the URL loads, because we run its installer during deployment. You open the address, log in, and install the browser extension; the plumbing happened without you.

• One subscription, not per-app pricing. Wallabag runs inside a capacity subscription alongside whatever else you host -- an RSS reader and a bookmark manager are natural neighbors. Nothing is billed per app.
• HTTPS and your domain, automatic. Your instance comes up behind Cloudflare with HTTPS already issued. Point a custom domain at it and every extension and mobile app talks to an address you own.
• Your archive on your volume. The database holding every article you have ever saved lives on storage you can reach over SFTP, with snapshots for restore points -- the archive is backed by something you can physically copy.
• Email out of the box. For apps that send sign-in links or notifications, transactional email works platform-wide without configuration -- one less form standing between deploy and daily use.

Export your Pocket or Omnivore archive one last time, import it into Wallabag, and stop migrating. The reading list becomes what it always should have been: a library that answers to nobody's roadmap but yours.