25 de febrero de 2026

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

Gontzal Bilbao

25 de febrero de 2026

1 min lectura

Introducción

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 guía está pensada para resolver ambas en una sola sesión. Es una guía 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.

Qué es n8n

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

En la práctica, un workflow de n8n suele tener esta forma:

Un trigger (Webhook, Schedule, Manual Trigger, etc.)
Uno o varios pasos de transformación/validación
Una acción final (guardar datos, llamar API, enviar mensaje, publicar, etc.)

Para nuestro caso futuro (publicar posts en LinkedIn), n8n será la pieza que reciba un evento desde GitHub y ejecute la automatización.

Qué vamos a montar exactamente en local

En esta guía montaremos n8n en Windows con Docker de dos formas:

Opción rápida (docker run)

Buena para arrancar ya y entender el flujo.

Opción recomendada (Docker Compose)

Mejor para mantenerlo, reiniciarlo y reutilizarlo.

En ambos casos usaremos persistencia para no perder:

workflows
credenciales
configuración 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 configuración local.

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

/home/node/.n8n

Ese directorio guarda el estado local de n8n.

Opción 1: instalación rápida con `docker run` (con persistencia)

Esta es la forma más rápida 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

Qué 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

Deberías ver un contenedor llamado n8n-local escuchando en el puerto 5678.

Ver logs (muy útil la primera vez)

docker logs -f n8n-local

Que deberías 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 configuración inicial (cuenta local / owner). Completa ese paso. Esta configuración se conservará gracias al volumen.

Opción 2: instalación recomendada con `Docker Compose` (con persistencia)

Esta es la opción que te recomiendo dejar como base para trabajar de forma recurrente.

Ventajas sobre docker run:

configuración versionable
arranque/parada más comodos
más fácil 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 deberías conservar:

usuario/credenciales locales
workflows guardados
configuración 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 validación (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 sesión con tu usuario local
(si venias de docker run) siguen apareciendo tus workflows/ajustes previos

Captura sugerida (añadir después):

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

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

Qué has hecho

Has arrancado n8n en local con Docker.
Has probado primero docker run (arranque rápido).
Has pasado después a Docker Compose (base mantenible).
Has conservado datos y credenciales usando persistencia (n8n_data).

Por qué se configura así

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 configuración declarada en un archivo, más fácil de mantener y reutilizar.

Por qué lanzamos esos comandos

docker compose up -d: arranca el servicio en segundo plano.
docker compose ps: verifica estado del contenedor (si realmente está 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 rápido que n8n te arranca
estás aprendiendo y quieres entender lo mínimo
no quieres crear archivos aún

Usa `Docker Compose` si…

quieres dejarlo bien montado para usarlo más veces
quieres documentarlo (como en esta guía)
vas a ampliarlo después (MVP con webhook real, túnel, etc.)

Mi recomendación:

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

Operaciones básicas 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 sesión/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 rápida 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 ahí.

Si sigue ahí, la persistencia está bien.

Conceptos básicos 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
transformación
llamada API
salida

3) Ejecución

Cada vez que el workflow se lanza (manual o automáticamente), n8n genera una ejecución con entrada/salida de datos por nodo.

4) Activar workflow

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

5) URL de test vs URL de producción (webhooks)

En n8n, un Webhook suele tener:

URL de prueba (testing)
URL de producción (cuando el workflow está activo)

Esto es importante para no pensar que algo “no funciona” cuando en realidad estás 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 ejecución 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 automáticamente).
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).

Qué debes observar

La ejecución 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 validación (workflow manual)

Antes de pasar al webhook:

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

Capturas sugeridas (añadir después):

[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)

Qué 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 qué 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 ejecución deja trazabilidad visual

Este paso te da una base clara para depurar después workflows reales.

Por qué usamos `Edit Fields` (`Set`)

Es el nodo más simple para crear y transformar datos.
Te permite ver rápidamente 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 más reales.

Workflow 2: webhook local de prueba (POST real)

Ahora vamos a probar algo más útil: un Webhook local.

Objetivo

Recibir un POST en local
Ver el JSON dentro de n8n
Responder una confirmación 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 producción. Para esta guía usaremos primero la de prueba.

Captura sugerida (añadir después):

