Agente de IA autoalojado en Docker: guía práctica 2026

Por qué Docker es la forma estándar de ejecutar un agente de IA autoalojado

Si has decidido que quieres un agente de IA en tu propia infraestructura en lugar de pagar una suscripción mensual de SaaS, Docker es casi con seguridad la forma en que vas a ejecutarlo. En 2026 todo runtime de agente open source serio incluye un Dockerfile o un docker-compose.yml. El patrón ha convergido porque los contenedores resuelven cuatro problemas a la vez que aparecen al autoalojar un agente: la versión del runtime de Python o Node, las dependencias de sistema para audio o visión, la superficie de red que hay que exponer a los webhooks de Telegram o Slack, y el estado persistente (una base de datos y un almacén vectorial) que el agente necesita entre reinicios.

Este artículo recorre cómo se ve realmente ejecutar un agente de IA autoalojado en Docker en 2026: la arquitectura, las plataformas que merece la pena conocer, los compromisos a los que te apuntas y la configuración más barata que sobrevive a un reinicio. Está escrito para alguien que ya ha usado Docker pero todavía no ha elegido un stack de agente.

Qué significa "agente de IA autoalojado" en la práctica

La expresión cubre un rango amplio de productos. Antes de elegir una imagen Docker, sepáralos en tres categorías.

Agentes de flujo de trabajo son plataformas visuales o low-code donde conectas cajas para componer un agente. n8n, Dify y Flowise son los ejemplos canónicos. Funcionan como una aplicación web en la que inicias sesión, y el agente es un flujo que tú diseñas y disparas. Buen encaje si quieres una GUI y más de 400 integraciones preconstruidas.

Frameworks de agentes orientados a código son librerías sobre las que escribes Python o TypeScript. LangChain o LangGraph, AutoGen, CrewAI y el SDK de Agentes de OpenAI viven aquí. Tú entregas tu código como imagen Docker. Buen encaje si eres desarrollador y quieres control total del prompt, las herramientas y la máquina de estados.

Agentes runtime son agentes ya construidos que autoalojas y conectas a tu propia app de mensajería (Telegram, Slack, WhatsApp, Signal, correo). Hermes Agent, OpenHands y Agent Zero son ejemplos. No escribes tú el bucle del agente, viene de serie. Pones una clave de API, pones un servidor, y le hablas desde el móvil.

La receta de Docker es similar para los tres. Las diferencias están en lo que pones alrededor del contenedor: una base de datos para memoria persistente, un almacén vectorial para búsqueda semántica y un receptor de webhooks para la app de mensajería que conectes.

Una imagen tipo diagrama mostrando un contenedor docker con flechas hacia una base de datos postgres, un almacén vectorial y un webhook de telegram

La arquitectura de referencia

Casi todos los agentes de IA autoalojados en Docker terminan teniendo esta forma:

| Componente | Imagen típica | Para qué sirve | |---|---|---| | Runtime del agente | Imagen propia o ghcr.io/<proyecto>/<agente> | El bucle del agente: recibe input, llama al LLM, ejecuta herramientas | | Gateway del LLM | ollama/ollama para local, o API externa | El modelo en sí, o un proxy a OpenAI / Anthropic / OpenRouter | | Base de datos relacional | postgres:16 | Conversaciones, estado del usuario, tareas programadas | | Almacén vectorial | qdrant/qdrant o pgvector dentro de Postgres | Memoria a largo plazo, búsqueda semántica, RAG | | Proxy inverso | traefik o caddy | Terminación TLS, enrutado de webhooks | | Adaptador de mensajería | Dentro de la imagen del agente | Conectores de Telegram, Slack, Discord, WhatsApp, Signal |

No vas a necesitar todas las capas. Si tu agente es solo texto y usa una API LLM externa, puedes saltarte Ollama. Si tu app de mensajería usa long-polling en lugar de webhooks (Telegram soporta los dos), puedes saltarte el proxy inverso. El stack mínimo viable en un VPS de 5 dólares es el runtime del agente más Postgres, con el modelo llamado por una API externa. Eso son entre tres y cuatro contenedores en un único docker-compose.yml.

Un docker-compose.yml mínimo

