InformadoRSS

Mon, 01 Jan 0001 00:00:00 +0000

InformadoRSS es un servicio ligero y self-hosted que vigila feeds RSS y Atom, filtra sus elementos por ruta y los entrega a canales de Discord o a ntfy. Funciona en un único contenedor: un binario en C# con .NET 10 compilado con NativeAOT que sirve una interfaz web en Vue 3 y guarda todo en SQLite. Solo habla con Discord a través de la API REST del bot (sin gateway ni comandos). Es de código abierto con licencia MIT.

Características principales:

Feeds y rutas: Un feed es una URL; cada feed tiene rutas con un filtro, uno o varios destinos (Discord o ntfy) y una plantilla de mensaje.
Constructor de filtros y editor de plantillas: Crea los filtros y edita los mensajes desde la interfaz web en lugar de escribirlos a mano.
Selector de servidor y canal de Discord: Elige los destinos por nombre y comprueba en qué canales no puede publicar el bot.
Alertas: Un aviso cuando un feed o un destino se rompe y otro cuando se recupera, por Discord o ntfy.
Copias de seguridad diarias: Copias programadas de la base de datos en una carpeta, conservando las más recientes.
Importador de MonitoRSS: Importa feeds y rutas desde una exportación de MonitoRSS, con simulación y un canal de pruebas para comparar los mensajes antes de cambiar.
Patrón de identidad para feeds que reescriben entradas: Una expresión regular sobre la descripción que se añade al id del elemento, así un cambio de estado en una lista de MyAnimeList cuenta como elemento nuevo.

Cuento cómo y por qué lo hice en el post del blog. La imagen se publica en ghcr.io/christt105/informadorss.

InformadoRSS: sustituyendo MonitoRSS

Wed, 28 Oct 2026 00:00:00 +0100

¡Hola otra vez!

Tengo un par de servidores de Discord donde un bot avisa de las entradas nuevas de blogs, vídeos de YouTube, newsletters y de las listas de anime y manga de mis amigos. Durante años eso lo hizo MonitoRSS. Funciona, pero son nueve contenedores (varios servicios en Node, Mongo, Postgres, RabbitMQ…) y unos 670 MB de RAM para mirar cada diez minutos si hay algo nuevo en unos feeds. En un servidor casero que ya tiene Jellyfin y media docena de cosas más, me parecía una barbaridad, y como sabéis, el mundo no está para regalar RAM. Así que me hice el mío.

Qué es

InformadoRSS es un servicio autoalojado que mira feeds RSS y Atom, filtra los elementos y los manda a canales de Discord. Un contenedor, un archivo SQLite y una web que sirve el mismo binario. Es de código abierto (MIT):

christt105/InformadoRSS

Lightweight single-container RSS/Atom to Discord forwarder

0 0 2026-10-24

La idea es sencilla:

Un feed es una URL.
Una ruta dice qué hacer con un feed: un filtro, uno o varios destinos (un canal de Discord o ntfy) y una plantilla de mensaje.
La web tiene un constructor de filtros, un editor de plantillas y un selector de servidores y canales, para no tener que copiar ids a mano.
El bot habla con Discord solo por la API REST. Nada de gateway, ni comandos, ni webhooks. Así de simple.
Cuando un feed o un destino se rompe me manda un único mensaje privado por Discord, y otro cuando se recupera.

Por ejemplo, el feed de Media Tracker, donde sale lo que termino de ver o jugar, tiene cuatro rutas: en cada servidor las películas y series van a un canal y los videojuegos a otro. Cuando termino Tetris, la entrada pasa por las cuatro y solo llega a los canales que la aceptan:

