25 de febrero de 2026

Como instalar n8n en local con Docker (Windows): guia completa paso a paso

25 de febrero de 2026

1 min lectura

Introduccion

Si nunca has usado n8n, lo normal es tener dos dudas:

Como lo instalo sin complicarme.
Como comprobar que realmente funciona con un flujo real.

Esta guia esta pensada para resolver ambas en una sola sesion. Es una guia ejecutable en Windows para que puedas seguirla paso a paso mientras montas tu entorno local.

Objetivo de esta primera parte:

Instalar n8n en local con Docker.
Entender la diferencia entre docker run y Docker Compose.
Dejar persistencia configurada (para no perder workflows y credenciales).
Crear un primer workflow.
Probar un webhook local con un POST real.

Que es n8n

n8n es una herramienta de automatizacion visual basada en nodos. Te permite conectar triggers, APIs, transformaciones y servicios sin tener que crear cada integracion desde cero.

En la practica, un workflow de n8n suele tener esta forma:

Un trigger (Webhook, Schedule, Manual Trigger, etc.)
Uno o varios pasos de transformacion/validacion
Una accion final (guardar datos, llamar API, enviar mensaje, publicar, etc.)

Para nuestro caso futuro (publicar posts en LinkedIn), n8n sera la pieza que reciba un evento desde GitHub y ejecute la automatizacion.

Que vamos a montar exactamente en local

En esta guia montaremos n8n en Windows con Docker de dos formas:

Opcion rapida (docker run)

Buena para arrancar ya y entender el flujo.

Opcion recomendada (Docker Compose)

Mejor para mantenerlo, reiniciarlo y reutilizarlo.

En ambos casos usaremos persistencia para no perder:

workflows
credenciales
configuracion local de n8n

Requisitos (asumidos)

Asumimos que ya tienes instalado:

Docker Desktop en Windows

Y que puedes abrir:

PowerShell

Concepto clave antes de empezar: persistencia

Si ejecutas n8n sin persistencia y eliminas el contenedor, perderas tu configuracion local.

Por eso montaremos un volumen en esta ruta interna del contenedor:

/home/node/.n8n

Ese directorio guarda el estado local de n8n.

Opcion 1: instalacion rapida con `docker run` (con persistencia)

Esta es la forma mas rapida de comprobar que n8n arranca y responde en tu equipo.

Comando recomendado (PowerShell)

