Ejecuta una crew multiagente de CrewAI en un VPS

Tu crew de CrewAI funciona genial en tu portátil. Los agentes hablan entre sí, el investigador entrega al escritor, todo el asunto zumba — justo hasta que cierras la tapa y todo se detiene. O tu wifi se cae a mitad de tarea. O reinicias y olvidas reiniciarla.

Una crew que solo funciona mientras observas no es automatización. Es una demo. Moverla a un VPS es lo que la convierte en algo que de verdad funciona mientras duermes.

Por qué un servidor, no tu máquina

El pitch es simple: un VPS es un ordenador que nunca cierra su tapa. Tiene una IP fija, no duerme, y si el proceso muere puede traerse de vuelta a sí mismo. Para una crew multiagente — que por diseño ejecuta trabajos largos, parlanchines y de múltiples pasos — esa es la diferencia entre «funcionó una vez» y «lleva funcionando tres semanas».

Hay una segunda razón que hace tropezar a la gente de buena manera: no necesitas una máquina potente. Más sobre eso a continuación, porque es la pregunta que todos hacen primero.

No, no necesitas una GPU

Esta es la parte que la gente hace mal sobre alojar agentes. CrewAI es un orquestador. Decide qué agente actúa, en qué orden, con qué contexto — y luego le pide a un modelo de lenguaje que haga el razonamiento real. Ese modelo casi siempre vive detrás de una API: envías una solicitud a OpenAI o Anthropic, la ejecutan en sus GPUs, obtienes texto de vuelta.

Así que tu servidor hace tres cosas: ejecutar Python, mantener el estado de la crew, y hacer llamadas HTTPS. Nada de eso toca una GPU. Un VPS de CPU simple es exactamente lo correcto. La única vez que eso cambia es si además quieres ejecutar el modelo localmente — pero ese es un proyecto aparte, más pesado, y la mayoría de las crews no lo hacen.

En la práctica: un plan de 1–2 GB ejecuta una crew pequeña sin sudar. Ve a 4 GB si estás ejecutando varias crews a la vez, conservando grandes historiales de conversación en RAM, o atornillando una base de datos vectorial para memoria de largo plazo del agente.

La configuración real

Máquina Ubuntu nueva, root en aproximadamente un minuto tras el pedido. Aquí está la cosa entera:

# Python + venv
apt update && apt install -y python3-venv python3-pip
python3 -m venv ~/crew && source ~/crew/bin/activate

# CrewAI
pip install crewai crewai-tools

# tu proyecto
mkdir ~/mycrew && cd ~/mycrew
# copia aquí tu crew.py y .env (scp / git clone)

Tu .env mantiene el único secreto que importa — la clave de API del LLM:

OPENAI_API_KEY=sk-...
# o ANTHROPIC_API_KEY, etc.

Luego un python crew.py normal la ejecuta. Esa es la versión manual. Funciona, pero muere en el momento en que tu sesión SSH se cierra — lo que nos lleva al sentido real de un servidor.

Mantenla viva con systemd

tmux está bien para una prueba rápida. Para cualquier cosa real, usa systemd — reinicia la crew si se cae y la levanta al reiniciar. Coloca esto en /etc/systemd/system/mycrew.service:

[Unit]
Description=CrewAI crew
After=network-online.target

[Service]
WorkingDirectory=/root/mycrew
ExecStart=/root/crew/bin/python /root/mycrew/crew.py
Restart=always
RestartSec=5
EnvironmentFile=/root/mycrew/.env

[Install]
WantedBy=multi-user.target

systemctl daemon-reload
systemctl enable --now mycrew
journalctl -u mycrew -f   # míralo trabajar

Ahora la crew funciona al arranque, se reinicia en los fallos, y registra en todas partes donde puedas leerlo. Cierra tu portátil — no le importa.

El pago

El registro es un correo y un código de un solo uso — sin tarjeta, sin documento. Financias un saldo con USDC o USDT en Base, Ethereum o Polygon (Base es la más barata en comisiones), y los pedidos toman de él. Para una crew que sobre todo hace llamadas de API de salida, el plan NAT por defecto está bien y es más barato; elige un plan -ip solo si la crew necesita su propia IPv4 pública para servicios entrantes.

Un buen truco: EQVPS tiene un servidor MCP en mcp.eqvps.com/mcp. Si el aprovisionamiento es en sí uno de los trabajos de tu crew, un agente con un saldo financiado puede llamar a order_vps y levantar una máquina por su cuenta — sin humano en la caja.

Qué es honesto decir

Tú traes las claves de API del LLM. Nosotros alojamos la crew, no el modelo. Tu factura de OpenAI/Anthropic es aparte y, para una crew ocupada, normalmente el coste mayor — el VPS es la parte barata.

Es solo CPU, un centro de datos en Alemania. Sin inferencia local en GPU, y la latencia es mejor si tus usuarios o APIs están cerca de Europa. Para una crew que llama a APIs de LLM alojadas en EE. UU. el salto extra son milisegundos — irrelevante junto a la latencia del modelo — pero bueno saberlo.

Dimensiona para tu memoria, no para tu modelo. Lo que de verdad hace crecer tu uso de RAM es el historial de conversación y cualquier almacén vectorial que añadas, no el número de agentes. Vigila journalctl y htop un día y cambia el tamaño si lo necesitas.

La conclusión

Una crew de CrewAI pertenece a algo que no duerme. El movimiento es corto: un VPS de CPU, pip install crewai, una unidad systemd, tu clave de API en un .env. Diez minutos y tu crew funciona 24/7 en lugar de «cuando el portátil está abierto». Root en aproximadamente un minuto, paga en cripto, cambia el tamaño cuando la memoria te lo diga — y deja que los agentes sigan con ello.