← Volver al blog
open-source docker self-hosting soberania privacidad ia

De Snipe-IT a Onyx: cómo el open source me enseñó soberanía en AI (y Docker)

De un inventario sin licencia en L'Idem a un Mini PC con Docker: cómo el open source me obligó a aprender infraestructura, privacidad y soberanía de datos — hasta la capa de IA.

Hay una mentira cómoda en el sector tech: que la soberanía de la información es un tema de “empresas grandes” o de reguladores en Bruselas. La verdad es más cercana. Empieza el día en que no tienes presupuesto para la licencia, necesitas la herramienta igual, y descubres que el open source no solo te salva la plata: te obliga a entender el sistema. A mí me pasó hace unos cuatro años, en Barcelona, y ese peaje —incomodidad a cambio de control— terminó siendo la mejor escuela de mi carrera.

Este no es un tutorial. Es el camino de Snipe-IT a Onyx: de gestionar activos IT sin SaaS caro, a decidir dónde viven mis prompts. Y de paso, por qué Docker dejó de ser “esa vaina de DevOps” y se volvió el idioma en el que despliego casi todo.

1. Presupuesto cero: L’Idem y el inicio del viaje

Trabajaba como IT Manager en L’Idem Barcelona, una escuela de animación y artes digitales con servidores físicos de los que yo me encargaba. Había infraestructura real, pero no había margen para comprar software avanzado de inventario o de gestión de contraseñas. El problema no era “querer open source por ideología”. Era más simple: o improvisábamos, o no teníamos herramienta.

Ahí aparecieron dos piezas que aún uso en el discurso de este post:

  • Snipe-IT — gestión de activos IT (hardware, licencias, quién tiene qué). Open source, autoalojable.
  • Vaultwarden — servidor compatible con los clientes de Bitwarden (no es el servidor oficial de Bitwarden; es una implementación ligera, no oficial, pensada para self-hosting).

Claro: al principio no entendía nada de contenedores. Seguía videos de YouTube —un ingeniero de la India con librería infinita de guías IT— e instalé Snipe-IT directo sobre Ubuntu, sin Docker, a pelo. Error de principiante. Funcionó… hasta que las dependencias, las actualizaciones y el “¿por qué se rompió esto?” me cobraron la factura.

2. Publicarlo por una URL: proxy, HTTPS y el peaje de la red

Levantar la app en el servidor es la mitad del problema. La otra mitad es: ¿cómo la alcanzas con una URL decente, con TLS, sin dejar el servicio colgando en un puerto crudo?

Ahí aprendí, a golpes, lo que muchos tutoriales dan por sentado:

  • Proxy reverso — el portero que recibe HTTPS y enruta hacia el servicio interno.
  • CDN — borde de distribución y a veces caché.
  • WAF — filtros frente a basura y ataques obvios en el perímetro.
  • HTTPS / cURL — no como teoría de certificaciones, sino como “¿por qué este 502?” y “¿qué header estoy mandando de verdad?”.

Usábamos máquinas virtuales sobre un VMware ya viejo en la empresa. Las VMs sirven: aíslan, emulan un equipo completo, traen su propio sistema. Pero para desplegar muchas apps pequeñas, el peso se siente. Cada VM es casi un PC entero. Cuando solo quieres una aplicación y sus dependencias, eso es mucho peaje.

3. Glovo, un HP de 20 kg y el MinisForum HM80

Conseguí un puesto en Glovo: mejor pagado, responsabilidades más básicas de las que ya venía haciendo. Justo antes de cerrar el ciclo en L’Idem, me regalaron un servidor HP viejo —más de 20 kg, unos 16 GB de RAM y 10 núcleos— que era, con cariño, más peso que capacidad para lo que el software de 2023 pedía. Lo llevé a casa, experimenté, y poco después lo regalé a un compañero.

Entonces compré mi primer Mini PC: un MinisForum HM80, alrededor de 550 euros, 32 GB de RAM, 8 núcleos y 16 hilos. Una maquinón del tamaño de la palma. Ahí el laboratorio dejó de ser “servidor heredado que gime” y pasó a ser infraestructura que yo elegí.

