Portainer lo usé durante un par de años. Es una herramienta sólida, madura, y que hace cosas que Dockge no hace, como gestionar Kubernetes, gestionar nodos Docker Swarm, o tener control de acceso por roles. Si gestionas infraestructura de empresa o un cluster complejo, tiene sentido.
En un homelab personal, sin embargo, Portainer me empezó a resultar pesado. No por los recursos, que son mínimos, sino por el modelo mental. Portainer quiere gestionar tus contenedores, tus redes, tus volúmenes, tus imágenes. Tiene su propia capa de abstracción por encima de Docker. Y cuando algo no va como esperas, a veces es difícil saber si el problema está en tu configuración, en Portainer, o en Docker.
Tuve una historia de amor y odio con los backups durante años. Amor porque siempre tenía la intención de montarlo bien. Odio porque cada solución que intentaba tenía algo que me echaba atrás: demasiado complicada, demasiado lenta, imposible de verificar, o que dejaba de funcionar en silencio durante semanas sin que yo me enterara.
Rsync para hacer copias de directorios. Duplicati con su interfaz web que prometía mucho y entregaba poco. Borg Backup, que es técnicamente excelente pero que tiene una curva de aprendizaje suficientemente pronunciada como para que lo dejara a medias dos veces.
Llevo tres años cambiando de hardware homelab y cometiendo los mismos errores que todos al principio. Empecé con una Raspberry Pi, di el salto a un PC viejo de torre, y después de varios recorridos y facturas de luz más altas de lo que me esperaba, llegué a los mini PCs. Hoy mi homelab principal corre sobre un Minisforum MS-01 y un par de nodos más pequeños, y estoy razonablemente contento.
Hay herramientas que uno descubre tarde y piensa: ¿cómo estuve tanto tiempo sin esto? Cockpit es una de ellas.
La descubrí por casualidad mientras buscaba una forma de gestionar mis servidores Debian sin tener que conectarme por SSH para cada cosa pequeña. No quería Portainer porque no todo lo que corre en mis servidores es Docker. No quería montar otra aplicación en K3s solo para ver el estado de una máquina. Quería algo nativo, ligero y que funcionara sin fricción.
Durante mucho tiempo tuve el mismo problema que creo que tiene casi todo el que monta un homelab con más de cuatro o cinco servicios: una contraseña diferente para cada cosa. Proxmox con su usuario, Grafana con el suyo, Portainer con otro, y así hasta llegar a tener un documento con 20 credenciales que actualizaba de forma irregular. Cuando instalaba un servicio nuevo, pensaba un momento y escribía alguna variación de siempre la misma contraseña. Mal hábito.
Durante mucho tiempo mi stack de monitorización fue Grafana más Prometheus más node_exporter más varios exporters específicos. Funciona bien, da dashboards muy potentes, y lo recomiendo. También tarda horas en configurar correctamente, tiene un consumo de recursos no despreciable, y cualquier nueva métrica que quieras monitorizar requiere buscar el exporter adecuado, configurarlo, añadir el scrape job en Prometheus, crear el panel en Grafana.
Netdata tiene una filosofía diferente. Instalas el agente y en dos minutos tienes datos de todo: CPU, memoria, disco, red, procesos, temperatura, Docker, y decenas de integraciones que se detectan automáticamente. Sin tocar ningún archivo de configuración en la instalación básica.
Tengo más SBCs repartidos por casa de lo que me gustaría admitir. Hay un par de Raspberry Pi haciendo de sensores, un ZimaBoard en el rack de red, y algún Orange Pi que empecé a usar para algo y se quedó a medias. Todos estuvieron durante meses sin carcasa, apoyados sobre su propia PCB o dentro de bolsas antiestáticas. Funciona, pero es feo y no protege nada.
La impresora 3D cambió eso. Ahora cada SBC que uso tiene su carcasa impresa, con ventilación, con soporte para el rack si hace falta, y en algunos casos con personalización que no encontrarías en ningún sitio. Llevarlo a la práctica no es complicado, pero hay decisiones de material y de diseño que marcan la diferencia entre una carcasa que dura y una que se deforma al mes.
Este no es un post de teoría sobre IA. Es lo que realmente tengo montado, lo que ha funcionado, lo que no, y por qué creo que la forma en que muchas empresas están aproximándose a los agentes de IA está mal planteada.
Contexto: gestiono la distribución de varias marcas de cosmética de lujo en España. Marcas con catálogos grandes (cientos de productos), terminología muy específica (ingredientes activos, protocolos de tratamiento, formaciones de terapeuta), y materiales que constantemente hay que adaptar: manuales, fichas de producto, presentaciones para clientes, contenido para redes sociales.
Llevo años peleándome con scrapers que fallan en la mitad de las webs. Curl y wget para páginas estáticas, Playwright para las que necesitan JavaScript, Selenium para las que son especialmente cabronas… y siempre el mismo problema: login. Si la página necesita que estés autenticado, la cosa se complica bastante.
La semana pasada instalé browser-use CLI y cambió bastante el panorama. No es magia, pero es la herramienta más práctica que he encontrado para automatizar el navegador desde la terminal de una forma sencilla y que además puede usar tus sesiones reales de Chrome. Sin configurar credenciales. Sin gestionar cookies manualmente.
Antes de Uptime Kuma, mi sistema de monitorización consistía en abrir el navegador, escribir la IP de cada servicio y ver si respondía. Funciona, pero está lejos de ser un sistema. Un día me enteré de que un servicio llevaba 14 horas caído porque nadie (yo incluido) lo había comprobado manualmente en ese tiempo.
Eso fue hace dos años. Desde entonces tengo Uptime Kuma corriendo en el homelab y me avisa antes de que yo me dé cuenta de que algo falla. Con cuarenta y tantos monitores configurados, es el servicio que más uso en el día a día aunque sea el que menos veo, precisamente porque cuando funciona bien no necesita atención.
Llevo un par de años imprimiendo piezas que otros diseñaron. Gridfinity, soportes para servidores, cubiertas para la Raspberry Pi… todo genial, pero siempre llegaba el momento en que necesitaba algo específico y no lo encontraba en Printables ni en Thingiverse. O lo encontraba, pero con las dimensiones equivocadas para mi caso concreto.
El salto a diseñar mis propias piezas lo di por necesidad. Tenía un mini PC que necesitaba un soporte que se enganchara al lateral del rack, con unas medidas muy concretas. Nada encajaba. Así que abrí Fusion 360 por primera vez, vi la interfaz y cerré el programa a los diez minutos. Demasiado.
Perdí tres meses de trabajo una vez. No en un homelab, en un servidor de producción, pero la lección se me quedó grabada. Desde entonces tengo una regla no negociable: si no hay backup verificado, no existe.
Durante mucho tiempo usé las snapshots de Proxmox como backup. Es cómodo y rápido, pero es una trampa. Las snapshots viven en el mismo almacenamiento que las VMs. Si falla el disco, pierdes las VMs y las snapshots de golpe. Eso no es un backup, es una ilusión de seguridad.