docker run -d `
  --name n8n-local `
  -p 5678:5678 `
  -v n8n_data:/home/node/.n8n `
  -e TZ=Europe/Madrid `
  docker.n8n.io/n8nio/n8n:latest

Que hace cada parte (importante)

-d: ejecuta el contenedor en segundo plano
--name n8n-local: nombre legible del contenedor
-p 5678:5678: expone n8n en http://localhost:5678
-v n8n_data:/home/node/.n8n: volumen persistente de Docker
-e TZ=Europe/Madrid: zona horaria (ajusta si quieres otra)
docker.n8n.io/n8nio/n8n:latest: imagen oficial

Comprobar que ha arrancado

docker ps

Deberias ver un contenedor llamado n8n-local escuchando en el puerto 5678.

Ver logs (muy util la primera vez)

docker logs -f n8n-local

Que deberias comprobar:

Que no hay errores de arranque
Que n8n queda escuchando en el puerto 5678

Para salir de los logs sin detener el contenedor:

Ctrl + C

Abrir la interfaz

Entra en:

http://localhost:5678

En el primer arranque, n8n suele pedir configuracion inicial (cuenta local / owner). Completa ese paso. Esta configuracion se conservara gracias al volumen.

Opcion 2: instalacion recomendada con `Docker Compose` (con persistencia)

Esta es la opcion que te recomiendo dejar como base para trabajar de forma recurrente.

Ventajas sobre docker run:

configuracion versionable
arranque/parada mas comodos
mas facil de ampliar luego (DB, reverse proxy, etc.)

1) Crea una carpeta de trabajo local (fuera del repo, opcional)

Por ejemplo:

C:\n8n-local

Puedes crearla desde PowerShell:

New-Item -ItemType Directory -Path C:\n8n-local -Force
Set-Location C:\n8n-local

2) Crea el archivo `docker-compose.yml`

Contenido recomendado:

services:
  n8n:
    image: docker.n8n.io/n8nio/n8n:latest
    container_name: n8n-local
    restart: unless-stopped
    ports:
      - "5678:5678"
    environment:
      TZ: Europe/Madrid
      N8N_HOST: localhost
      N8N_PORT: 5678
      N8N_PROTOCOL: http
    volumes:
      - n8n_data:/home/node/.n8n

volumes:
  n8n_data:

Si vienes de `docker run` y quieres reutilizar tus credenciales/workflows (muy recomendado)

Si ya arrancaste n8n antes con docker run usando este volumen:

n8n_data

entonces conviene decirle a Compose que reutilice ese volumen existente en vez de crear otro distinto con prefijo del proyecto.

Usa esta variante del bloque volumes:

volumes:
  n8n_data:
    external: true
    name: n8n_data

Con esto, al pasar de docker run a Docker Compose deberias conservar:

usuario/credenciales locales
workflows guardados
configuracion inicial de n8n

Si ya existe el contenedor `n8n-local` por una prueba previa con `docker run`

Antes de levantar Compose, elimina solo el contenedor (sin borrar el volumen):

docker stop n8n-local
docker rm n8n-local

Esto evita conflictos por nombre de contenedor (container_name: n8n-local).

3) Arrancar `n8n` con Compose

docker compose up -d

4) Comprobar estado

docker compose ps

5) Ver logs

docker compose logs -f n8n

Checkpoint de validacion (Compose)

Antes de seguir, deja esto en verde:

docker compose ps muestra el servicio n8n en estado running
http://localhost:5678 abre correctamente
puedes iniciar sesion con tu usuario local
(si venias de docker run) siguen apareciendo tus workflows/ajustes previos

Captura sugerida (anadir despues):

[CAPTURA] Docker Compose levantado + acceso correcto a la UI de n8n

Resumen de fase: runtime local con Docker (que has conseguido y por que)

Que has hecho

Has arrancado n8n en local con Docker.
Has probado primero docker run (arranque rapido).
Has pasado despues a Docker Compose (base mantenible).
Has conservado datos y credenciales usando persistencia (n8n_data).

Por que se configura asi

Puerto 5678: es el puerto por defecto de n8n, y mapearlo a localhost te permite acceder desde navegador y PowerShell.
Volumen n8n_data: evita perder workflows/credenciales al recrear el contenedor.
Docker Compose: deja la configuracion declarada en un archivo, mas facil de mantener y reutilizar.

Por que lanzamos esos comandos

docker compose up -d: arranca el servicio en segundo plano.
docker compose ps: verifica estado del contenedor (si realmente esta corriendo).
docker compose logs -f n8n: sirve para diagnosticar errores de arranque y confirmar que n8n escucha en el puerto correcto.

`docker run` vs `Docker Compose`: cuando usar cada uno

Usa `docker run` si…

quieres validar rapido que n8n te arranca
estas aprendiendo y quieres entender lo minimo
no quieres crear archivos aun

Usa `Docker Compose` si…

quieres dejarlo bien montado para usarlo mas veces
quieres documentarlo (como en esta guia)
vas a ampliarlo despues (MVP con webhook real, tunel, etc.)

Mi recomendacion:

prueba primero docker run si te ayuda a entenderlo
deja Docker Compose como base final local

Operaciones basicas que vas a usar mucho

Si usas `docker run`

Parar contenedor:

docker stop n8n-local

Arrancar de nuevo:

docker start n8n-local

Eliminar contenedor (sin perder datos del volumen):

docker rm -f n8n-local

Volver a crear contenedor usando el mismo volumen:

Repite el comando docker run anterior

Si usas `Docker Compose`

Parar:

docker compose down

Arrancar:

docker compose up -d

Recrear tras cambios en el YAML:

docker compose up -d --force-recreate

Primer acceso a la UI: que debes revisar

Cuando abras http://localhost:5678, revisa estas cosas:

Puedes iniciar sesion/crear usuario sin errores.
La interfaz carga de forma estable.
Puedes crear un workflow nuevo.
Al reiniciar el contenedor, la cuenta y workflows se mantienen.

Prueba rapida de persistencia (muy recomendada)

Crea un workflow vacio y guardalo con un nombre simple (prueba-persistencia).
Para el contenedor.
Arrancalo otra vez.
Comprueba que el workflow sigue ahi.

Si sigue ahi, la persistencia esta bien.

Conceptos basicos de n8n (para no ir a ciegas)

Antes de crear el primer flujo, te conviene entender 5 conceptos:

1) Workflow

Es el flujo completo (grafo de nodos) que automatiza una tarea.

2) Nodo

Cada paso del workflow:

trigger
transformacion
llamada API
salida

3) Ejecucion

Cada vez que el workflow se lanza (manual o automaticamente), n8n genera una ejecucion con entrada/salida de datos por nodo.

4) Activar workflow

Un workflow guardado no siempre esta activo. Para triggers reales (como webhooks), normalmente debes activarlo.

5) URL de test vs URL de produccion (webhooks)

En n8n, un Webhook suele tener:

URL de prueba (testing)
URL de produccion (cuando el workflow esta activo)

Esto es importante para no pensar que algo “no funciona” cuando en realidad estas usando la URL equivocada.

Primer workflow (manual): hola n8n

Vamos a crear un flujo simple para entender como pasan los datos entre nodos.

Objetivo

Lanzar manualmente un workflow
Construir un JSON de salida
Ver la ejecucion en pantalla

Pasos en la UI

En la pantalla principal, pulsa Create workflow (o New workflow).
Ponle un nombre claro, por ejemplo: 01-manual-prueba-local.
Pulsa Add first step.
Busca y añade Manual Trigger.
Añade un segundo nodo pulsando el + a la derecha del Manual Trigger.
Busca Edit Fields (en algunas versiones aparece como Set).
Conecta Manual Trigger -> Edit Fields (si no se conecta automaticamente).
En Edit Fields, crea campos como:
- source = local-test
- status = ok
- timestamp = {{ $now }}
Guarda el workflow (Ctrl + S o boton Save).
Ejecuta el workflow (Execute workflow).

Que debes observar

La ejecucion se lanza desde Manual Trigger
El nodo Edit Fields devuelve un JSON con tus valores
Puedes inspeccionar los datos de entrada/salida por nodo

Checkpoint de validacion (workflow manual)

Antes de pasar al webhook:

el workflow se guarda sin errores
la ejecucion termina en verde
ves el JSON de salida en Edit Fields
entiendes donde se inspeccionan los datos por nodo

Capturas sugeridas (anadir despues):

[CAPTURA] Canvas del workflow 01 (Manual Trigger -> Edit Fields)
[CAPTURA] Nodo Edit Fields con source/status/timestamp
[CAPTURA] Output del nodo Edit Fields con ejecucion correcta

Resumen de fase: primer workflow manual (que has conseguido y por que)

Que has hecho

Has creado tu primer workflow en n8n.
Has conectado Manual Trigger -> Edit Fields.
Has ejecutado el flujo y visto el output en la UI.

Por que este flujo es importante

Antes de usar webhooks o APIs, necesitas entender el modelo mental de n8n:

un nodo recibe datos
otro nodo los transforma
cada ejecucion deja trazabilidad visual

Este paso te da una base clara para depurar despues workflows reales.

Por que usamos `Edit Fields` (`Set`)

Es el nodo mas simple para crear y transformar datos.
Te permite ver rapidamente como n8n maneja claves/valores.
Es ideal para pruebas y para preparar payloads antes de llamar APIs.

Este paso parece simple, pero es clave para entender luego workflows mas reales.

Workflow 2: webhook local de prueba (POST real)

Ahora vamos a probar algo mas util: un Webhook local.

Objetivo

Recibir un POST en local
Ver el JSON dentro de n8n
Responder una confirmacion sencilla

Estructura del workflow

Webhook -> Edit Fields (opcional) -> Respond to Webhook

Paso a paso en la UI

1) Crear el nodo `Webhook`

Configura:

HTTP Method: POST
Path: demo-n8n-local

Guarda el nodo.

Nota:

n8n generara una URL de prueba y otra de produccion. Para esta guia usaremos primero la de prueba.

Captura sugerida (anadir despues):

[CAPTURA] Nodo Webhook configurado (POST + Path demo-n8n-local + Test URL visible)

2) (Opcional pero recomendable) Añadir `Edit Fields`

Usalo para normalizar la respuesta. Por ejemplo:

received = true
source = "powershell-local-test"
payload = {{ $json }}

3) Añadir `Respond to Webhook`

Configura una respuesta JSON sencilla. Si la UI te lo permite con respuesta personalizada, usa algo como:

ok: true
message: "Webhook recibido en local"

Si la version de la UI muestra opciones distintas, la idea es la misma:

devolver un JSON simple para confirmar que el flujo responde bien

Importante (error comun real):

El bloque de Response Body debe ser JSON valido.
Esto es incorrecto:

{
  ok = true,
  message = "Webhook recibido en local"
}

Esto es correcto:

{
  "ok": true,
  "message": "Webhook recibido en local"
}

Captura sugerida (anadir despues):

[CAPTURA] Nodo Respond to Webhook con Response Body JSON valido

4) Conectar nodos

Webhook -> Edit Fields (si lo usas) -> Respond to Webhook

Muy importante (si usas Respond to Webhook)

En el nodo Webhook, cambia el parametro:

Respond = Using Respond to Webhook Node (o equivalente)

Si lo dejas en:

Respond = Immediately

el webhook respondera antes de tiempo y el nodo Respond to Webhook mostrara un aviso (warning) indicando que no se esta usando el modo correcto.

Captura sugerida (anadir despues):

[CAPTURA] Nodo Webhook con Respond cambiado a "Using Respond to Webhook Node"

5) Guardar y preparar prueba

Guarda el workflow.
Ponle un nombre claro, por ejemplo: 02-webhook-local-prueba.
Pulsa Listen for test event (o equivalente) en el nodo Webhook.

Este paso es clave para que la URL webhook-test quede escuchando.

Captura sugerida (anadir despues):

[CAPTURA] Nodo Webhook en modo "Listen for test event"

Probar el webhook local desde PowerShell

Opcion A: usar la URL de prueba (`webhook-test`)

Con el workflow en modo escucha de prueba, lanza:

$body = @{
  event = "test_local"
  source = "powershell"
  message = "Hola desde Windows"
} | ConvertTo-Json

Invoke-RestMethod `
  -Method Post `
  -Uri "http://localhost:5678/webhook-test/demo-n8n-local" `
  -ContentType "application/json" `
  -Body $body

Validacion recomendada de respuesta HTTP (PowerShell 5.1)

En Windows PowerShell 5.1, Invoke-RestMethod a veces no muestra la respuesta como esperas o no te ayuda a diagnosticar bien el body HTTP.

Para validar de forma explicita status code + content, usa Invoke-WebRequest con -UseBasicParsing:

$body = @{
  event = "test_local"
  source = "powershell"
  message = "Hola desde Windows"
} | ConvertTo-Json

$response = Invoke-WebRequest `
  -UseBasicParsing `
  -Method Post `
  -Uri "http://localhost:5678/webhook-test/demo-n8n-local" `
  -ContentType "application/json" `
  -Body $body

