Radarr, Sonarr y Prowlarr con Docker Compose

Radarr, Sonarr y Prowlarr con Docker Compose

Radarr, Sonarr y Prowlarr con Docker Compose

Guía paso a paso para montar Radarr, Sonarr y Prowlarr en Docker Compose usando las imágenes de linuxserver.io. Prowlarr centraliza la gestión de indexadores y los sincroniza automáticamente con el resto del stack.

Por Javier · Actualizado: 2025-07-13

Radarr, Sonarr y Prowlarr son tres servicios que, combinados en un stack Docker Compose, automatizan la monitorización y descarga de películas y series: Prowlarr centraliza los indexadores y los sincroniza vía API con Radarr (puerto 7878) y Sonarr (puerto 8989), eliminando configuración duplicada. La legalidad depende del país y del contenido indexado.

Para quien ya tiene Docker y quiere automatizar

Si ya tienes Docker corriendo en tu máquina o en tu servidor y llevas un tiempo pensando en montar algo para gestionar descargas automáticamente, probablemente te has topado con nombres como Radarr, Sonarr o Prowlarr y no has tenido claro por dónde empezar. Son tres apps distintas, cada una con su interfaz, su API key y sus puertos. En papel parece mucho lío.

La realidad es que el stack funciona de forma bastante coherente una vez entiendes para qué sirve cada pieza: Radarr gestiona películas, Sonarr gestiona series y Prowlarr hace de puente con los indexadores para que no tengas que configurarlos dos veces. El Docker Compose une todo esto con unas pocas líneas y, si cuidas los paths de los volúmenes desde el principio, el setup se mantiene solo.

En este post te explico cómo montar el stack completo desde cero: el compose.yml, las variables de entorno que no puedes saltarte, y la integración entre las tres apps para que empiecen a hablar entre sí. Sin atajos que luego rompen cosas.

Por qué importa

Un indexador para todos

Prowlarr sincroniza vía API con Radarr y Sonarr: configuras los indexadores una sola vez y ambas apps los heredan automáticamente.

Permisos sin fricción

Las imágenes linuxserver.io usan PUID y PGID para correr con tu usuario del host, sin errores de permisos en los volúmenes.

Tres puertos, tres UIs

Radarr en 7878, Sonarr en 8989, Prowlarr en 9696. Cada servicio accesible por separado desde el primer arranque.

Paths coherentes o espacio duplicado

El directorio de descargas debe tener el mismo path en el cliente torrent y en Radarr/Sonarr; si difieren, el hardlink falla y ocupas el doble.

Lo que necesitas antes de arrancar

El stack arr no requiere hardware potente: un mini PC con 4 GB de RAM y un procesador moderno va sobrado. Lo tengo corriendo en Proxmox sobre un N100 y el consumo de CPU en reposo es prácticamente cero.

Lo que sí necesitas tener claro antes de empezar:

  • Docker y Docker Compose instalados en el host.
  • Un cliente de descarga ya funcionando: qBittorrent, Transmission, Deluge o NZBGet/SABnzbd para Usenet. Este tutorial asume que ya tienes uno corriendo.
  • Una estructura de carpetas pensada: una para descargas en curso y otra para la biblioteca final. Anótatla antes de tocar nada.

Sobre la legalidad: los indexadores de torrents varían mucho en qué contenido indexan y la situación legal depende de tu jurisdicción. Esto es una guía técnica del stack; lo que busques y descargues es tu responsabilidad.

El docker-compose.yml del stack completo

Las imágenes de linuxserver.io son el estándar de facto para este tipo de servicios. Mantienen builds para amd64 y arm64, actualizan rápido tras cada release upstream, y usan PUID/PGID para que el proceso interno corra con tu usuario de host y no tengas líos de permisos en los volúmenes.

Este es el compose de partida:

version: "3.8"

services:
  prowlarr:
    image: lscr.io/linuxserver/prowlarr:latest
    container_name: prowlarr
    environment:
      - PUID=1000
      - PGID=1000
      - TZ=Europe/Madrid
    volumes:
      - ./prowlarr/config:/config
    ports:
      - 9696:9696
    restart: unless-stopped

  radarr:
    image: lscr.io/linuxserver/radarr:latest
    container_name: radarr
    environment:
      - PUID=1000
      - PGID=1000
      - TZ=Europe/Madrid
    volumes:
      - ./radarr/config:/config
      - /datos/peliculas:/movies
      - /datos/descargas:/downloads
    ports:
      - 7878:7878
    restart: unless-stopped

  sonarr:
    image: lscr.io/linuxserver/sonarr:latest
    container_name: sonarr
    environment:
      - PUID=1000
      - PGID=1000
      - TZ=Europe/Madrid
    volumes:
      - ./sonarr/config:/config
      - /datos/series:/tv
      - /datos/descargas:/downloads
    ports:
      - 8989:8989
    restart: unless-stopped

Ajusta PUID y PGID al UID/GID de tu usuario con id tu_usuario en la terminal. Los paths de volúmenes de descargas tienen un detalle crítico que explico más abajo; no los ignores.

Primer arranque y configuración inicial

Con el compose en su sitio, levanta el stack:

docker compose up -d

Las tres apps tardan un par de minutos en inicializar su base de datos la primera vez. Después accedes a cada una por su puerto:

  • Prowlarr: http://tu-ip:9696
  • Radarr: http://tu-ip:7878
  • Sonarr: http://tu-ip:8989

Lo primero en cada app: ve a Settings → General y copia la API Key. La necesitas para el paso de integración con Prowlarr.

Configura la carpeta raíz en Radarr y Sonarr

