751 - Las 12 dudas más habituales sobre Self-Hosting

751 - Las 12 dudas más habituales sobre Self-Hosting

Las 12 claves del Self-Hosting 2025. Respuestas sobre Docker, Traefik, Jellyfin, seguridad y backups. Guía esencial para tu servidor Linux.

1:25
-3:15

Hace unos días publicaron los resultados de una encuesta sobre Self-Hosting, autoalojamiento o autohospedaje de las que aproximadamente se recibieron unas 4000 respuestas completas, y me resultó realmente interesante, y por esta razón decidí compartirla. Pero, en lugar de simplemente comentar los resultados, me he enfocado mas en responder las 10 dudas más habituales que suelen surgir cuando alguien se plantea hacer self-hosting.

Las preguntas mas habituales, son las que a lo largo de estos años, he ido escuchando, leyendo y viendo en foros, grupos de Telegram, Discord, etc. Mientras que la respuesta viene de la propia encuesta matizada y comentada a partir de mi propia experiencia. Y es que si bien, lo que hace la mayoría puede que no sea lo mejor, si que es cierto que puede ser un buen punto de partida para alguien que se inicia en este mundillo.

Las 12 dudas más habituales sobre Self-Hosting

Estado del Self-Hosting en 2025

Hay algunas cuestiones que me han llamado especialmente la atención en los resultados de la encuesta, y que si bien, era algo que me imaginaba, lo cierto es que no tenía soporte para pensar que eso sería así.

Así, por ejemplo, la gran mayoría de los encuestados, mas del 80% hacen self-hosting de forma personal, mientras que la mayoría del resto lo hace de forma personal y profesional, y unos poquitos solo profesional.

Por otro lado, en cuanto al número de usuario de un chisme, el 28 % lo hace en solitario, y un 21 % con un acompañante, y en el caso de 3 llegamos a un 13 %. Todo esto indica que en la mayoría de los casos, el self-hosting es algo que se hace para uno mismo y su entorno mas cercano.

Y en cuanto a la razón para hacer self-hosting la inmensa mayoría lo hace por hobby y en una proporción similar por privacidad, seguido por la cuestión económica. Muy pocos lo hacen por necesidad o por cuestiones profesionales.

⚙️ ¿Qué hardware se utiliza para hacer self-hosting?

La encuesta muestra claramente que la gente se decanta por lo práctico, barato y de bajo consumo.

  • La mayoría de los self-hosters optan por dispositivos de bajo consumo como la Raspberry Pi o por hardware de consumo reutilizado. Esto se debe al coste inicial y operativo reducido.
  • Los dispositivos NAS preconfigurados (como Synology o TrueNAS) también son muy populares, especialmente entre quienes se autoalojan principalmente para hacer streaming multimedia. Es una solución llave en mano.
  • El uso de un Cloud VPS se mantiene como una opción, aunque está por detrás de las soluciones físicas domésticas.

Yo siempre digo que el mejor hardware es el que tienes en casa y te permite hacer lo que quieres. La encuesta valida esto: no necesitas un servidor de centro de datos para empezar.

  • La Raspberry Pi es la reina del inicio y la domótica: Su popularidad no es casualidad. Para servicios ligeros como Home Assistant, Pi-hole, o montar un nodo de Syncthing, la Pi es imbatible en cuanto a coste/vatio. Es la puerta de entrada perfecta para el ecosistema Linux.
  • El poder de x86 para Docker y BBDD: Aunque la Pi es genial, mi experiencia me dice que, si empiezas a meterle caña con contenedores Docker complejos, bases de datos demandantes o transcodificación de vídeo (Jellyfin/Plex), vas a necesitar un procesador x86 más potente. La reutilización de un mini-PC de bajo consumo o un NUC con Linux sigue siendo una opción fantástica para tener más músculo sin disparar la factura de la luz.
  • No olvidemos el VPS: Yo prefiero el VPS por comodidad, lo que no quita que tenga parte de mi self-hosting en casa, soy un firme defensor del VPS para todo lo que deba ser accesible 24/7 de forma fiable, como mi servidor web o mi proxy inverso Traefik. La encuesta lo sitúa más abajo, pero para mí, es la mejor solución para sacar servicios al exterior.