$response.StatusCode
$response.Content

Resultado esperado:

200
{"ok":true,"message":"Webhook recibido en local"}

Nota:

-UseBasicParsing evita el aviso de PowerShell 5.1 sobre analisis de scripts en respuestas web.

Que deberia pasar

n8n recibe la peticion
Ves la ejecucion en la UI
PowerShell devuelve la respuesta JSON del Respond to Webhook

Ejemplo esperado de respuesta en PowerShell:

{
  "ok": true,
  "message": "Webhook recibido en local"
}

Checkpoint de validacion (webhook local)

el nodo Webhook estaba en modo escucha (Listen for test event)
PowerShell devuelve una respuesta JSON
la ejecucion aparece en n8n
puedes inspeccionar el payload recibido (event, source, message)

Nota de validacion real (muy util)

En una prueba real es normal que, si configuras Edit Fields en modo manual con tipos simples:

received te aparezca como string ("true") en vez de boolean (true)
payload te aparezca serializado como texto JSON (string) en vez de objeto

Ejemplo real de output en Edit Fields:

[
  {
    "received": "true",
    "source": "powershell-local-test",
    "payload": "{\"headers\":{\"content-type\":\"application/json\"},\"body\":{\"message\":\"Hola desde Windows\",\"source\":\"powershell\",\"event\":\"test_local\"},\"executionMode\":\"test\"}"
  }
]