En Radarr: Settings → Media Management → Root Folders. Añade la ruta tal como la ve el contenedor: /movies en el ejemplo de arriba. Lo mismo en Sonarr con /tv.

Sin esto, cuando Radarr intente mover un archivo descargado a la biblioteca no sabrá a dónde llevarlo y el proceso se queda colgado.

Conectar Prowlarr con Radarr y Sonarr

Aquí está la parte que hace interesante el stack: configuras los indexadores una sola vez en Prowlarr, y él los empuja automáticamente a Radarr y Sonarr vía API. Sin duplicar configuración, sin mantener dos listas separadas.

  1. En Prowlarr: Settings → Apps → Add Application.
  2. Selecciona Radarr. En Prowlarr Server pon la URL interna Docker: http://prowlarr:9696. En Radarr Server: http://radarr:7878.
  3. Pega la API key de Radarr y pulsa Test.
  4. Repite para Sonarr con server http://sonarr:8989 y su API key.

Clave: usa los nombres de servicio del compose como hostname, no localhost. Docker resuelve esos nombres internamente entre contenedores de la misma red. Con localhost el contenedor se apunta a sí mismo y la conexión falla sin un error especialmente claro.

Añadir indexadores en Prowlarr

Ve a Indexers → Add Indexer y añade los que necesites. Una vez guardados, Prowlarr hace push automático hacia Radarr y Sonarr en formato Torznab (torrents) o Newznab (Usenet). Si abres Settings → Indexers en Radarr verás que el indexador ya está ahí sin haber hecho nada más.

Un aviso: Prowlarr cubre la mayoría de casos pero no reemplaza completamente a Jackett en todos los escenarios. Algunos indexadores privados o con implementaciones específicas tienen mejor soporte en Jackett; comprueba caso a caso si estás migrando desde allí.

El error que más duele: paths inconsistentes

Aquí se rompe la mayoría de setups. Lo peor es que puede fallar silenciosamente o hacer algo peor que fallar: copiar el archivo entero en vez de enlazarlo, duplicando el espacio en disco sin que te enteres.

El principio es simple: el directorio de descargas debe ser el mismo path visto tanto desde el cliente de descarga como desde Radarr y Sonarr. Si qBittorrent escribe en /downloads dentro de su contenedor, Radarr también debe ver ese mismo directorio del host mapeado en /downloads.

El hardlink que usa Radarr para mover archivos sin copiarlos solo funciona dentro del mismo filesystem. Si el cliente de descarga y Radarr tienen bind mounts diferentes apuntando a rutas distintas del host, el kernel los trata como filesystems separados y copia en vez de enlazar.

La estructura que funciona: montar un directorio raíz común en todos los contenedores implicados.

# En el cliente de descarga, Radarr y Sonarr:
volumes:
  - /datos:/datos

Dentro de /datos organizas las subcarpetas: descargas/, peliculas/, series/. Los hardlinks funcionan dentro del mismo mount point y no duplicas nada.

Actualizaciones y mantenimiento

Actualizar el stack son dos comandos:

docker compose pull
docker compose up -d

Los contenedores que ya estaban en la imagen más reciente no se reinician. Los que tienen imagen nueva sí. El tiempo total suele ser menos de un minuto por servicio.

Puedes delegar esto a Watchtower para automatizarlo, aunque así pierdes visibilidad sobre qué versión entra. Personalmente prefiero hacerlo a mano un par de veces al mes y revisar el changelog si hay algo importante.

Backups de la configuración

Toda la configuración de cada app vive en sus carpetas de config: ./radarr/config, ./sonarr/config y ./prowlarr/config. Un tar periódico de esas carpetas es suficiente para restaurar el setup completo, incluidos indexadores, conexiones, API keys e historial de descargas.

Radarr y Sonarr también incluyen backup integrado en System → Backup, en formato SQLite comprimido importable desde cualquier instalación limpia. Úsalo antes de actualizar si quieres tener una red de seguridad.

Preguntas frecuentes

Q: ¿Necesito configurar los indexadores en cada app por separado?

A: Con Prowlarr no. Se configura una sola vez en Prowlarr y se sincroniza automáticamente con Radarr y Sonarr via API usando la URL interna de Docker y la API key de cada app. Ahorra bastante tiempo si tienes varios indexadores.

Q: ¿Qué pasa si las rutas de descarga no coinciden entre servicios?

A: El hardlinking falla y los archivos se duplican en disco, ocupando el doble de espacio. El directorio de descargas debe ser exactamente el mismo path en el host tanto para el cliente de descarga (qBittorrent, Transmission...) como para Radarr y Sonarr.

Q: ¿Vale Prowlarr para reemplazar Jackett completamente?

A: En la mayoría de casos sí, pero no siempre. Algunos indexadores tienen soporte solo en Jackett y no en Prowlarr. Conviene verificar caso a caso antes de migrar, especialmente si usas indexadores privados o más nicho.

Q: ¿Cómo evito problemas de permisos en los volúmenes Docker?

A: Las imágenes de linuxserver.io usan las variables PUID y PGID en el docker-compose.yml. Ponlas con el UID y GID de tu usuario del host (normalmente 1000:1000) y los archivos escritos por el contenedor tendrán los permisos correctos desde el principio.

Q: ¿Por qué puertos accedo a cada app del stack?

A: Cada app tiene su puerto por defecto: Radarr en el 7878, Sonarr en el 8989 y Prowlarr en el 9696. Se pueden remap en el docker-compose.yml si ya tienes algo corriendo en esos puertos.

Deja una respuesta

Tu dirección de correo electrónico no será publicada. Los campos obligatorios están marcados con *