Bookshelf, librería self-hosted de ebooks en R2 o Node

Bookshelf, la librería de ebooks que cabe en un bucket de R2

El repositorio público murerkinn/bookshelf en GitHub — 5 estrellas y 0 forks al cierre de esta nota — publicó Bookshelf, una librería de ebooks self-hosted con una idea tan simple como efectiva: una sola página renderizada en el servidor que lista los libros, los filtra con un buscador, los sirve como descarga y los lee en el navegador, sin base de datos detrás.

Lo llamativo no es la idea en abstracto — Calibre-Web, Kavita, Komga y BookLore ya hacen algo parecido, según el repaso de It's FOSS — sino dónde corre: como un Cloudflare Worker sobre R2, o como un servidor Node sobre un directorio del disco. No hay Postgres ni SQLite: el "estado" son los propios archivos en object storage y las cookies del navegador.

Qué hace exactamente

El repo documenta un caso de uso muy concreto: subir EPUB y PDF propios, y leerlos desde cualquier dispositivo. Cada formato tiene su propio lector integrado en la página. Las portadas se generan con cwebp y pdftoppm (incluidos en la imagen Docker).

👥 ¿Quieres ir más allá de la noticia?

En nuestra comunidad discutimos las tendencias, compartimos oportunidades y nos ayudamos entre emprendedores. Sin humo, solo acción.

👥 Unirme a la comunidad

El comando de inicio es deliberadamente corto:

git clone, npm install.
docker compose run --rm sync --create para construir la librería.
docker compose up -d para servirla en http://localhost:3000.

El volumen que importa es uno solo — library — y guarda los libros publicados más los perfiles y las posiciones de lectura. El README es explícito: ese volumen es lo único que hay que respaldar. Apagar la instancia y desplegar en otro lado es clonar el repo y montar el mismo volumen.

Cómo se publica en Cloudflare

El modo "Cloudflare" usa npx wrangler login, dos archivos de configuración que el repo lleva checked-in (el nombre del bucket y el nombre del Worker, ambos pensados para editarse), y dos comandos:

npm run sync -- --create crea el bucket y sube la librería.
npm run deploy compila y despliega el Worker.

La propia herramienta de sync compara los dos archivos antes de subir nada y aborta si el bucket declarado no coincide con el del Worker, para no servir una estantería vacía.

El modo "filesystem" apunta bookshelf.config.json a un directorio local (shelf-data) y corre como un Node server. Sin cuenta en ninguna nube.

Lectura en el navegador, perfiles y modo público

El lector vive dentro de la app: cargar un EPUB o un PDF abre su visor inline. Los perfiles son la única forma de separar quién lee qué — un perfil por compañero de casa, uno por dispositivo, lo que sea — y guardan la posición de lectura en el propio bucket cuando el proveedor puede escribir; si no, caen al localStorage del navegador.

Para una instancia expuesta a desconocidos existe la variable BOOKSHELF_READ_ONLY=1. La storage sigue sirviendo pero deja de aceptar escrituras: no se pueden crear, renombrar ni borrar perfiles, y las posiciones de lectura vuelven al navegador. La regla se aplica donde se escribe, no escondiendo formularios — postear directo a la acción da el mismo rechazo.

El README avisa dos cosas: no hay autenticación (cualquiera con la URL lee y descarga todo, y puede elegir cualquier perfil), y dos dispositivos en el mismo perfil al mismo tiempo se pisan por last-write-wins.

Cuánto cuesta correrlo sobre R2

La pieza interesante para founders es el precio del lado Cloudflare. Según la página oficial de pricing de Cloudflare R2 (actualizada al 7 de agosto de 2026), el modelo es:

Storage Standard: US$0,015 por GB-mes.
Class A operations (escrituras, listados): US$4,50 por millón.
Class B operations (lecturas, GETs): US$0,36 por millón.
Egress: gratis en cualquier clase.

El free tier mensual incluye 10 GB-mes de storage, 1 millón de Class A y 10 millones de Class B, con egress siempre gratis. Para una biblioteca personal de EPUB (un libro de 500 KB a 2 MB típicamente), el techo del free tier cubre varios miles de libros sin pagar nada.

El análisis de Filebase ilustra el contraste con AWS S3: en un escenario con 1 TB almacenado y 10 TB descargados al mes, R2 ronda los US$23,10, mientras que la línea de data transfer out de S3 (a US$0,09/GB) suma unos US$900 por sí sola. La diferencia no es magia — es que la línea de egress desaparece.

Comparativa con el resto del ecosistema self-hosted

El repaso de It's FOSS sobre servidores de ebooks enumera las alternativas más maduras:

Calibre + Calibre-Web — Calibre existe desde 2006, soporte para más de 50 formatos (incluye audiolibros), conversión entre formatos, envío a e-readers, sincronización con Kobo, extensibilidad por plugins. Es el "one-stop" estable, pero la interfaz se siente antigua.
Kavita — orientada a comics y manga, UI moderna con temas y modo oscuro, lector online muy configurable (webtoon, doble página, anotaciones).
Komga — servidor Java para comics y manga, con organización por series y volúmenes, y OPDS feeds.
BookLore — el "Jellyfin de los libros": UI tipo estanterías, OPDS, sincronización con Kobo, pensado para familias.
Ubooquity, pyShelf, Atsumeru — más ligeros, pensados para hardware modesto o casos simples.

Lo que Bookshelf no intenta ser: no reemplaza Calibre en catálogo y metadata. No hay OPDS, no hay plugins, no hay sincronización con Kobo, no hay decenas de formatos. Si tu problema es administrar 20.000 libros con autores, series y ratings, vas a querer Calibre-Web o BookLore. Si tu problema es "tengo 300 EPUBs y PDFs en una carpeta y quiero leerlos desde el celular en cualquier red", Bookshelf entra en una línea de costo operativo.

Qué significa esto para tu startup

Más allá de los ebooks, Bookshelf es un patrón de arquitectura que cualquier founder debería mirar dos veces: producto entero, UI incluida, sobre un bucket de R2 + un Worker de Cloudflare, sin base de datos.

Dos acciones concretas que podés implementar esta semana

Probar el patrón en un side project real. Cloná el repo, apuntálo a un bucket R2 vacío y cargá una decena de archivos. Vas a ver de primera mano el costo de servir assets estáticos y media sin pagar egress — útil para decidir si tu próximo SaaS (que probablemente tiene uploads y descargas) tiene que pagar S3 o puede vivir en R2.
Auditar qué partes de tu producto podrían correr en R2 sin base de datos. Archivos generados por usuarios (exports, reportes, PDFs, respaldos) muchas veces no necesitan query SQL: necesitan URL firmada y download. Mover eso a R2 te borra una base de datos del diagrama y un cargo fijo del presupuesto.