flowchart LR
 I["Nueva entrada
en Media Tracker
Tetris · película"]
 I --> R1["Ruta 3
sin videojuegos"]
 I --> R2["Ruta 4
solo videojuegos"]
 I --> R3["Ruta 1
sin videojuegos"]
 I --> R4["Ruta 2
solo videojuegos"]
 R1 -->|"✔ pasa"| C1
 R2 -.-x|"✘ no pasa"| G1
 R3 -->|"✔ pasa"| C2
 R4 -.-x|"✘ no pasa"| G2
 subgraph Z["Discord · Los Zanahorios"]
 C1["#cine"]
 G1["#games"]
 end
 subgraph P["Discord · Los Panas"]
 C2["#animu-pelis-series"]
 G2["#gaming"]
 end

El stack

C# con .NET 10 compilado con NativeAOT, y un frontend en Vue 3 que acaba como archivos estáticos dentro del mismo binario. Elegí C# porque es lo que uso a diario, y por eso descarté Go y C++. Me daba curiosidad probar a hacer algo de este estilo con uno de esos lenguajes, pero al final C# es con el que me siento más cómodo leyendo. El almacenamiento es SQLite, con una copia de seguridad diaria a otro disco, aunque no sería mucha pérdida.

Así se ve por dentro:

flowchart TD
 F["Feeds RSS / Atom"] --> SRC
 YO["Navegador en la LAN"] --> WEB
 subgraph BIN["Un solo binario de C# · .NET 10 con NativeAOT"]
 WEB["Web en Vue 3"] <--> API["API"]
 API <--> DB[("SQLite")]
 SCH["Planificador"] <--> DB
 SCH --> SRC["Fuente
descarga y parsea"]
 SRC --> PIPE["Rutas
filtro y plantilla"]
 subgraph SK["Sinks"]
 DSC["Discord"]
 NT["ntfy"]
 NEXT["¿Telegram?"]
 end
 PIPE --> DSC
 PIPE --> NT
 PIPE -.-> NEXT
 end
 classDef futuro stroke-dasharray: 5 5
 class NEXT futuro

La idea es que todo sea modular. Cada destino es un sink, una clase que implementa una interfaz muy pequeña: un nombre y un método que entrega el mensaje. Ahora mismo hay dos, Discord y ntfy, y añadir otro, como Telegram, es escribir esa clase y registrarla, sin tocar el planificador ni los filtros; la web lo detecta sola y ya lo ofrece como destino. Con las fuentes pasa lo mismo: hoy solo hay RSS y Atom, pero están detrás de su propia interfaz.

Los números

Vamos a poner los números sobre la mesa y a comparar los dos servicios en momentos parecidos: en reposo, con los mismos feeds y mirando cada diez minutos. MonitoRSS ya lo he apagado por razones obvias, así que sus cifras son de antes del cambio.

	InformadoRSS	MonitoRSS
Contenedores	1	9
RAM	75 MiB	unos 670 MB
Imagen	37 MB	unos 3,9 GB sumadas
Datos en disco	4,5 MB	656 MB

Aunque los números son muy buenos, aún hay margen de mejora. En el primer experimento, sin feeds ni web, el binario AOT gastaba unos 10 MiB, y en producción son 75 MiB: el recolector de basura de .NET no tiene ninguna prisa por devolver memoria en una máquina con 15 GB libres. Si algún día me importa, puedo limitarle el heap. También escribe unos 50 MB al día en disco, casi todo logs demasiado detallados del cliente HTTP, que se arreglan bajando el nivel de log.

Hecho con Claude

Primero escribí el diseño en una nota de Obsidian (qué hace MonitoRSS, qué uso yo de verdad y qué puedo tirar) y luego lo partí en tareas. Claude ejecutó varias en paralelo en worktrees de git distintos, cada una con su pull request, y yo las revisaba y mergeaba por oleadas: almacenamiento, filtros y parser de feeds, luego el planificador y el envío a Discord, y por último el importador, las alertas, las copias de seguridad y la web. Creo que he encontrado un flujo de trabajo muy cómodo con la IA, puede que pronto escriba un post de cómo trabajo.

El cambio

Lo que daba miedo no era el código, era el cambio de uno a otro. Hice un importador que lee un mongoexport de MonitoRSS y crea los feeds y las rutas. La primera pasada mandaba todos los destinos a un canal de pruebas y enviaba el último elemento de cada feed, para comparar los mensajes uno al lado del otro. Cuando cuadró, paré los contenedores de MonitoRSS, apunté las 22 rutas a los canales de verdad y las marqué como vistas en silencio para que nadie se comiera una avalancha de entradas viejas. Si algo salía mal, un docker start y vuelve el stack antiguo. La verdad es que salió casi perfecto a la primera.

Cosas que me dieron guerra

Los feeds de YouTube devuelven 404 unas horas cada mañana. Es una caída global, no mi IP. Por eso un feed solo se considera roto tras seis horas seguidas fallando. No entiendo muy bien por qué le pasa esto a YouTube. Parece un error de hace algo de tiempo.
MyAnimeList reescribe las entradas en el sitio. El guid de cada entrada es la URL del anime y el estado vive en la descripción, así que pasar de Watching a Completed nunca se enviaba. En MonitoRSS pasaba igual. Ahora un feed puede tener un patrón de identidad, una expresión regular sobre la descripción que se añade al id del elemento, y cada estado cuenta como elemento nuevo. Igualmente es una mierda cómo MAL organiza el RSS (Ori no te lo digo más, mete RSS en tu app de tracking).
Elementos viejos tras una caída. Los elementos más antiguos que un máximo se marcan como vistos sin enviarse, y desde la web se puede enviar o resetear cualquiera a mano. Esto me suele pasar porque tardo varios días en escribir un post: me olvido de actualizar la fecha, aparece como publicado hace varios días y se pierde el envío.

Lo que falta

Es un servicio muy básico, tiene justo lo que necesito. MonitoRSS tiene mucha más personalización y puedes hacer más cosas, pero no lo necesito, y menos a cambio de gastar nueve veces más RAM.

Faltan cosas como los mensajes de Discord con Components V2, una vista previa del mensaje estilo Discord y un filtro de Shorts para YouTube. No tiene login: está pensado para una LAN de confianza.

Lo tengo montado bastante modular, así que puedo añadir otras fuentes u otros sinks, y si necesito alguna funcionalidad la puedo añadir fácilmente: no es un servicio muy complejo. De momento lo dejaré así, abierto para quien quiera usarlo o mejorarlo.

Si usas MonitoRSS y quieres algo más ligero, pruébalo y échale un vistazo.

¡Nos vemos en el siguiente!

Sqlite on Christian Martínez De La Rosa