Esto no es un error para esta primera prueba. De hecho, nos sirve para validar que:

el webhook recibe datos
el flujo ejecuta
podemos transformar y devolver respuesta

Ademas, en una validacion HTTP completa desde PowerShell (Invoke-WebRequest), la respuesta correcta del Respond to Webhook deberia verse asi:

200
{"ok":true,"message":"Webhook recibido en local"}

Mas adelante (en workflows reales), ya afinaremos tipos (boolean, object) y transformaciones.

Capturas sugeridas (anadir despues):

[CAPTURA] Respuesta de PowerShell tras POST al webhook-test
[CAPTURA] Ejecucion del workflow 02 en n8n
[CAPTURA] Payload recibido dentro del nodo Webhook/Edit Fields

Resumen de fase: webhook local de prueba (`webhook-test`) (que has conseguido y por que)

Que has hecho

Has creado un workflow real con Webhook -> Edit Fields -> Respond to Webhook.
Has probado una peticion POST local desde PowerShell.
Has validado recepcion del payload en n8n.
Has validado una respuesta HTTP desde Respond to Webhook.

Por que se configura `Respond to Webhook`

Si quieres controlar la respuesta HTTP (JSON, status, headers) desde el flujo:

el nodo Webhook debe delegar la respuesta
y el nodo Respond to Webhook debe devolverla al cliente