[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 versión de la UI muestra opciones distintas, la idea es la misma:

devolver un JSON simple para confirmar que el flujo responde bien

Importante (error común real):

El bloque de Response Body debe ser JSON válido.
Esto es incorrecto:

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

Esto es correcto:

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

Captura sugerida (añadir después):

[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 parámetro:

Respond = Using Respond to Webhook Node (o equivalente)

Si lo dejas en:

Respond = Immediately

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

Captura sugerida (añadir después):

[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 (añadir después):

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

Probar el webhook local desde PowerShell

Opción 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

Validación 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 análisis de scripts en respuestas web.

Qué debería pasar

n8n recibe la petición
Ves la ejecución 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 validación (webhook local)

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

Nota de validación real (muy útil)

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

Además, en una validación HTTP completa desde PowerShell (Invoke-WebRequest), la respuesta correcta del Respond to Webhook debería verse así:

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

Más adelante (en workflows reales), ya afinaremos tipos (boolean, object) y transformaciones.

Capturas sugeridas (añadir después):

[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)

Qué has hecho

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

Por qué 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 qué usamos PowerShell para la prueba

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

método POST
payload JSON
respuesta HTTP
comportamiento del webhook en local

Por qué usamos `Invoke-WebRequest -UseBasicParsing`

En Windows PowerShell 5.1:

evita el aviso de parsing de scripts
permite validar claramente StatusCode y Content
es muy útil para diagnosticar si el problema está en la recepción o en la respuesta

Opción B: URL de producción (`webhook`)

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

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

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

Cómo 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 aplicación.

URL correcta del webhook

webhook-test vs webhook

Workflow activado

Solo necesario para URL de producción

Método HTTP

Si configuras POST y envias GET, no coincidirá

Errores comunes en Windows (y como evitarlos)

Error 1: “No abre localhost:5678”

Causas habituales:

contenedor no iniciado
puerto ocupado
Docker Desktop no está corriendo

Que revisar:

docker ps

Error 2: “He perdido el workflow al reiniciar”

Causa habitual:

no había persistencia (-v o volumen en Compose)

Solución:

recrear usando volumen persistente (n8n_data)

Error 3: El webhook “no responde”

Causas habituales:

usando URL de producción sin activar workflow
workflow no está en modo escucha de test
método HTTP incorrecto

Error 4: Cambie el compose y no veo cambios

Solución:

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 configuración (si hice ambas pruebas)

Prueba extra (muy recomendada): `webhook-test` vs `webhook` (producción)

Hasta ahora hemos probado la URL de test:

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

Esa URL solo funciona cuando el nodo Webhook está en modo:

Listen for test event

Ahora vamos a validar la URL de producción para entender la diferencia real.

Diferencia práctica

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 producción)

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 práctico es el mismo para esta guía: dejar el workflow activo para atender la Production URL.

2) Comprueba la URL de producción

En el nodo Webhook, revisa la pestaña:

Production URL

Debería 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 ejecución en n8n

Abre la ejecución y comprueba que el Webhook muestra:

executionMode con contexto de producción (no test)

Errores típicos 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 válido

Checkpoint de validación (test vs producción)

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

Capturas sugeridas (añadir después):

[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` (producción) (que has conseguido y por que)

Qué 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 producción (/webhook/...) sin Listen for test event.
Has confirmado respuesta HTTP 200 con JSON en ambos casos.

Por qué 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 guía 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 estás en modo “instalación”. Ya estás en modo “automatización”.

Siguiente lectura recomendada

Si quieres continuar con el siguiente paso natural (usar este n8n local en una automatización real), el siguiente post de la serie será:

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

Resumen final de aprendizaje (esta guía)

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.

Recepción de eventos (Webhook)

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

Transformación

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 Producción

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

Gontzal Bilbao

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

Introducción

Qué es n8n

Qué vamos a montar exactamente en local

Requisitos (asumidos)

Concepto clave antes de empezar: persistencia

Opción 1: instalación rápida con docker run (con persistencia)

Comando recomendado (PowerShell)

Qué hace cada parte (importante)

Comprobar que ha arrancado

Ver logs (muy útil la primera vez)

Abrir la interfaz

Opción 2: instalación 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 validación (Compose)

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

Qué has hecho

Por qué se configura así

Por qué lanzamos esos comandos

docker run vs Docker Compose: cuando usar cada uno

Usa docker run si…

Usa Docker Compose si…

Operaciones básicas que vas a usar mucho

Si usas docker run

Si usas Docker Compose

Primer acceso a la UI: que debes revisar

Prueba rápida de persistencia (muy recomendada)

Conceptos básicos de n8n (para no ir a ciegas)

1) Workflow

2) Nodo

3) Ejecución

4) Activar workflow

5) URL de test vs URL de producción (webhooks)

Primer workflow (manual): hola n8n

Objetivo

Pasos en la UI

Qué debes observar

Checkpoint de validación (workflow manual)

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

Qué has hecho

Por qué este flujo es importante

Por qué 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

Opción A: usar la URL de prueba (webhook-test)

Validación recomendada de respuesta HTTP (PowerShell 5.1)

Qué debería pasar

Checkpoint de validación (webhook local)

Nota de validación real (muy útil)

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

Qué has hecho

Por qué se configura Respond to Webhook

Por qué usamos PowerShell para la prueba

Por qué usamos Invoke-WebRequest -UseBasicParsing

Opción B: URL de producción (webhook)

Cómo 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 (producción)

Diferencia práctica

Paso a paso (URL de producción)

Opción 1: instalación rápida con `docker run` (con persistencia)

Opción 2: instalación 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 qué usamos `Edit Fields` (`Set`)

1) Crear el nodo `Webhook`

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

3) Añadir `Respond to Webhook`

Opción A: usar la URL de prueba (`webhook-test`)

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

Por qué se configura `Respond to Webhook`

Por qué usamos `Invoke-WebRequest -UseBasicParsing`

Opción B: URL de producción (`webhook`)

Prueba extra (muy recomendada): `webhook-test` vs `webhook` (producción)

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` (producción) (que has conseguido y por que)