Para la mayoría de agentes personales o de equipo pequeño, este es el aspecto del archivo compose. Reemplaza your-agent-image por el runtime que hayas elegido.

services:
  agent:
    image: your-agent-image:latest
    restart: unless-stopped
    environment:
      DATABASE_URL: postgres://agent:agent@db:5432/agent
      MODEL_PROVIDER: openai
      OPENAI_API_KEY: ${OPENAI_API_KEY}
      TELEGRAM_BOT_TOKEN: ${TELEGRAM_BOT_TOKEN}
    depends_on:
      - db
    ports:
      - "127.0.0.1:8080:8080"

  db:
    image: postgres:16-alpine
    restart: unless-stopped
    environment:
      POSTGRES_USER: agent
      POSTGRES_PASSWORD: agent
      POSTGRES_DB: agent
    volumes:
      - db-data:/var/lib/postgresql/data

volumes:
  db-data:

Tres detalles importantes. El puerto del agente está expuesto a 127.0.0.1 en vez de a 0.0.0.0 porque un webhook público debería llegar a través de un proxy inverso que termine TLS, no directamente al puerto de un contenedor sin proteger. Los secretos viven en un fichero .env junto al compose (y nunca en git). El volumen de Postgres tiene nombre para que docker compose lo preserve entre reinicios; si pierdes ese volumen, pierdes la memoria del agente.

Las opciones a conocer en 2026

Esta es la lista corta de stacks de agente open source que envían imágenes Docker y tienen tracción en 2026.

| Proyecto | Tipo | Licencia | Integraciones de mensajería | Notas | |---|---|---|---|---| | Hermes Agent | Runtime | MIT | Telegram, Slack, Discord, WhatsApp, Signal, correo | Memoria persistente, BYOK para el modelo, creación autónoma de skills | | n8n | Flujo de trabajo | Sustainable Use | 400+ vía nodos | Constructor visual de flujos, gran catálogo de integraciones | | Dify | Flujo de trabajo | Apache 2.0 | Web UI, widgets embebibles | Enfoque RAG, orquestación de prompts, monitorización incluida | | Flowise | Flujo de trabajo | Apache 2.0 | Web UI, nodos REST/Slack/Telegram | LangChain con drag and drop | | LangGraph | Framework | MIT | Lo que tú conectes | Orientado a código, grafos de estado profundos | | AutoGen | Framework | CC-BY 4.0 (Microsoft) | Lo que tú conectes | Conversación multiagente | | OpenHands | Runtime | MIT | Web UI, IDE | Agente de ingeniería de software en un Docker aislado | | Agent Zero | Runtime | MIT | Web UI, terminal | Agente autónomo de uso de ordenador |

La división importa porque la elección correcta depende de para qué quieras al agente. Una plataforma de flujo es la opción correcta si quieres automatizar un proceso de negocio con 14 pasos y 5 APIs externas. Un framework es la opción correcta si estás construyendo un producto a medida. Un runtime es la opción correcta si quieres un agente personal que viva en tu móvil vía una app de mensajería y que te recuerde.

Para el caso de uso personal centrado en mensajería, Hermes Agent se compara directamente contra n8n en el lado de flujo de trabajo y contra LangChain en el lado de framework.

Los compromisos reales

Autoalojar en Docker no es gratis, aunque los binarios sí lo sean. La lista honesta de compromisos en 2026:

Tú asumes el uptime. Un proveedor de agente gestionado monitoriza procesos, reinicia contenedores caídos y avisa a alguien a las 3 de la madrugada si una release rompe producción. En un VPS autoalojado eso eres tú, incluso si has configurado restart: unless-stopped. Docker reinicia contenedores; no arregla un volumen de Postgres corrupto ni un token de bot de Telegram caducado.

Tú eres dueño del dato, completamente. Esta es la ventaja que hace que los compromisos merezcan la pena para la mayoría. Tus conversaciones, tus notas de clientes, tu lista de contactos: nada toca a terceros excepto el proveedor de LLM que elijas. Los usuarios europeos en un VPS europeo obtienen residencia de datos GDPR sin papeleo. Sanidad o asesorías sobre hardware propio tienen una respuesta defendible al "¿dónde vive el dato?".

