Readeck
Codeberg-hosted (1.2k★, AGPL-3.0, Go, single binary or container): a self-hosted bookmark manager + read-later tool whose design center is long-term archival: “will this article be online next year? In 10 years? Maybe not — for this reason text and images are all stored in your instance the moment you save a link.” Notably privacy-strict: “with the exception of videos, not a single request is made from your browser to an external website.”
Features: readable-content extraction (adapts for pictures/videos), labels/favorites/archives, highlights and annotations, collections (saved searches), EPUB export (single article or whole collection) + OPDS catalog for e-readers, full-text search, browser extension (FF/Chrome), smartphone apps with sync. “A modern take on so-called boring, but proven, technology pieces.”
vs karakeep (OSS) — the comparison (asked at capture, 2026-10-16)
Both AGPL-3.0 self-hosted bookmark apps, but they optimize different things:
| Readeck (Codeberg, 1.2k★) | Karakeep (GitHub, 29k★, ex-Hoarder) | |
|---|---|---|
| Center | Read-later + archival fidelity | Data-hoarding + AI enrichment |
| Content model | readable-article extraction, stored verbatim at save time | links + notes + images + PDFs, auto-fetched metadata |
| AI | none — deliberately boring | LLM auto-tagging/summarization, semantic search, ollama-local support |
| Agent surface | full OpenAPI 3 REST API (Bearer auth, OAuth2 device flow) — no MCP/CLI yet | official CLI + agentic skills (“OpenClaw, Hermes friendly”) |
| Reading | EPUB export + OPDS e-reader catalog (unique) | web-first |
| Annotations | native highlights | highlights in newer versions |
| Deployment | single Go binary or container, SQLite | container, heavier stack (TS, Chrome for screenshots, ML extras) |
| Governance | Codeberg/federation-friendly | GitHub + Weblate |
The honest split: Readeck for the reading lane (e-reader integration via OPDS/EPUB is unmatched, archival-first storage, minimal footprint, zero external requests) vs karakeep for the agent lane (CLI + official skills = the CLIs for agents story, semantic search, AI tagging; the vault’s own capture ETL philosophy favors this direction). For the homelab: karakeep already sits in the services candidate list — Readeck doesn’t displace it, but its OPDS+EPUB trick is the piece worth stealing if e-reader reading ever becomes a requirement.
(Comparison grounded in both READMEs at capture time; both are captured.)
The API (verified from source, 2026-10-16)
Yes — a full OpenAPI 3.0 spec ships in-tree (docs/api/api.yaml), and it’s substantial, not a stub. Bearer-token auth plus OAuth2 with device flow (/oauth/token, /oauth/device, /oauth/client, /oauth/revoke). Endpoints from the route files:
- Bookmarks: CRUD (
/bookmarks,/bookmarks/{id}), labels, annotations (full annotation CRUD — highlights via API),/bookmarks/{id}/article.{format}withepubandmdexport (the e-reader trick is scriptable), share links/email - Collections: CRUD
- Import: browser, CSV, GoodLinks, Linkwarden, Pinboard, Pocket, Readwise, wallabag — the migration path from every competitor
/bookmarks/sync(the phone-app sync protocol) and the interesting one:/cookbook/extract+/cookbook/urls— Readeck’s readable-content extractor callable on arbitrary URLs, extraction-as-a-service/info,/profile
So the comparison’s “no agent surface” softens to: the REST substrate is fully there (extract API + EPUB export + annotation CRUD), it’s just missing the CLI/MCP packaging karakeep ships. A thin skills wrapper over /cookbook/extract would make Readeck a capture-side tool for agents.