Wallabag vs Cowpin: Should You Self-Host Your Reading List?

Cowpin

Cowpin

8/19/2026

#wallabag #self-hosted #comparison #migration #read-it-later
Wallabag vs Cowpin: Should You Self-Host Your Reading List?

Let's start with the part most comparison posts bury: Wallabag is a real, mature project. It's been around since the original "read-it-later, but you own it" wave, it's actively maintained, and it does something few other self-hosted tools attempt — it fetches and archives the full text of every page you save, not just the link. Tags, starred items, annotations, a browser extension (Wallabagger), mobile apps, a REST API, and public share links for individual articles. If you're already running it and it's working, this post isn't trying to talk you out of it.

What this post is for: you're weighing whether to keep running Wallabag yourself or move to something hosted, and you want the trade stated honestly — plus, if you do move, exactly what survives the trip.

What self-hosting Wallabag actually buys you

The same three things any self-hosted tool buys you, and they're real:

Nobody can take it away. No pricing change, no acquisition, no shutdown notice. We wrote a whole post about services that died — Pocket and Omnivore both went out this way. A container on your own disk doesn't end up on that list.

The data is already yours. Not "exportable" — sitting in a database you can query right now, with the full article text alongside it.

It's the same cost at any size. A hundred saved articles or a hundred thousand, it's the same VPS bill.

If any of those three is the thing you actually care about, that's a good reason to keep running Wallabag. Nothing below changes that calculus.

What it costs you

The honest list, and Wallabag's is a bit longer than a simple bookmark manager's:

  • It's heavier than it looks. Unlike a single-file SQLite tool, Wallabag wants a proper database (MySQL, PostgreSQL, or SQLite in a pinch) and a PHP runtime behind it. More moving parts than Linkding or Shaarli, which we covered in our self-hosted bookmark manager roundup.
  • It fetches arbitrary web content on your behalf, which is exactly the feature that makes it useful — and exactly the thing that means updates aren't optional. A content-fetching service is a bigger attack surface than a tool that just stores URLs.
  • The archive lives on your disk, once. Full-text archiving is Wallabag's best feature, and it's only as durable as your backup discipline. A drive failure with an untested restore takes years of archived articles with it.
  • Mobile and sharing get fiddly. Reaching your own instance from your phone means a domain, a certificate, and either an open port or a tunnel.
  • The upkeep is invisible until it isn't. Most weeks: zero minutes. The week a PHP or database major-version bump breaks the container: a Saturday.

None of that is a knock on Wallabag — it's the tax every self-hosted tool charges, and plenty of people are glad to pay it.

Where Cowpin is actually different

Not "better" — different, on the axes that matter for a reading habit:

Search that understands the question. Cowpin does full-text search across archived page content, semantic search, and "ask your library" — you ask a question in plain language and get answers pulled from what you've saved. Wallabag's search is keyword-based over the articles it's fetched.

Highlights and annotations, exported to where you actually think. Select text on a saved page, keep it, and export your highlights to Markdown, Obsidian, or Notion. Wallabag has annotations too, but they stay inside Wallabag.

Zero operations. No container, no database to patch, no renewal reminder. That's the entire pitch on this axis — it's either worth something to you or it isn't.

Cowpin also builds a full-text archive against link rot, has a browser extension, public profiles with RSS, and speaks the Pinboard-compatible API that a lot of older tools — Wallabag included — already know how to talk to.

The honest counterweight: Cowpin is hosted. That's the whole thing you'd be giving up, and it's exactly why the rest of this post is about making the move — in either direction — as low-risk as we can make it.

Exactly what survives a Wallabag → Cowpin migration

Wallabag's own Export → JSON — the same file it uses to migrate between two Wallabag instances — is what Cowpin's importer reads. Drop it into Settings → Import and it's detected automatically; you don't need to rename anything or pick a format. Here's the field-by-field reality, checked against Wallabag's actual export schema rather than guessed at:

WallabagComes over?Notes
URL and titleYesUses the URL you actually saved, not a resolved/tracking-stripped one
TagsYesMapped from each tag's label
Unread vs archivedYesArchived articles import as read; unread ones join your read-later queue
StarredYesComes over as starred
Original save dateYesA years-old library keeps its real dates, not today's
Full article text (Wallabag's archive)NoCowpin builds its own archive by fetching the page fresh after import
Highlights & annotationsNoNot read by the importer yet
Per-article public share linksNoCollapses to private or public per your Cowpin privacy defaults

That table exists because building it is what we do before writing one of these posts, not after. Wallabag's export is a JSON array shaped nothing like Pinboard's — different field names throughout (given_url and is_archived instead of href and toread) — and before this importer existed, that file would have been silently misread as a Pinboard export and imported as zero bookmarks. Same failure shape we found and fixed for Instapaper's CSV and Linkding's HTML export — a switcher's whole library looking empty is the worst possible first impression, so we built the real parser and tested it against Wallabag's actual field names before publishing this comparison.

About the archived text: Wallabag's export carries your bookmarks and metadata, not a portable copy of the full-text archive it built. That's true of most read-it-later tools — the archive is the thing that's hardest to move. Cowpin re-fetches each URL after import to build its own archive, so pages still online get captured fresh, and pages that have already rotted are gone either way.

And the way back out

Cowpin exports to Pinboard-format JSON — the same field names Pinboard itself uses — and Wallabag ships a built-in Pinboard importer. So the door genuinely swings both directions: you can move to Cowpin, decide later you'd rather self-host after all, export, and hand the file to Wallabag's importer. (We've verified the export carries the full field set — URL, tags, privacy, read state, and save date — against Wallabag's documented Pinboard format; if you hit an edge case on your specific Wallabag version, tell us and we'll fix it the same day we fixed the other three.)

A hosted tool that can't hand your data back is a trap. One that can is just a tool.

How to actually decide

Keep running Wallabag if: you want the archive on your own disk non-negotiably, you're already comfortable running a database and applying updates, or "no company can shut this down" outweighs everything else.

Try Cowpin if: you want the searching-and-asking layer, you want highlights that export somewhere useful, or the Wallabag instance you meant to set up has been a to-do list item for months.

Or run both. Keep Wallabag as your archive of record if you already have it, and use Cowpin for search and reading. The Pinboard round-trip in both directions makes that a real option, not a leap of faith.

If you want to try it: export from Wallabag (Export → JSON), drop the file into Cowpin's import, and your library — tags, read state, starred items and save dates intact — is there in about a minute. Cowpin is free while we're finding our first users, and you can export everything back out whenever you like.

Import your Wallabag library →