Local-First Bookmark Managers Are Back. Here's Why

For about a decade, nobody worried about where their bookmarks lived. You saved a link, it went somewhere, and it was there when you came back. The cloud was assumed to be permanent, the way a public library is permanent. Then two of the most loved read-later apps on the internet shut down inside eight months of each other and took millions of libraries with them.

Now there is a whole category of bookmark tools whose main selling point is that they run on your own hardware. Self-hosted, Docker-composed, SQLite on a disk you can hold. The pitch is simple. Nobody can take this away from you.

I think the people building these tools are mostly right about the problem and slightly wrong about the fix. Local-first won the argument. It has not yet won the job.

What local-first actually means

The phrase is not marketing. It comes from a 2019 essay by the research lab Ink & Switch, and it is specific enough to argue with.

Local-first software keeps the primary copy of your data on your own device. The network is an enhancement, not a dependency. The original manifesto lays out seven ideals a local-first app should hit. Fast, because reads and writes never wait on a server. Multi-device, so your stuff follows you. Offline, meaning full function with the wifi off. Collaboration, so other people can still work with you. Longevity, meaning the software outlives the company. Privacy, because the data does not have to leave your machine. And user control, which is the right to take your data and go.

Seven ideals. Read that list again, because almost every conversation about local-first bookmarks only ever discusses three of them.

The idea has grown a real community around it. There is an annual Local-First Conference now, with Ink & Switch running a lab day. This is not a fringe position anymore. It is a movement with a conference and a manifesto and a lot of very good engineering behind it.

Why they are coming back

The revival has a cause, and the cause has dates.

Omnivore was an open-source read-later app with an unusually devoted following. In late October 2024 its team was acquihired by ElevenLabs. The product shut down on November 15, 2024, and the data-export window closed two weeks later after users complained. ElevenLabs wanted the engineers. The app was not the point.

Then Pocket. Mozilla bought it in 2017, invested less every year, closed new signups in May 2025, and shut the service down on July 8, 2025. Roughly 35 million people had been saving articles into it. The export window closed that November, and the remaining accounts were queued for deletion.

Two of the biggest names in saving things for later, gone in eight months. Neither died because the technology failed. They died because the business around them stopped making sense to somebody in a meeting.

That is the lesson people actually absorbed. Not “the cloud is unreliable.” The cloud was extremely reliable right up until the day it was switched off on purpose. What people absorbed is that your library’s lifespan is tied to a strategy document you will never read. So a generation of tools appeared with a different promise. Run it yourself. Karakeep is the one most people land on, a self-hostable bookmark-everything app with local LLM tagging and full-text search. Linkwarden sits next to it with better page archiving. Both are free if you run them, and both are genuinely excellent.

The instinct is correct. I want to push on the fix.

The ideals most local-first bookmark apps skip

Here is the scorecard nobody publishes. Take a typical self-hosted bookmark manager and grade it honestly against the seven ideals it is implicitly claiming.

Four straight wins. Those four are real and they are why the category deserves its comeback. But look at the bottom row, because that is where the argument gets uncomfortable.

The self-hosted graveyard nobody talks about

Longevity is the ideal everyone cites and nobody tests. “The software works in ten years even if the vendor is gone.” Fine. Does it work in ten years if you are gone? Not dead. Just busy.

Here is the take I will defend. A self-hosted bookmark manager you stopped patching, whose Docker image is three major versions behind, whose backup cron job silently broke in March, is not safer than Pocket was. It is a shutdown with extra steps. Pocket at least emailed you. Your unmaintained container will not.

Self-hosting does not delete the risk of losing your library. It transfers the risk from a company with a status page and a paid ops team to a person who has a day job. For a small number of people, that trade is clearly correct, and they know exactly who they are. They already run a NAS. They already have backups they have actually restored from, not just configured.