En resumen: Aunque en otro momento te diría que empezaras con una Raspberry Pi, a día de hoy te digo que empieces con un Mini-PC, salvo que tengas una Rasbperry en un cajón, y usa un VPS si quieres publicar tus servicios de forma fiable.

🐧 ¿Que sistema operativo utilizo?

Los datos son contundentes y reflejan que la encuesta de self-hosting está firmemente anclada en el software libre y la especialización:

  • Linux y las distribuciones basadas en Linux son, con diferencia, las más populares.
  • Además del Linux puro, hay una alta popularidad de los sistemas operativos específicos para plataformas de self-hosting o virtualización, como Proxmox, Home Assistant OS, Raspberry Pi OS, TrueNAS y Unraid.

Esto significa que la gente no solo usa Linux, sino que también utiliza sistemas operativos ad hoc diseñados para gestionar almacenamiento, virtualización o domótica de manera eficiente.

Para mí, la supremacía de Linux es obvia. Es el corazón del self-hosting.

  • Linux es la navaja suiza: La razón de la popularidad de Linux es su flexibilidad y eficiencia. Para mí, una distribución headless (sin e Debian o Ubuntu Server es la base perfecta para alojar servicios, especialmente si vas a usar Docker. Es ligero y tienes control total, que es lo que buscamos.
  • La especialización manda (Proxmox, TrueNAS, etc.): El alto uso de Proxmox y Unraid me dice que la gente está priorizando la gestión fácil de máquinas virtuales (VMs) y contenedores (LXC), así como el almacenamiento (ZFS, RAID). Si quieres tener varias máquinas virtuales con diferentes sistemas operativos o gestionar grandes cantidades de datos de forma segura, estos sistemas especializados son la mejor opción, porque simplifican tareas que en Linux puro pueden ser complejas.
  • Windows es testimonial: Es importante notar que Windows Desktop o Server aparecen muy abajo. Esto confirma que si buscas optimizar recursos, seguridad y compatibilidad con el software de código abierto que solemos usar (Traefik, Syncthing, Nextcloud), Linux es el camino a seguir.

Mi recomendación personal, que coincide con la tendencia: Usa una distribución Linux pura (como Ubuntu o Debian) para servicios en Docker, o un sistema operativo especializado como Proxmox o Unraid si necesitas virtualización o gestión avanzada de almacenamiento.

🌐 ¿Necesito un dominio para hacer self-hosting?

Aquí, los datos aquí son muy claros,

  • El 88% de los encuestados utiliza un dominio personalizado para acceder a sus servicios, ya sea de forma interna (dentro de la red local) o externa.
  • El registrador de dominios más popular con diferencia es Cloudflare.

La abrumadora mayoría indica que los self-hosters consideran que un dominio es esencial para acceder a sus aplicaciones de forma cómoda.

Mi respuesta es un rotundo sí, lo necesitas si quieres evitar frustraciones y usar tecnologías modernas de la forma más eficiente.

  • Comodidad y Usabilidad: Olvidarte de memorizar direcciones IP y puertos es lo más importante. Escribir miservicio.miweb.es es infinitamente mejor que 192.168.1.100:8080. Un dominio te da una URL limpia y profesional para cada servicio.
  • El SSL es imprescindible: Esto es lo más crítico. Para usar tecnologías modernas y, sobre todo, para tener seguridad, necesitas certificados SSL/TLS (HTTPS). Es decir, el candadito verde. Esto es imposible de conseguir fácilmente sin un dominio. Plataformas como Traefik, que me gusta mucho, dependen de un dominio para emitir certificados Let’s Encrypt automáticamente. Si no tienes dominio, no tienes HTTPS, y sin HTTPS, muchos navegadores o APIs te darán problemas.
  • Cloudflare y el Proxy Inverso: La popularidad de Cloudflare no es casualidad. Yo lo uso muchísimo. Me permite apuntar mi dominio, gestionar DNS de forma sencilla y, lo más importante, me ayuda a ocultar mi IP real o a usar sus servicios de túnel (como Cloudflare Tunnels), lo que simplifica el acceso remoto sin tener que abrir puertos en el router de casa.

En resumen: Técnicamente puedes autoalojarte sin dominio, pero si quieres seguridad (HTTPS), facilidad de acceso remoto (VPN, Traefik, Tunnels) y una buena experiencia de usuario, un dominio es un requisito fundamental.

🐳 ¿Como instalo los servicios?

Casi todos los encuestados implementan contenedores de alguna forma.

  • Existe una fuerte preferencia por los despliegues en contenedores frente a la instalación directa en el sistema operativo base (Bare Metal).
  • Docker y LXC son, con diferencia, los métodos más comunes para la contenerización.

En esencia, la encuesta ha abrazado Docker (o tecnologías similares) como la forma estándar de empaquetar y ejecutar aplicaciones.

Para mí, si quieres hacer self-hosting de forma moderna y eficiente, tienes que pensar en contenedores. Yo lo he dicho muchas veces: Docker o Podman es la herramienta fundamental en el ecosistema de Linux y el self-hosting.

  • Aislamiento y Limpieza: La gran ventaja del contenedor es que aísla la aplicación de mi sistema operativo base. Si algo falla en el servicio (una dependencia, una configuración), solo afecta al contenedor. Esto mantiene mi sistema Linux limpio y estable.
  • Portabilidad y Escalabilidad: Un compose de Docker que yo uso en mi Raspberry Pi puedo moverlo mañana a un VPS o a un PC más potente con un par de comandos. La portabilidad que da Docker es inigualable y simplifica enormemente las copias de seguridad y las migraciones.
  • Docker vs. LXC: La encuesta menciona ambos. Yo me decanto más por Docker para aplicaciones (Nextcloud, Traefik, Jellyfin) por su ligereza y facilidad. Pero si utilizas algo como Proxmox, los contenedores LXC son fantásticos porque se parecen más a una máquina virtual ligera, ideal si necesitas un entorno aislado con un sistema operativo completo para hacer pruebas.

Mi recomendación es clara: Olvídate de compilar o instalar directamente en la máquina anfitriona. Aprende Docker (o Podman) y despliega la inmensa mayoría de tus servicios con un docker-compose.yml. Es la forma más limpia, segura y moderna de hacer self-hosting.

🛠️ ¿Que software utilizo para gestionar los contenedores?

A pesar de que hay gente que gestiona los contenedores solo por línea de comandos, entre los que yo mismo me encuentro, una gran parte de los self-hosters utiliza software externo para simplificar el proceso.

  • Más de la mitad de los encuestados que usan contenedores emplean software de gestión externa.
  • El 82% de estos usuarios se concentra en solo tres plataformas principales: Portainer, Dockge y Komodo.

Esto demuestra que, si bien la línea de comandos es poderosa, una interfaz gráfica (GUI) para la gestión de contenedores es tremendamente popular para la eficiencia diaria.

En mi podcast, siempre he promovido la automatización y la eficiencia. Si bien yo hago muchas cosas desde la terminal con docker compose, entiendo y respaldo totalmente la popularidad de estas herramientas.

  • Portainer sigue siendo el estándar, pero hay competencia: Portainer ha sido el líder histórico y sigue siendo muy fuerte por su madurez y por su capacidad de manejar no solo Docker, sino también orquestación como Kubernetes. Para un recién llegado que quiere pinchar y desplegar contenedores rápidamente, es una opción excelente y la más respaldada.
  • La simplicidad de Dockge y Komodo: La aparición de Dockge y Komodo en el top 3 indica que la gente busca soluciones más ligeras y modernas centradas quizás solo en docker-compose.yml. Si solo usas Docker en una máquina y quieres una interfaz rápida para ver el estado, logs y reiniciar contenedores, son alternativas que han ganado tracción rápidamente por su simplicidad.
  • Línea de Comandos vs. GUI: Mi consejo mi audiencia es siempre encontrar el equilibrio. Usa la línea de comandos para el despliegue inicial y automatización (con un compose), pero herramientas como Portainer o Dockge son geniales para la supervisión y para las operaciones rápidas de mantenimiento (reiniciar un contenedor que ha fallado, revisar logs sin tener que teclear docker logs...).

En resumen: Si buscas una herramienta robusta y completa, Portainer es el líder. Si quieres algo más moderno y enfocado en la simplicidad de Docker Compose, mira Dockge o Komodo. Sea cual sea, una interfaz gráfica te ahorrará mucho tiempo.

🔄 ¿Como actualizo los servicios que tengo autoalojados?

La encuesta revela una clara tendencia hacia la precaución cuando se trata de las actualizaciones:

  • Los encuestados tienden a evitar las actualizaciones automáticas de contenedores.
  • Esto se debe principalmente al potencial de fallos o cambios que rompen el servicio (breaking changes).
  • La mayoría prefiere el método Manual o una combinación de ambos (Depends / Both).

En resumen, la encuesta valora más la estabilidad y el control que la inmediatez de la actualización.

Yo soy un entusiasta de la automatización, pero cuando se trata de actualizar algo que funciona, siempre predico la cautela. Si algo rompe mi servidor, afecta a todo lo que tengo autoalojado, y la encuesta refleja esa preocupación.

  • La Regla de Oro: La Estabilidad es Prioridad: La gente no quiere que, al levantarse, su Nextcloud o su servidor Jellyfin haya dejado de funcionar porque una actualización nocturna cambió una variable de entorno de Docker. Los breaking changes son comunes en el código abierto. Por eso, el control manual es crucial para revisar los release notes antes de actualizar.
  • Uso herramientas de Ayuda Manual: Yo, por ejemplo, utilizo herramientas que me avisan de que hay una actualización disponible (como Watchtower configurado en modo notificación, o interfaces como Portainer) pero ejecuto la actualización manualmente. Esto me permite mantener el control.
  • Cuándo Automatizar es Aceptable: El matiz es que la automatización puede ser aceptable para servicios muy estables y de bajo riesgo, como Pi-hole o quizás algunas herramientas muy específicas y aisladas. Pero para servicios troncales (bases de datos, proxies inversos como Traefik, Nextcloud), el consenso es que el control manual es la mejor estrategia para asegurar la productividad y evitar sorpresas desagradables.

Resumiendo: Coincido con la encuesta. En el self-hosting, la estabilidad es más importante que la actualización inmediata. Prefiero revisar las notas y ejecutar la actualización manualmente, minimizando el riesgo de romper mi configuración de contenedores.

🚪 ¿Como accedo a los servicios que tengo autoalojados?

Esa es la pieza final del rompecabezas de la seguridad y la accesibilidad. Una vez que tengo mis servicios en marcha, ¿cómo me aseguro de poder acceder a ellos desde fuera de casa de forma segura? La encuesta es muy clara al respecto.

La encuesta de self-hosting confía en métodos probados que combinan seguridad y comodidad para el acceso remoto:

  • Los encuestados utilizan predominantemente VPNs (Redes Privadas Virtuales) y Proxies Inversos para acceder a sus servicios cuando están fuera de la red local (LAN).
  • La apertura directa de puertos (Forwarded Ports) se utiliza mucho menos.
  • En cuanto a proxies inversos, NGINX y Traefik dominan la escena, representando juntos el 62% de todo el uso de proxies.

Esto indica una madurez en la encuesta, que prioriza soluciones con una capa de seguridad.

Para mí, estas dos herramientas (VPN y Proxy Inverso) no son excluyentes, sino que trabajan mejor juntas, y la encuesta me da la razón.

  • La VPN: El túnel más seguro: Yo siempre recomiendo tener una VPN (WireGuard, OpenVPN, Tailscale, etc.) como la primera capa de defensa. Es como si te teletransportaras a tu red local. Cuando me conecto por VPN, mi móvil o portátil actúa como si estuviera sentado en mi escritorio, y puedo acceder a mis servicios por su IP local si quiero. Es el método más seguro para acceder a todo.
  • El Proxy Inverso (Traefik) para la conveniencia: La popularidad de Traefik y NGINX se debe a que son vitales para la comodidad. El Proxy Inverso me permite hacer dos cosas esenciales:
    • HTTPS Seguro: Me permite obtener certificados Let’s Encrypt automáticamente para mi dominio, ofreciendo acceso seguro (HTTPS) a mis servicios.
    • Acceso Selectivo: Me permite exponer solo ciertas aplicaciones al mundo (por ejemplo, mi blog o mi servidor Git) sin exponer mi red interna completa, delegando la gestión del tráfico y los certificados a una herramienta especializada.
  • La Apertura de Puertos es Peligrosa: La poca popularidad de abrir puertos directamente es una buena señal. Abrir puertos directamente es una práctica insegura porque expones el servicio directamente a Internet sin una capa de protección o filtrado de tráfico adecuada.

En resumen: Para la máxima seguridad, usa una VPN (WireGuard) para acceder a tu red interna. Para la máxima comodidad y para servicios que deben ser públicos (como una web o un servidor de correo), usa un Proxy Inverso como Traefik. Aún así, la solución debería estar combinada por comodidad, VPN para acceder a la red y Proxy Inverso para acceder a los servicios.

🛡️ ¿Que proxy inverso utilizo?

La encuesta revela un claro liderazgo bicéfalo en el sector de los proxies inversos:

  • NGINX y Traefik dominan el mercado, representando juntos el 62% de todo el uso reportado.
  • NGINX Proxy Manager (una interfaz gráfica para NGINX) es la opción individual más popular.
  • Traefik es el segundo, seguido de Caddy y los túneles de Cloudflare.

La tendencia es usar soluciones que simplifican la gestión de certificados y el enrutamiento.

Para mi audiencia, que utiliza mucho Docker y busca automatización, la elección es crucial y está entre el enfoque tradicional y el moderno.

  • NGINX Proxy Manager: El favorito para la sencillez: No me extraña que sea el más popular. La gente adora NGINX Proxy Manager (NPM) porque ofrece una interfaz gráfica sencilla sobre el robusto motor de NGINX. Para quien no quiere tocar archivos de configuración ni entender la lógica de Traefik, NPM es perfecto para gestionar dominios y certificados de forma visual.
  • Traefik: El campeón de Docker y la automatización: Yo, personalmente, me inclino más por Traefik. ¿Por qué? Porque mi filosofía es la automatización. Traefik está diseñado para la era de los contenedores. Se integra directamente con el socket de Docker y detecta automáticamente los contenedores que necesitan exposición, generando los certificados SSL de Let’s Encrypt solo con poner unas etiquetas en mi archivo docker-compose.yml. No tengo que configurar nada fuera de ese archivo. Para mí, es la solución más elegante y eficiente para un entorno basado en contenedores.
  • Caddy y Cloudflare Tunnels: Alternativas interesantes: Caddy es un gran competidor por su simplicidad y por tener HTTPS habilitado por defecto. Los Túneles de Cloudflare también son una alternativa que menciono a menudo, ya que eliminan la necesidad de abrir puertos, lo cual es excelente para aquellos con configuraciones de red complejas.

En resumen: Si eres más visual y prefieres una GUI, NGINX Proxy Manager es excelente. Si, como yo, valoras la automatización, la integración con Docker y minimizar la configuración manual, Traefik es, sin duda, la herramienta más potente y moderna.

📧 ¿Puedo alojar un servicio de email en un servidor autoalojado?

La encuesta revela que, a pesar de la capacidad técnica, la mayoría evita esta tarea:

  • La gran mayoría de los encuestados evita autoalojar servicios de correo electrónico.

El motivo es su complejidad inherente. Es una de las pocas áreas donde la encuesta prefiere depender de proveedores externos.

Yo siempre soy el primero en decir que si se puede, hazlo tú mismo, pero con el correo electrónico, la complejidad y el riesgo son tan altos que coincido plenamente con la tendencia de la encuesta.

  • La Complejidad es la Barrera: Montar un servidor de correo no es solo instalar un contenedor (aunque hay excelentes opciones como Mailcow o iRedMail). El verdadero problema está en la configuración de la red y el dominio. Tienes que gestionar registros DNS complejos (MX, SPF, DKIM, DMARC), asegurar que tu IP no esté en listas negras y lidiar con los filtros anti-spam de gigantes como Google y Microsoft.
  • El Problema de la Reputación de IP: Si usas tu IP de casa, es probable que ya esté marcada como dinámica o que comparta un rango de IP con otros usuarios de ISP, lo que puede hacer que tus correos se vayan directamente a la carpeta de spam del destinatario. Es una batalla constante para mantener una buena reputación de IP.
  • El Riesgo de Pérdida de Datos: El correo electrónico es un servicio crítico. Un fallo en tu servidor, un problema de backup o un ataque podría significar la pérdida de comunicaciones importantes. Por eso, yo prefiero delegar esta responsabilidad en servicios profesionales (aunque sean de pago) que me garanticen la redundancia y la entrega.

Resumiendo: Técnicamente puedes, pero la inmensa mayoría de la encuesta lo evita por la complejidad de la configuración (DNS), la dificultad de mantener la reputación de la IP y el alto riesgo de que tus correos terminen en la bandeja de spam (o no se entreguen). Es más eficiente delegar este servicio.

💾 ¿Utilizo una base de datos para todos los servicios?

El dato clave aquí se relaciona con los métodos de despliegue de bases de datos:

  • La contenerización ha impulsado enormemente la popularidad de las bases de datos.
  • Los métodos de despliegue que más se utilizan son los que promueven el aislamiento (aunque no tenemos los porcentajes exactos):
    • Contenedor (Separado): Cada base de datos corre en su propio contenedor.
    • Bare Metal (Separado): Instalación separada en el sistema operativo base.
    • Contenedor (Compartido): Una base de datos que atiende a varios servicios en distintos contenedores.

La presencia de las opciones Separado sugiere que el aislamiento es la práctica preferida.

Mi recomendación es rotunda: No, no deberías usar una única base de datos para todos los servicios, aunque técnicamente sea posible.

  • Aislamiento y Dependencias: La filosofía de Docker se basa en el aislamiento, y esto aplica también a las bases de datos. Un servicio como Nextcloud tiene sus requisitos de base de datos (PostgreSQL o MariaDB) y necesita su propio espacio. Si lo mezclo con los datos de Gitea o de Jellyfin, estoy creando una dependencia cruzada innecesaria. Si una aplicación falla y afecta a la base de datos, no quiero que tumbe todos mis servicios. Prefiero un contenedor de base de datos por servicio principal.
  • Modularidad y Migración: Al igual que con los contenedores, la separación de bases de datos facilita enormemente el mantenimiento y la migración. Si decido cambiar mi base de datos de Nextcloud de MariaDB a PostgreSQL, solo tengo que ocuparme de ese contenedor y de ese servicio, sin afectar al resto de mis aplicaciones.
  • El Caso del Contenedor Compartido: La opción de Contenedor (Compartido) puede ser útil si estás alojando, por ejemplo, diez servicios muy ligeros y no quieres diez contenedores de base de datos separados. Pero incluso en ese caso, yo optaría por crear una base de datos diferente dentro de ese único contenedor compartido (por ejemplo, db_nextcloud, db_gitea, etc.), manteniendo el aislamiento lógico.

Resumiendo: La tendencia que apoya la encuesta es la de la separación. Yo te recomiendo encarecidamente utilizar un contenedor de base de datos dedicado para cada aplicación principal. Esto garantiza la modularidad, facilita las copias de seguridad y, sobre todo, asegura la estabilidad.

🎬 ¿Que servicio de streaming utilizo en un servidor autoalojado?

La encuesta revela que el mercado está dominado por dos gigantes, aunque con un crecimiento notable de las opciones centradas en el código abierto:

  • Jellyfin es el líder indiscutible en la categoría.
  • Plex sigue siendo muy popular y se posiciona como una opción fuerte.
  • AudioBookshelf (para audiolibros y podcasts) y Navidrome (para música) también destacan, mostrando que el self-hosting no solo se centra en vídeo.

La tendencia es clara: Jellyfin está capitalizando la preferencia de la encuesta por el software de código abierto y la total libertad.

Yo siempre he defendido las soluciones de código abierto, y la popularidad de Jellyfin me da la razón.

  • Jellyfin: El campeón del self-hosting (Open Source): La principal ventaja de Jellyfin es que es totalmente de código abierto y gratuito. Esto significa que tienes control completo, no hay restricciones de características premium (premium features) y la encuesta lo está desarrollando de forma muy activa. Es la opción que más se alinea con la filosofía de atareao con Linux. Lo puedes instalar fácilmente en Docker y te ofrece transcoding, gestión de bibliotecas y aplicaciones cliente para casi todas las plataformas.
  • Plex: El más pulido y fácil (Propietario): Plex sigue siendo popular por su interfaz muy pulida y su facilidad de configuración. Sin embargo, muchas de sus mejores características (como la sincronización móvil o el hardware transcoding en algunos casos) requieren una suscripción (Plex Pass). Es una solución híbrida que usa servidores centrales para la autenticación y la gestión. La gente que lo usa valora mucho su simplicidad.
  • No solo es vídeo: Me parece crucial destacar la aparición de AudioBookshelf y Navidrome. Esto demuestra que el self-hosting va más allá del cine y la televisión, y se extiende a nichos como la gestión de música y audiolibros.

En resumen: Si buscas la opción más pura, libre y totalmente controlada por ti, la respuesta es Jellyfin, que está arrasando. Si priorizas una interfaz muy pulida y no te importa un modelo parcialmente propietario, Plex es la alternativa.

🔒 ¿Es recomendable guardar datos sensibles en un servidor autoalojado?

La encuesta está dividida en este tema, pero la mayoría parece confiar en su propia configuración:

  • Un 18% de los encuestados evita autoalojar información sensible explícitamente, citando preocupaciones de seguridad y respaldo.
  • Esto significa que una gran mayoría (el 82% restante) sí aloja datos que consideran sensibles.

La razón principal para evitarlo es el miedo a las brechas de seguridad y, sobre todo, a la pérdida de datos.

Mi respuesta es: Sí, es recomendable, pero solo si soy riguroso y profesional con dos cosas: seguridad y copias de seguridad.

  • Control Total, Responsabilidad Total: La mayor ventaja del self-hosting es que sé exactamente dónde está mi información, a diferencia de los servicios en la nube. Esto me da privacidad. Sin embargo, esto también significa que la seguridad es 100% mi responsabilidad. No puedo culpar a Google si me hackean.
  • La Seguridad No es Negociable: Si almaceno datos sensibles (documentos, contraseñas en Vaultwarden, fotos en Immich), tengo que ser estricto:
    • Usar un proxy inverso (Traefik o NGINX) con HTTPS obligatorio.
    • Utilizar autenticación fuerte (2FA) en mis servicios.
    • Actualizar manualmente mis contenedores, como indica la encuesta, para evitar exploits conocidos.
  • La Alarma de los Backups: Aquí es donde la encuesta me preocupa más y me llama mas la atención. Si el 34% de los encuestados solo tiene sus datos en una única ubicación, esa gente está corriendo un riesgo enorme con datos sensibles. Si el disco duro falla, o hay un incendio, pierden todo.

Mi regla de oro para datos sensibles es la regla del 3-2-1 (3 copias de los datos, en 2 tipos diferentes de medios, con 1 copia fuera del sitio). Herramientas como Syncthing o soluciones en la nube de bajo coste como Backblaze (que la encuesta menciona como popular) son vitales.

Resumiendo: Si soy un self-hoster serio, implemento buenas prácticas de seguridad (HTTPS, autenticación) y, sobre todo, tengo una estrategia de copia de seguridad sólida (Onsite y Offsite), entonces mi servidor autoalojado es, de lejos, el lugar más seguro para mis datos sensibles, porque tengo el control total.


Más información,

Deja una respuesta

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