4. Glosario que aprendí rompiendo cosas

Antes de Docker, conviene nombrar las piezas sin teatro:

  • Máquina virtual (VM) — abstrae el hardware. Cada VM suele traer su propio sistema operativo y kernel. Aislamiento fuerte; más peso en disco, RAM y arranque.
  • Contenedor — aísla procesos compartiendo el kernel del host. Más ligero, arranca en segundos, portable entre entornos.
  • Docker — el runtime y el formato de imagen con el que la mayoría empaquetamos y corremos esos contenedores de forma reproducible.
  • Docker Compose — un YAML donde defines varios servicios (app, base de datos, proxy…), redes y volúmenes, y los levantas como un solo stack.
  • Open source — no es solo “gratis”. Según la Open Source Initiative, implica derechos reales: usar, estudiar, modificar y redistribuir con el código disponible. Esa transparencia es la base de la soberanía: puedes inspeccionar lo que corre con tus datos.

Ojo: VM y contenedor no son enemigos. En producción muchas veces corres contenedores dentro de VMs. Lo que sí se vuelve obsoleto, para densidades de lab y PyME, es montar cada app como si fuera un servidor completo.

5. La magia (sin magia) de Docker

Con el HM80 entendí el salto: desplegar a base de VMs para cada herramienta era el camino largo. Docker + Compose me daban lo mismo —aislamiento razonable, reproducibilidad— sin pelearme semanas con librerías del sistema.

No es magia. Es un contrato: la imagen trae lo que la app necesita; el YAML describe cómo se conecta con el resto; el host aporta kernel, disco y red. El mismo patrón que me hubiera ahorrado el install a pelo de Snipe-IT.

Desde entonces, Docker es el centro de mi laboratorio. Y Portainer —una interfaz clara para administrar contenedores— se volvió la base recomendable para quien quiere empezar sin vivir pegado al CLI… mientras entiende, poco a poco, cuándo hará falta algo más potente (Kubernetes / K3s: eso lo dejo para otro post).

6. De inventario a soberanía de IA

El patrón se repite en otra capa. Primero fueron inventarios y contraseñas. Ahora son prompts, contexto y políticas de modelos.

En mi repo público docker-compose-portainer voy recopilando stacks listos para Portainer o CLI: desde el mismo Snipe-IT y Vaultwarden donde empezó todo, hasta piezas de soberanía en AI como LiteLLM (gateway/proxy hacia muchos proveedores y modelos con API compatible) y Onyx (capa de chat/RAG autoalojable). No vendo la fantasía de que eso “iguala” por arte de magia la calidad frontier de ChatGPT o Gemini. Lo que sí cambia es el control: dónde viven los datos, qué modelo usas (API o local con Ollama), y qué queda dentro de tu red.

Ahí está el punto: soberanía de información no es un poster en la oficina. Es decidir el perímetro. Y privacidad no es un checkbox de marketing: es arquitectura.

7. El peaje de la comodidad

Self-hosting tiene costo real: backups, actualizaciones, TLS, no exponer servicios a lo loco, documentar. El SaaS vende comodidad. Tú sacrificas esa comodidad por criterio técnico y por no entregar inventarios, secretos o conversaciones con IA a un tercero por defecto.

En 2026, hasta la Unión Europea habla de open source como pieza de soberanía tecnológica —no solo como ahorro de licencia. A mí me llegó antes, por necesidad, en una uni con servidores físicos y poco presupuesto. El resto fue consistencia: Linux, protocolos, Docker, y la disciplina de compartir lo reutilizable sin filtrar secretos.

Si están empezando, miren el repo. Hay Compose de herramientas que he ido probando, con Portainer como puerta de entrada. Empiecen chiquito. Rompan cosas en casa, no en producción ajena. Y pregúntense, en serio, una sola cosa:

¿Cuánta comodidad estás dispuesto a pagar… con tus datos?