Por eso configuramos en Webhook:

Respond = Using Respond to Webhook Node

Por que usamos PowerShell para la prueba

Porque en el MVP real (#56) tambien enviaremos peticiones HTTP a n8n desde automatizaciones externas. Esta prueba ya valida:

metodo POST
payload JSON
respuesta HTTP
comportamiento del webhook en local

Por que usamos `Invoke-WebRequest -UseBasicParsing`

En Windows PowerShell 5.1:

evita el aviso de parsing de scripts
permite validar claramente StatusCode y Content
es muy util para diagnosticar si el problema esta en la recepcion o en la respuesta

Opcion B: URL de produccion (`webhook`)

Cuando el workflow este activado, la URL suele pasar a:

http://localhost:5678/webhook/demo-n8n-local

Si pruebas la URL de produccion sin activar el workflow, es normal que falle o no responda como esperas.

Como depurar si algo no funciona

Cuando falla un workflow en n8n, revisa en este orden:

Logs del contenedor

docker logs -f n8n-local

docker compose logs -f n8n

Estado del contenedor

docker ps

docker compose ps

Puerto

Que 5678 no lo este usando otra aplicacion.

URL correcta del webhook

webhook-test vs webhook

Workflow activado

Solo necesario para URL de produccion

Metodo HTTP

Si configuras POST y envias GET, no coincidira

Errores comunes en Windows (y como evitarlos)

Error 1: “No abre localhost:5678”

Causas habituales:

contenedor no iniciado
puerto ocupado
Docker Desktop no esta corriendo

Que revisar:

docker ps

Error 2: “He perdido el workflow al reiniciar”

Causa habitual:

no habia persistencia (-v o volumen en Compose)

Solucion:

recrear usando volumen persistente (n8n_data)

Error 3: El webhook “no responde”

Causas habituales:

usando URL de produccion sin activar workflow
workflow no esta en modo escucha de test
metodo HTTP incorrecto

Error 4: Cambie el compose y no veo cambios

Solucion:

docker compose up -d --force-recreate

Checklist final (deja esto en verde antes de pasar a la parte 2)

n8n arranca en http://localhost:5678
La cuenta local queda creada y persiste tras reiniciar
Entiendo la diferencia entre docker run y Docker Compose
Tengo persistencia funcionando (n8n_data)
He creado un workflow manual y lo he ejecutado
He probado un webhook local con POST desde PowerShell
Distingo webhook-test y webhook
He pasado de docker run a Docker Compose sin perder configuracion (si hice ambas pruebas)

Prueba extra (muy recomendada): `webhook-test` vs `webhook` (produccion)

Hasta ahora hemos probado la URL de test:

http://localhost:5678/webhook-test/demo-n8n-local

Esa URL solo funciona cuando el nodo Webhook esta en modo:

Listen for test event

Ahora vamos a validar la URL de produccion para entender la diferencia real.

Diferencia practica

webhook-test
- para pruebas desde el editor
- requiere Listen for test event
- no necesita activar el workflow
webhook
- pensada para uso real
- requiere workflow activo
- no usa Listen for test event

Paso a paso (URL de produccion)

1) Activa el workflow

En el workflow 02-webhook-local-prueba:

activa/publica el workflow

Nota de UI (versiones recientes de n8n):

En algunas versiones ya no aparece un toggle Active.
En su lugar aparece el boton Publish / Publish workflow.
El efecto practico es el mismo para esta guia: dejar el workflow activo para atender la Production URL.

