Recursos · Integración n8n

Nodo Execute Command n8nConfigura Execute Command en n8n.

A veces la herramienta que hace falta ya está en el servidor, no detrás de una API. El nodo Execute Command n8n lanza un comando de shell en la máquina que aloja n8n y devuelve su salida como dato del flujo. Dos parámetros, nada que autenticar, instancia propia.

Reseñas verificadas en Trustpilot · Agencia de IA, automatización y growth

Por qué automatizar

¿Para qué sirve de verdad el nodo Execute Command n8n?

Este nodo lanza un comando de shell en la máquina anfitriona donde corre n8n y devuelve al flujo lo que ese comando haya impreso. Usa el shell que la máquina tiene por defecto, cmd en Windows y zsh en macOS. No arranca nada por sí mismo: delante siempre hay un disparador, un Schedule Trigger o un Webhook, es decir una URL que n8n escucha.

El caso que más lo justifica es el despliegue. Un flujo reacciona a un cambio en el repositorio y el nodo lanza en el servidor los comandos de descarga y construcción, encadenados con && o escritos cada uno en su propia línea dentro de Command. Con el nodo GitHub delante, el nombre de la rama llega como dato y no escrito a mano en el comando.

Antes de seguir conviene decir lo que condiciona todo: el nodo no está disponible en n8n Cloud. Pide una instancia autoalojada, con Docker o npm, en Community Edition bajo licencia Sustainable Use, y desde n8n 2.0 llega además desactivado por defecto, porque abrir un shell desde un flujo es un riesgo real en una instancia compartida con usuarios que no controlas.

El segundo uso aprovecha la vuelta: lo que el comando imprime entra en el flujo como dato. Un comando que cuenta archivos o mide el espacio libre deja su salida lista para el nodo siguiente, y ese resultado llega al equipo como un mensaje de Slack en lugar de quedarse en un servidor que nadie mira.

El tercer uso es una cuestión de ritmo. Cuando entran varios items, el nodo corre una vez por cada entrada y la expresión {{ $json.field }} le pasa el valor propio de cada uno. Cuando lo que toca es una sola pasada de cierre, Execute Once activado lo reduce a una única ejecución. Elegir bien entre los dos comportamientos es casi todo lo que hay que configurar aquí.

Queda saber cuándo no es la herramienta. Lo que hable HTTP va al nodo HTTP Request, incluidos los comandos curl que se escriben por costumbre: curl no viene en la imagen Docker de n8n y recuperarlo obliga a construir una imagen propia sobre la oficial. Lo que deba correr en otra máquina va al nodo Ssh, porque este no sale de su anfitrión: con Docker el comando corre dentro del contenedor de n8n y no en la máquina de debajo, y en modo cola corre en el worker que tomó la tarea en producción, salvo en las ejecuciones manuales, que se quedan en la instancia principal mientras OFFLOAD_MANUAL_EXECUTIONS_TO_WORKERS no valga true. El Curso n8n empieza por esas bases.

Parámetros

¿Qué parámetros ofrece el nodo Execute Command ?

El nodo Execute Command tiene 2 parámetros. Para cada uno: el nodo tal como lo configuras en n8n, qué cambia el parámetro y nuestras notas de campo.

01

Execute Once

executeOnce

Lo que ves en n8n

Notas y casos de uso

Este interruptor marca cuántas veces sale el comando cuando llegan varios items al nodo. Activado, sale una sola vez sin importar cuántos items hayan entrado. Desactivado, sale una vez por cada item, que es el comportamiento por defecto del nodo.

Parámetros clave

  • Execute Once: un sí o no, ejecutar solo una vez en lugar de una vez por entrada.
Casos de uso
una consulta devuelve cuarenta filas y quieres un único comando de archivado al final, no cuarenta. Actívalo. Déjalo apagado cuando cada fila lleva el nombre del archivo sobre el que el comando tiene que actuar.
02

Command

command

Lo que ves en n8n

Notas y casos de uso

La línea que se entrega al shell. Único campo obligatorio del nodo: vacío, bloquea la ejecución. El texto de ayuda enseña la forma esperada, echo "test".