Tú pagas la factura del modelo. Usar tu propia clave de API (BYOK) suele costar unos pocos dólares al mes para un agente personal en lugar de los 20 dólares o más que cobra una alternativa gestionada. La otra cara es que tienes que recargar saldo en OpenAI o Anthropic y vigilarlo.

Tú asumes el upgrade. Tirar de una imagen más nueva es un solo comando, pero leer el changelog y migrar el esquema de la base de datos no. Reserva una ventana de 15 minutos cada par de meses.

No eres dueño del LLM. A no ser que ejecutes Ollama o vLLM localmente sobre una GPU, el modelo en sí sigue siendo una llamada de API a OpenAI, Anthropic, Google, Mistral o un agregador como OpenRouter. Autoalojado en 2026 normalmente significa runtime autoalojado, no pesos autoalojados. Está bien: el runtime es donde vive el 90% de la sensibilidad del dato.

Si los compromisos te encajan, la ventaja es importante. La infraestructura autoalojada muestra alrededor de un 55% de reducción del coste total de propiedad en 18 meses frente al SaaS equivalente, con ventajas de latencia del orden de 18 ms cuando el modelo también es local. Para la mayoría de los lectores la ganancia económica llega antes, hacia el mes tres.

Cómo se ve la configuración más barata

Una línea de base práctica para 2026 para un agente autoalojado de una persona:

Un VPS de 5 a 10 dólares al mes (Hetzner, Vultr, Contabo) con 2 GB de RAM
Docker y Docker Compose instalados
Un proxy inverso (Caddy es el más fácil para TLS automático) en el puerto 443
Un contenedor de runtime de agente, un contenedor de Postgres
Una clave de API del modelo con 5 a 10 dólares de saldo
Un bot de mensajería (un bot de Telegram es el más rápido de configurar)

Factura mensual total: aproximadamente de 7 a 20 dólares según uso, de los cuales 4 a 10 son tokens de API y el resto el VPS. La configuración tarda entre 15 y 30 minutos si has usado Docker antes; más bien una tarde si no. El cálculo de tamaño del VPS está en nuestro artículo dedicado al hosting VPS barato para un agente de IA, y la comparativa de costes entre autoalojado y gestionado está aquí.

Un espacio de trabajo oscuro y limpio por la noche con un portátil mostrando salida de terminal y un móvil con una burbuja verde de mensaje de un agente de IA autoalojado

Cuándo autoalojar es la respuesta equivocada

Una lista corta de casos donde la vía Docker es la herramienta equivocada.

Necesitas cero implicación de ops y tu equipo no tolera ninguna caída. Paga por un runtime gestionado.
Quieres SLAs del proveedor y un número de teléfono al que llamar. Gestionado.
Tienes menos de una hora de paciencia para la configuración inicial. Gestionado.
Tu agente necesita escalar de forma elástica a miles de usuarios concurrentes mañana. Un runtime gestionado sobre Kubernetes merece la pena.

Para todos los demás (fundadores en solitario, desarrolladores indie, despachos pequeños, profesionales sensibles a la privacidad, hobbistas) Docker en un VPS pequeño es el camino con mejor relación entre control y tiempo de puesta en marcha.

Dónde encaja Hermes

Hermify es un runtime de agente de IA autoalojado con licencia MIT que se distribuye como imagen Docker. Pones tu propia clave de proveedor de modelo (OpenAI, Anthropic, OpenRouter, Mistral u otros), ejecutas el contenedor en un VPS o en tu propia máquina, y le hablas a través de Telegram, Slack, Discord, WhatsApp, Signal o correo. Mantiene memoria persistente entre conversaciones, aprende skills reutilizables a partir de tu uso, y no te molesta el resto del tiempo. Es una opción entre los runtimes listados arriba; resulta que es la que nosotros mantenemos.

Si la forma de agente personal en el móvil es lo que buscas y tienes una hora para poner un contenedor Docker tras un proxy inverso, Empieza con Hermify. Si prefieres saltarte el VPS y que lo ejecutemos por ti, el plan gestionado se encarga del contenedor, del Postgres, del TLS y de las actualizaciones mientras tú conservas tu propia clave de modelo.