LTC Labs - Mi infraestructura ya no la opero yo, la opera la IA

1. Así empezó esto

Un día escribí a Claude que quería un servidor de IA local en mi Proxmox. No le di un comando, le di una idea. Esto es lo que pasó a continuación (capturas y conversación reales del task #719 de mi Odoo interno).

Yo:

Mejora este prompt: "Quiero crear un nuevo servidor con IA local. Un nuevo contenedor en pve1, ct-132 (ollama-gemma4) (192.168.1.132), 16 cores, 16GB RAM, 50GB HDD. Quiero montar LLM Ollama + gemma4 (#6 Arena AI). Analiza mi entorno de trabajo y prepara un plan para realizar todo esto usando system-admin"

Claude:

Fase 0 - Proyecto detectado

Entorno: Proxmox pve1 (192.168.1.2), infra dual pve1/ipve1.

Precedente: CT-131 (aicowork) ya corre Ollama + Open WebUI + Qwen2.5 7B - referencia directa.

Skill aplicable: system-admin (SSH remoto, Proxmox, contenedores).

Fase 4 - Gaps críticos detectados

1. "gemma4" no existe como modelo oficial. Google tiene Gemma 2 y Gemma 3. El #6 de LMArena (abril 2026) debe verificarse - probablemente te refieres a gemma-3-27b o similar. Aclarar antes de ejecutar.

2. Recursos: 16 GB RAM / 50 GB HDD - un Gemma 3 27B necesita ~20 GB solo para pesos (Q4). Recomendado 80-100 GB.

3. ¿GPU: passthrough o solo CPU? Para un 27B en CPU será muy lento.

4. ¿UI: Open WebUI como en CT-131, o solo API Ollama?

5. ¿Acceso externo: nginx reverse proxy / subdominio?

Pasos que voy a planificar (no ejecutar aún)

1. SSH a pve1, comprobar recursos libres, CTID y IP.

2. Investigar el modelo real en LMArena via WebFetch.

3. Plan de provisión con pct create y parámetros exactos.

4. Plan de instalación Ollama + pull modelo + test.

5. Plan Open WebUI si aplica.

6. Reverse proxy / DNS si aplica.

Espero tu OK antes de tocar nada.

Lo que vino después fue lo de menos. Confirmé, Claude se conectó a pve1 por SSH, creó el CT-132 con pct create, instaló Ollama nativo, descargó el modelo (acabó siendo Gemma 4 26B, 17 GB en disco), montó Open WebUI nativo bajo systemd como usuario aicowork, registró un tool de Python para que el LLM pueda ejecutar comandos, y me dejó el servicio escuchando en http://192.168.1.132:8080. Yo no abrí ni una sola sesión SSH.

Lo importante no es que Claude sepa hacer un pct create. Lo importante es que identificó los gaps antes de tocar nada (modelo inexistente, disco insuficiente), uso el precedente del CT-131 como plantilla mental, y se paro a pedirme confirmacion. Es como tener un sysadmin junior con memoria perfecta del entorno.

2. No tengo solo infra. La IA puede operarla.

La pieza que falta entender es esta: la infraestructura por sí sola no vale. Lo que la convierte en algo nuevo es el sandwich infra + skills + IA.

• Infra: Proxmox, contenedores, VPS de correo, accesos SSH con clave.
• Skills: instrucciones que le he ido escribiendo a Claude para que sepa operar mi entorno (system-admin, odoo-pilot, oci-creator, ict-project-creator...). Son markdown plano, versionados.
• IA: Claude Code conectado por SSH desde el contenedor de desarrollo, leyendo las skills y la memoria del proyecto.

Resultado: tareas que antes me llevaban media tarde ahora son una frase.

Ejemplo 1 - "Crea catchall@clientx.com"

Le digo a Claude: crea catchall@clientx.com y configuralo como saliente en el Odoo del cliente.

Lo que hace, sin que yo intervenga:

1. Carga la skill system-admin. Sabe que el correo vive en elpanocho.com (VPS OVH, ~7 EUR/mes), Postfix + Dovecot + Virtualmin.
2. SSH a ubuntu@elpanocho.com con su clave, crea el buzon en Postfix, añade el alias catchall.
3. Genera la clave DKIM con OpenDKIM para el dominio del cliente, pública el TXT en el panel DNS de PiensaSolutions.
4. Carga la skill odoo-pilot. Entra al Odoo del cliente por XML-RPC, configura el servidor saliente SMTP (puerto 587, STARTTLS, smtp_from correcto), y un fetchmail entrante para el catchall.
5. Manda un mail de prueba y verifica cabeceras (SPF/DKIM/DMARC PASS).

Yo recibo el resumen. Si algo falla, me dice exactamente qué falló y dónde.

Ejemplo 2 - "Aprovisiona un Odoo nuevo para el cliente Y"

Le pido un Odoo 18 con verticales hostelería + POS. Claude usa la skill oci-creator: SSH a pve1, pct create de un LXC nuevo con Docker dentro (privilegiado, lo aprendimos a fuerza de fallar con overlay2), genera el docker-compose.yml, resuelve dependencias OCA recursivas, hace addon_requirements.txt antes del build, inicializa la base de datos con --workers=0 --no-http para evitar la race condition con el entrypoint, instala l10n_es de inicio (no se puede cambiar el plan contable después), aplica el checklist de implantacion (EUR no USD, kg no unidades, alérgenos, mesas POS, traducciones con --i18n-overwrite, debranding) y pública el repo custom en GitLab con el README espejado en document.page dentro del Odoo.

Todo eso está codificado en una skill. La memoria de los errores también. Cada vez que me pego con algo nuevo, lo dejó escrito en MEMORY.md y la próxima vez no vuelve a pasar.

3. Inventario - los contenedores que mueven esto

Tres pilares físicos:

• pve1 - Proxmox on-premise en mi sede (192.168.1.2). Xeon E5-2697v3, 14 cores / 28 hilos, 62 GB RAM, 2 TB rpool ZFS. Es el taller: 33 contenedores entre activos y dormidos, 12 VMs. Aquí vive el desarrollo Odoo multiversion (14 a 19), el LLM local, los servicios internos.

• ipve1 - Barebone dedicado en datacenter (lemontreecloud.com, OVH). Xeon E5-1650v2, 6 cores / 12 hilos, 31 GB RAM. La cara pública: 7 contenedores, todos en running, sin VMs. Replicas de los Odoos de pve1 más el frente nginx y la VPN. Desde ~30 EUR/mes.

• elpanocho.com - VPS independiente de OVH (~7 EUR/mes). Postfix + Dovecot + Virtualmin + OpenDKIM. MTA y SMTP outbound autenticado para los dominios elpanocho.com, fer.elpanocho.com y lemontreecloud.com.

Estos son los 10 contenedores clave que tocamos a diario en pve1:

Aclaración importante: no hay replicación automática en vivo entre sede y datacenter. Cada nodo tiene su propio backup programado local (vzdump semanal, retención corta). Lo que sí hay es un mapeo lógico por servicio, conservando el VMID entre nodos (116 en pve1 = 116 en ipve1) como convención, para que cuando toque mover o recrear algo, el agente (o yo) no tenga que adivinar equivalencias. El mismo agente, con la misma clave SSH, opera en ambos hosts indistintamente; la sincronización, cuando hace falta, se orquesta a mano o por skill, no por cron.

4. Esto vale para cualquier PYME

Lo monte para mi. Pero no hay nada aquí que no funcione para una PYME que quiera dejar de pagar SaaS por todo y empezar a tener su propia infra operada por IA.

Coste de entrada, sin marketing:

• ipve1 estilo (barebone dedicado en datacenter, OVH o similar): desde ~30 EUR/mes. Suficiente para 5-7 LXC corriendo Odoo, nginx, VPN.
• VPS de correo estilo elpanocho.com: ~7 EUR/mes. Postfix + Dovecot + DKIM. Te quita la dependencia de Google Workspace o Microsoft 365 para los buzones operativos.
• pve1 estilo (Proxmox on-premise en la oficina): hardware propio. Una única inversión. Un Xeon de segunda mano con 64 GB de RAM cuesta menos que un mes de SaaS para 20 empleados.

Tres caminos para llegar aquí (sin orden, sin venta):

• Te lo montó yo. La infra es tuya. Tu la alquilas con el proveedor que quieras y yo opero sobre ella. Pongo las skills, los SSH keys, y te dejó operativo el primer flujo "crea cliente nuevo extremo a extremo". A partir de ahi tu equipo le habla a la IA, no a la consola.
• Te formo via Open Teach Partner. Tengo una empresa de formacion en open-source (Odoo + OCA, infra Proxmox, agentes Claude). Si lo que quieres es entender cómo se monta y operarlo tú -o que alguien de tu empresa ejerza ese rol-, hay un programa para eso.
• Te inspiro y lo pides a otro. Esta nota existe precisamente para que sepas que esto ya no es ciencia ficción. Si encuentras a alguien que te lo monte mejor, perfecto. La idea es que existe la categoría. Antes no sabias que existía.

Lo que hace tres años requeria un equipo de DevOps, hoy lo hace un Proxmox barato, una clave SSH, y un agente que ha leido tu memoria. Yo lo uso a diario. Funciona.