Parámetros clave

  • Command: texto, obligatorio, el comando a ejecutar. Mete un valor del nodo anterior con una expresión como {{ $json.field }}, la sintaxis de n8n para leer un campo del item entrante.
Casos de uso
encadenar dos comandos uniéndolos con &&, por ejemplo cd bin && ls, o escribiendo cada uno en su propia línea. Dos trampas: en Windows un comando de PowerShell con varias líneas se corta tras la primera, y un comando demasiado hablador falla con un error de desbordamiento del búfer de stdout mientras no filtres su salida.
Necesitas ayuda

¿Necesitas ayuda para automatizar Execute Command con n8n?

El equipo te responde directamente.

Cada mensaje lo lee una persona.

FAQ

Execute Command en n8n, las dudas que vienen después

01¿El nodo Execute Command n8n viene incluido, en Cloud y autoalojado?
Es un nodo core, incluido con n8n: sin instalación y sin coste extra por el lado de n8n. El matiz está en dónde corre. Este nodo no está disponible en n8n Cloud. Necesitas una instancia autoalojada, con Docker o npm, en Community Edition bajo licencia Sustainable Use. Hay algo más que prever: desde n8n 2.0 el nodo viene desactivado por defecto, porque dejar que un flujo abra un shell es un riesgo real en cuanto la instancia se comparte con usuarios que no controlas. Un administrador tiene que volver a permitirlo en la instancia antes de que el nodo se ejecute.
02¿Qué hay que configurar antes de que el nodo funcione?
Nada por el lado de la cuenta. No hay credential que crear, es decir ninguna credencial que guardar en n8n, ni selector Authentication, ni token que pegar. Es uno de los pocos nodos que pones en el lienzo y arranca al momento. Lo que sí importa es la máquina anfitriona. El comando tiene que existir en el PATH del usuario que ejecuta n8n, y con Docker tiene que existir dentro del contenedor de n8n, no en la máquina de debajo. Cuando falta, el shell devuelve un error de comando no encontrado, y lo sensato es probarlo primero dentro del contenedor en marcha.
03¿Qué limitaciones tiene el nodo Execute Command?
Es un nodo pequeño: versión 1, dos parámetros y ninguna colección de opciones. Actúa sobre su anfitrión y sobre ninguna otra máquina, así que un servidor remoto queda fuera. La salida tiene techo, y un comando muy verboso provoca un error de desbordamiento del búfer de stdout, que se evita limitando o filtrando lo que imprime. En Windows, un comando de PowerShell de varias líneas pierde todo lo que va tras el primer salto: une las instrucciones con puntos y coma o lanza un archivo de script. Y el shell que te toca es el del anfitrión, nunca una opción del panel.
04¿Execute Command, HTTP Request o Ssh, cuál eliges?
Bastan dos preguntas: qué máquina y qué protocolo. Si el trabajo tiene que ocurrir fuera del anfitrión de n8n, elige Ssh, porque Execute Command no sale de su propia máquina. Si el trabajo es una llamada HTTP, elige HTTP Request, aunque el primer impulso sea escribir una línea de curl: curl no viene en la imagen oficial de n8n y tenerlo obliga a construir una imagen propia encima. Execute Command se gana su sitio cuando la herramienta es un binario o un script que ya está en el anfitrión de n8n, sin ninguna API delante.
05¿n8n o Make para lanzar scripts así?
Make está alojado por su editor, sin opción de autoalojamiento, y se factura por operación. Eso zanja el caso: sin una máquina anfitriona tuya, un comando de shell no tiene dónde correr. Lanzar comandos implica llevar tu propia instancia, que es lo que n8n permite. La decisión de fondo va más allá de este nodo: mira dónde viven los datos, cuánta plataforma quieres operar por tu cuenta y si la factura por operación o la de tu propio servidor encaja mejor con tu volumen. Make sigue siendo un buen editor visual para equipos que prefieren no gestionar infraestructura.
Hack'celeration Lab

Recibe nuestros tips de integración cada semana.

Sin spam. Cancela cuando quieras.