2) Comprueba la URL de produccion

En el nodo Webhook, revisa la pestaña:

Production URL

Deberia ser algo como:

http://localhost:5678/webhook/demo-n8n-local

3) Lanza la prueba desde PowerShell (sin `Listen for test event`)

$body = @{
  event = "test_production"
  source = "powershell"
  message = "Hola desde webhook de produccion"
} | ConvertTo-Json

$response = Invoke-WebRequest `
  -UseBasicParsing `
  -Method Post `
  -Uri "http://localhost:5678/webhook/demo-n8n-local" `
  -ContentType "application/json" `
  -Body $body

$response.StatusCode
$response.Content

Resultado esperado:

200
{"ok":true,"message":"Webhook recibido en local"}

4) Verifica la ejecucion en n8n

Abre la ejecucion y comprueba que el Webhook muestra:

executionMode con contexto de produccion (no test)

Errores tipicos en esta prueba

Caso 1: `404` o webhook no encontrado

Revisa:

que el workflow este Active
que estes usando la URL webhook (no webhook-test)
que el Path coincida exactamente (demo-n8n-local)

Caso 2: no responde como esperas

Revisa:

Respond = Using Respond to Webhook Node
nodo Respond to Webhook con JSON valido

Checkpoint de validacion (test vs produccion)

He probado webhook-test con Listen for test event
He probado webhook con el workflow Active
Entiendo cuando usar cada URL

Capturas sugeridas (anadir despues):

[CAPTURA] Nodo Webhook con pestaña Test URL / Production URL
[CAPTURA] Workflow publicado/activo (boton Publish o toggle Active, segun version)
[CAPTURA] Respuesta PowerShell usando /webhook (produccion)

Resumen de fase: `webhook-test` vs `webhook` (produccion) (que has conseguido y por que)

Que has hecho

Has probado la URL de test (/webhook-test/...) con Listen for test event.
Has publicado/activado el workflow.
Has probado la URL de produccion (/webhook/...) sin Listen for test event.
Has confirmado respuesta HTTP 200 con JSON en ambos casos.

Por que esta diferencia es clave para el MVP

En el MVP con GitHub Actions, GitHub no va a pulsar un boton en tu editor de n8n.

Por tanto, necesitaremos:

un workflow activo/publicado
una Production URL estable (/webhook/...)

Esta prueba deja validado justo ese comportamiento.

Cierre

Si has seguido esta guia paso a paso, ya tienes lo importante:

n8n funcionando en local
persistencia configurada
una base mental clara de workflows, nodos y ejecuciones
y un webhook local probado de verdad

Con eso, ya no estas en modo “instalacion”. Ya estas en modo “automatizacion”.

Siguiente lectura recomendada

Si quieres continuar con el siguiente paso natural (usar este n8n local en una automatizacion real), el siguiente post de la serie sera:

MVP: auto-publicar posts del blog en LinkedIn con GitHub Actions + n8n

Resumen final de aprendizaje (esta guia)

Si quieres entender el flujo completo de forma conceptual, este es el mapa:

Infraestructura local (Docker)

Levantas n8n como servicio local y guardas estado con persistencia.

Modelo mental de workflows

Compruebas como se crean, ejecutan y depuran nodos con un flujo manual.

Recepcion de eventos (Webhook)

n8n recibe un POST JSON y lo expone como datos del workflow.

Transformacion

Edit Fields te permite normalizar/preparar payloads antes de responder o llamar APIs.

Respuesta HTTP

Respond to Webhook devuelve una respuesta controlada al cliente que llama al webhook.

Test vs Produccion

webhook-test sirve para probar en editor.
webhook sirve para automatizaciones reales con el workflow publicado.

Ese es exactamente el flujo que usaremos en la parte 2 cuando conectemos GitHub Actions con n8n para automatizar publicaciones.

¿Aplicamos esta idea en tu contexto?

Si quieres convertir este enfoque en un plan accionable para tu equipo, puedo ayudarte a definir prioridades, riesgos y siguiente iteración.

Contactar Ver más artículos

Como instalar n8n en local con Docker (Windows): guia completa paso a paso

Introduccion

Que es n8n

Que vamos a montar exactamente en local

Requisitos (asumidos)

Concepto clave antes de empezar: persistencia

Opcion 1: instalacion rapida con docker run (con persistencia)

Comando recomendado (PowerShell)

Que hace cada parte (importante)

Comprobar que ha arrancado

Ver logs (muy util la primera vez)

Abrir la interfaz

Opcion 2: instalacion recomendada con Docker Compose (con persistencia)

1) Crea una carpeta de trabajo local (fuera del repo, opcional)

2) Crea el archivo docker-compose.yml

Si vienes de docker run y quieres reutilizar tus credenciales/workflows (muy recomendado)

Si ya existe el contenedor n8n-local por una prueba previa con docker run

3) Arrancar n8n con Compose

4) Comprobar estado

5) Ver logs

Checkpoint de validacion (Compose)

Resumen de fase: runtime local con Docker (que has conseguido y por que)

Que has hecho

Por que se configura asi

Por que lanzamos esos comandos

docker run vs Docker Compose: cuando usar cada uno

Usa docker run si…

Usa Docker Compose si…

Operaciones basicas que vas a usar mucho

Si usas docker run

Si usas Docker Compose

Primer acceso a la UI: que debes revisar

Prueba rapida de persistencia (muy recomendada)

Conceptos basicos de n8n (para no ir a ciegas)

1) Workflow

2) Nodo

3) Ejecucion

4) Activar workflow

5) URL de test vs URL de produccion (webhooks)

Primer workflow (manual): hola n8n

Objetivo

Pasos en la UI

Que debes observar

Checkpoint de validacion (workflow manual)

Resumen de fase: primer workflow manual (que has conseguido y por que)

Que has hecho

Por que este flujo es importante

Por que usamos Edit Fields (Set)

Workflow 2: webhook local de prueba (POST real)

Objetivo

Estructura del workflow

Paso a paso en la UI

1) Crear el nodo Webhook

2) (Opcional pero recomendable) Añadir Edit Fields

3) Añadir Respond to Webhook

4) Conectar nodos

5) Guardar y preparar prueba

Probar el webhook local desde PowerShell

Opcion A: usar la URL de prueba (webhook-test)

Validacion recomendada de respuesta HTTP (PowerShell 5.1)

Que deberia pasar

Checkpoint de validacion (webhook local)

Nota de validacion real (muy util)

Resumen de fase: webhook local de prueba (webhook-test) (que has conseguido y por que)

Que has hecho

Por que se configura Respond to Webhook

Por que usamos PowerShell para la prueba

Por que usamos Invoke-WebRequest -UseBasicParsing

Opcion B: URL de produccion (webhook)

Como depurar si algo no funciona

Errores comunes en Windows (y como evitarlos)

Error 1: “No abre localhost:5678”

Error 2: “He perdido el workflow al reiniciar”

Error 3: El webhook “no responde”

Error 4: Cambie el compose y no veo cambios

Checklist final (deja esto en verde antes de pasar a la parte 2)

Prueba extra (muy recomendada): webhook-test vs webhook (produccion)

Diferencia practica

Paso a paso (URL de produccion)

1) Activa el workflow

Opcion 1: instalacion rapida con `docker run` (con persistencia)

Opcion 2: instalacion recomendada con `Docker Compose` (con persistencia)

2) Crea el archivo `docker-compose.yml`

Si vienes de `docker run` y quieres reutilizar tus credenciales/workflows (muy recomendado)

Si ya existe el contenedor `n8n-local` por una prueba previa con `docker run`

3) Arrancar `n8n` con Compose

`docker run` vs `Docker Compose`: cuando usar cada uno

Usa `docker run` si…

Usa `Docker Compose` si…

Si usas `docker run`

Si usas `Docker Compose`

Por que usamos `Edit Fields` (`Set`)

1) Crear el nodo `Webhook`

2) (Opcional pero recomendable) Añadir `Edit Fields`

3) Añadir `Respond to Webhook`

Opcion A: usar la URL de prueba (`webhook-test`)

Resumen de fase: webhook local de prueba (`webhook-test`) (que has conseguido y por que)

Por que se configura `Respond to Webhook`

Por que usamos `Invoke-WebRequest -UseBasicParsing`

Opcion B: URL de produccion (`webhook`)

Prueba extra (muy recomendada): `webhook-test` vs `webhook` (produccion)

3) Lanza la prueba desde PowerShell (sin `Listen for test event`)

Caso 1: `404` o webhook no encontrado

Resumen de fase: `webhook-test` vs `webhook` (produccion) (que has conseguido y por que)