For everybody else, “I own the data” quietly means “I am now the single point of failure.” That is a real answer to the wrong question. The reason people lose bookmarks has never mostly been vendor shutdowns. It has been neglect, drift, and never being able to find the thing again.

The saves a local-first app cannot reach

There is a second gap, and it is bigger than the first.

Open your phone and think about where you actually save things now. You are not copying URLs into a self-hosted web app. You are tapping the bookmark icon on a post in X, hitting save on a Reddit thread, tapping save on a LinkedIn article. That is where modern saving happens, inside the platform, in one tap, twenty times a week.

Local-first bookmark managers cannot see any of it. There is no export button on your X bookmarks. Reddit will show you roughly your last thousand saves and no more. These saves are not even copies, they are pointers, so when the original post is deleted your bookmark quietly rots. A self-hosted app running perfectly on your own metal captures precisely none of this unless you paste every link in by hand, which you will do for a week.

So the sovereign, private, offline library you built contains the twelve links you were motivated enough to file manually. The four hundred things you actually saved are still trapped in three apps that do not care about them. That is the split between browser bookmarks and social bookmarks, and local-first only ever addresses the half that was already fine.

Escapable and machine-readable beat local and cloud

I think the local-versus-cloud axis is the wrong one to organize your choice around. Two other properties predict whether a library survives and stays useful, and they cut across both camps.

Escapable. Can you get everything out, today, in a format that another tool will read, without asking permission? Not “is there an export feature buried in settings.” Have you run it? A cloud app with a one-click complete export is more escapable than a self-hosted app whose data sits in a schema only it understands. Pocket’s failure was not that it was cloud. It was that 35 million people had never tested the exit.

Machine-readable. Can something other than the app’s own search box read your library? For the last twenty years this did not matter much. It matters enormously now, because the thing you most want to do with a decade of saved links is ask an AI about them. A library your agent cannot reach is an archive, not a tool. This is what MCP exists to solve, a standard way for an AI agent to read a data source directly.

Grade your current setup on those two and the answer is usually more interesting than its hosting model. A private SQLite file nothing can read is sovereignty with nothing to show for it. You own it completely and it does nothing for you.

Where ContextBolt sits, honestly

I build a bookmark tool, so let me be straight rather than clever about this.

ContextBolt is not local-first. Pro syncs your saves to encrypted cloud storage. If you want the seven ideals in full, run Karakeep. I mean that. It is a good piece of software and the people building it are serious.

ContextBolt optimizes for the two gaps above instead. It captures automatically from X, Reddit, and LinkedIn, which is where saving actually happens and which no local-first tool reaches. AI tags every save with a topic so you can find things by meaning rather than remembering a keyword. And Pro ($6/month) gives your library a personal MCP endpoint, so Claude, Cursor, and Windsurf can query your saves mid-conversation. The free Basic tier holds 150 bookmarks with the same AI tagging, clustering, and semantic search.

That is a trade, and I would rather name it than pretend it away. You are trusting a hosted service, in exchange for capture that reaches the platforms and retrieval an agent can use. If vendor independence is the thing you care about most in the world, this is the wrong tool and you should not buy it.

What I would push back on is the idea that self-hosting settles the question. It answers one risk, loudly, and leaves the other two untouched. The library still has to be findable, and it still has to be readable by the machine you now ask everything.

How to choose

Pick by what actually worries you.

If you are worried about a company deleting your library, and you genuinely maintain your own infrastructure, self-host. Karakeep or Linkwarden. You will get four of the seven ideals at full strength and you will keep them as long as you keep patching.

If you are worried about never finding anything again, hosting is not your problem. Retrieval is. Solve that first, and then insist on a complete export you have personally tested, so you can leave whenever you like.

And if you are worried about both, the honest answer is that no tool clears all seven ideals today for social saves, because the platforms will not let one exist. What you can demand right now is a library you can walk out of, and one your AI can read while you stay. Local-first got the diagnosis right. The prescription is still being written.