Variables de Entorno n8n: Configuración Completa y Segura

Imaginate que llevás horas configurando tus flujos de automatización en n8n, todo parece andar perfecto en tu máquina local, y cuando lo subís a producción… los webhooks no funcionan, las credenciales se pierden y la

Written by: Luis Hernandez

Published on: noviembre 10, 2025

elevenlabs

Imaginate que llevás horas configurando tus flujos de automatización en n8n, todo parece andar perfecto en tu máquina local, y cuando lo subís a producción… los webhooks no funcionan, las credenciales se pierden y la zona horaria está completamente desquiciada. ¿Te suena familiar? La realidad es que el 90% de esos problemas se resuelven entendiendo bien las variables de entorno n8n y configurándolas como corresponde desde el primer momento.

En esta guía completa vas a aprender a dominar cada variable de entorno n8n que importa: desde la configuración básica del host hasta opciones avanzadas de seguridad, base de datos y rendimiento. Todo explicado con ejemplos reales que podés copiar y adaptar a tu instalación, ya sea con Docker, npm o plataformas cloud. Sin rodeos ni relleno, vamos directo al grano.

Conceptos base: ¿Qué son las variables de entorno n8n y para qué sirven?

Antes de meternos de lleno en la configuración, vale la pena aclarar qué son exactamente las variables de entorno n8n para los que recién arrancan. En términos simples, son parámetros de configuración que le dicen a n8n cómo comportarse cuando se ejecuta. En vez de tocar archivos de código fuente o meterte en configuraciones complicadas dentro del programa, simplemente definís estas variables y n8n las lee al iniciar.

Pensalo así: es como los ajustes de un electrodoméstico. No necesitás abrir la máquina para cambiar la temperatura — usás los botones externos. Las variables de entorno son esos «botones» para n8n. Controlan absolutamente todo: el dominio donde corre tu instancia, qué base de datos usa, cómo cifra las credenciales, qué zona horaria maneja, cuántas ejecuciones guarda en el historial, y mucho más.

En el ecosistema de n8n existen más de 80 variables de entorno documentadas en la documentación oficial de n8n. No necesitás conocerlas todas, pero sí las críticas. Se dividen en varias categorías principales:

  • Configuración de red: host, puerto, protocolo (HTTP/HTTPS)
  • Base de datos: tipo de DB, host, credenciales, esquema
  • Seguridad y cifrado: clave de encriptación, autenticación básica, JWT
  • Ejecuciones: historial, modo de ejecución, tiempo máximo
  • Logs y depuración: nivel de log, salida
  • Cola de trabajos: integración con Redis para modo queue
  • Permisos de acceso: bloqueo de variables en nodos, restricciones

Nota: Sin configurar correctamente las variables de entorno n8n, te vas a encontrar con webhooks rotos que apuntan a localhost, credenciales almacenadas sin cifrado adecuado, problemas de zona horaria en los triggers programados y una base de datos SQLite que se vuelve inmanejable con el tiempo. Básicamente, es la diferencia entre una instalación profesional y un desastre esperando a pasar.

Si todavía no tenés n8n instalado o querés repasar lo básico, te recomiendo primero revisar la guía completa en español para automatizar desde cero y después volvé acá para dejar todo bien configurado.

Conceptos base: ¿Qué son las variables de entorno n8n y para qué sirven?

¿Dónde se configuran las variables de entorno n8n?

Dependiendo de cómo hayas instalado n8n, las variables de entorno n8n se configuran en diferentes lugares. Es fundamental que sepas cuál aplica a tu caso para no perder tiempo buscando dónde va cada cosa:

  • Docker Compose: en el bloque environment del servicio o en un archivo .env separado que referenciás con env_file
  • Docker run: con flags -e VARIABLE=valor directamente en la línea de comandos
  • npm (instalación global): en el archivo ~/.n8n/.env o exportándolas en la sesión del terminal con export VARIABLE=valor
  • Railway / Render / Coolify: en la sección «Variables» o «Environment» del dashboard de cada plataforma

Tip: La forma más recomendada y segura es usar un archivo .env separado. De esta manera no mezclás contraseñas con la configuración de Docker Compose, y podés agregar el archivo a tu .gitignore para no subir datos sensibles al repositorio. Es una buena práctica que te va a ahorrar dolores de cabeza serios.

Un archivo .env típico para n8n se ve así:

# Archivo .env para variables de entorno n8n
N8N_HOST=n8n.tudominio.com
N8N_PORT=5678
N8N_PROTOCOL=https
N8N_ENCRYPTION_KEY=tu_clave_segura_de_32_caracteres
DB_TYPE=postgresdb
GENERIC_TIMEZONE=America/Mexico_City

Y en tu docker-compose.yml lo referenciás de esta forma:

services:
  n8n:
    image: n8nio/n8n
    env_file: .env
    ports:
      - "5678:5678"
    volumes:
      - n8n_data:/home/node/.n8n

Algo que mucha gente no sabe: n8n también lee un archivo de configuración en ~/.n8n/config en formato JSON. Sin embargo, las variables de entorno siempre tienen prioridad sobre ese archivo. Así que si definís algo en ambos lugares, gana la variable de entorno. Esto es clave para no confundirte cuando algo no funciona como esperabas.

Variables de entorno n8n: configuración de red y host

Las primeras variables que necesitás configurar son las de red. Estas le dicen a n8n cuál es su dirección pública, en qué puerto escuchar y qué protocolo usar. Si no las configurás bien, tus webhooks van a apuntar a localhost:5678 y cualquier servicio externo que intente comunicarse con tu instancia va a fallar miserablemente.

# Variables de red esenciales
N8N_HOST=n8n.tudominio.com
N8N_PORT=5678
N8N_PROTOCOL=https
WEBHOOK_URL=https://n8n.tudominio.com/

Acá va el detalle de cada una:

  • N8N_HOST: el dominio o IP pública donde corre tu n8n. Esto es lo que n8n usa para generar las URLs de webhooks. Si lo dejás en blanco, usa localhost y nada externo va a funcionar.
  • N8N_PORT: el puerto interno donde escucha n8n (por defecto 5678). Si usás un reverse proxy como Nginx o Caddy, este puerto solo necesita ser accesible internamente.
  • N8N_PROTOCOL: puede ser http o https. Siempre usá https en producción.
  • WEBHOOK_URL: sobreescribe la URL base de los webhooks. Útil si tu n8n está detrás de un proxy inverso con una URL diferente.

Importante: La variable N8N_HOST (también referenciada en queries como n8n_host environment variable) es probablemente la más crítica de todas. Si la dejás sin configurar o con un valor incorrecto, absolutamente todos tus webhooks van a generar URLs inaccesibles. Es el error número uno que cometen los principiantes al desplegar n8n.

Configuración de base de datos con variables de entorno

Por defecto, n8n usa SQLite como base de datos. Funciona bien para pruebas y proyectos chiquitos, pero para producción real necesitás migrar a PostgreSQL o MySQL. La variable DB_TYPE (que seguramente ya viste si buscaste n8n environment variables db_type) es la que controla esto.

# Configuración para PostgreSQL
DB_TYPE=postgresdb
DB_POSTGRESDB_HOST=localhost
DB_POSTGRESDB_PORT=5432
DB_POSTGRESDB_DATABASE=n8n
DB_POSTGRESDB_USER=n8n_user
DB_POSTGRESDB_PASSWORD=tu_password_seguro
DB_POSTGRESDB_SCHEMA=public

Si preferís MySQL o MariaDB, las variables cambian un poco:

# Configuración para MySQL/MariaDB
DB_TYPE=mysqldb
DB_MYSQLDB_HOST=localhost
DB_MYSQLDB_PORT=3306
DB_MYSQLDB_DATABASE=n8n
DB_MYSQLDB_USER=n8n_user
DB_MYSQLDB_PASSWORD=tu_password_seguro

¿Por qué importa tanto esto? SQLite guarda todo en un solo archivo y no maneja bien la concurrencia. Si tenés varios workflows ejecutándose al mismo tiempo (algo totalmente normal en producción), SQLite se puede bloquear o corromper. PostgreSQL, en cambio, está diseñado para manejar miles de conexiones simultáneas sin problemas. Si querés profundizar en cómo conectar n8n con PostgreSQL, revisá la guía de n8n con PostgreSQL donde se explica el proceso completo.

Tip: Si estás usando Docker Compose, podés levantar PostgreSQL como un servicio adicional en el mismo archivo y conectarlos por la red interna de Docker. Así no necesitás exponer el puerto de la base de datos al exterior, lo que mejora la seguridad considerablemente.

Variables de entorno n8n para seguridad y cifrado

La seguridad es donde muchos se la juegan. Las variables de entorno n8n relacionadas con seguridad protegen tus credenciales almacenadas, controlan quién puede acceder a la interfaz y definen qué pueden hacer los nodos dentro de los workflows.

N8N_ENCRYPTION_KEY: la variable más importante

Esta variable define la clave con la que n8n cifra todas las credenciales que almacenás (tokens de API, contraseñas de servicios, etc.). Si no la definís, n8n genera una automáticamente y la guarda en ~/.n8n/.n8n_encryption_key. El problema es que si perdés ese archivo (cosa que pasa fácilmente con Docker si no montás los volúmenes correctamente), perdés TODAS tus credenciales sin posibilidad de recuperarlas.

# Clave de cifrado — NUNCA la pierdas
N8N_ENCRYPTION_KEY=una_clave_muy_segura_de_al_menos_32_caracteres_aleatorios

Importante: Generá una clave aleatoria fuerte. Podés usar openssl rand -hex 32 en tu terminal para generar una clave segura. Guardala en un lugar seguro fuera de tu servidor (un gestor de contraseñas, por ejemplo). Si alguna vez necesitás migrar tu instancia a otro servidor, esta clave es lo que te permite llevar todas tus credenciales sin tener que reconfigurar cada una manualmente.

Autenticación y control de acceso

Hay varias variables que controlan quién puede entrar a tu instancia de n8n:

# Autenticación básica (versiones anteriores)
N8N_BASIC_AUTH_ACTIVE=true
N8N_BASIC_AUTH_USER=admin
N8N_BASIC_AUTH_PASSWORD=tu_password_seguro

# Para versiones recientes con user management
N8N_USER_MANAGEMENT_DISABLED=false

La variable N8N_BASIC_AUTH_ACTIVE (que aparece en búsquedas como n8n_basic_auth_active env var) activa la autenticación básica HTTP. Es el método más simple pero efectivo para proteger tu instancia si no querés configurar el sistema de usuarios completo. En versiones más nuevas de n8n, el sistema de gestión de usuarios viene habilitado por defecto y es la opción recomendada.

N8N_BLOCK_ENV_ACCESS_IN_NODE: configuración de seguridad avanzada

Esta es una variable que pocos conocen pero que es crucial para la seguridad. N8N_BLOCK_ENV_ACCESS_IN_NODE controla si los nodos de código (Function, Code) pueden acceder a las variables de entorno del sistema operativo. Por defecto está en false, lo que significa que cualquier workflow con un nodo de código puede leer todas las variables de entorno, incluyendo contraseñas de base de datos y claves de cifrado.

# Bloquear acceso a variables de entorno desde nodos de código
N8N_BLOCK_ENV_ACCESS_IN_NODE=true

Nota: Si tu instancia de n8n es compartida con otros usuarios o si importás workflows de terceros, activá esta variable sin dudarlo. Un workflow malicioso podría usar un nodo Function para leer process.env y extraer todas tus claves. Con N8N_BLOCK_ENV_ACCESS_IN_NODE=true esto se bloquea completamente.

Variables de entorno n8n para seguridad y cifrado

Zona horaria, ejecuciones y rendimiento

Otro grupo de variables de entorno n8n que necesitás configurar bien son las que controlan el comportamiento de las ejecuciones y la zona horaria. Estas afectan directamente cómo funcionan tus triggers programados y cuánta información histórica guarda tu instancia.

# Zona horaria
GENERIC_TIMEZONE=America/Buenos_Aires

# Configuración de ejecuciones
EXECUTIONS_MODE=regular
EXECUTIONS_TIMEOUT=300
EXECUTIONS_TIMEOUT_MAX=600
EXECUTIONS_DATA_SAVE_ON_ERROR=all
EXECUTIONS_DATA_SAVE_ON_SUCCESS=none
EXECUTIONS_DATA_SAVE_MANUAL_EXECUTIONS=true
EXECUTIONS_DATA_MAX_AGE=168

GENERIC_TIMEZONE es esencial para que tus Cron triggers se ejecuten a la hora correcta. Si estás en México usá America/Mexico_City, si estás en Argentina America/Buenos_Aires, Colombia America/Bogota, etc. Sin esta variable, n8n usa UTC y tus automatizaciones programadas van a ejecutarse a horas completamente distintas de las que esperás.

Las variables de ejecuciones son importantes para el rendimiento a largo plazo. Si guardás los datos de todas las ejecuciones exitosas (EXECUTIONS_DATA_SAVE_ON_SUCCESS=all), tu base de datos va a crecer rápidamente y todo se va a poner lento. La configuración que te muestro arriba guarda solo los errores completos y limpia datos después de 168 horas (7 días). Es un buen balance entre tener información para depurar y no saturar el storage.

Tip: Si usás triggers programados con Cron, te conviene leer la guía de n8n Cron Schedule donde se explica cómo interactúa la zona horaria con la programación de tareas.

Archivo .env completo: configuración de variables de entorno n8n lista para producción

Acá te dejo un archivo .env completo que podés usar como plantilla para tu instalación de producción. Incluye las variables de entorno n8n más importantes organizadas por categoría. Solo tenés que cambiar los valores por los tuyos:

# ================================
# VARIABLES DE ENTORNO N8N - PRODUCCIÓN
# ================================

# --- Red y Host ---
N8N_HOST=n8n.tudominio.com
N8N_PORT=5678
N8N_PROTOCOL=https
WEBHOOK_URL=https://n8n.tudominio.com/
N8N_EDITOR_BASE_URL=https://n8n.tudominio.com/

# --- Base de datos (PostgreSQL) ---
DB_TYPE=postgresdb
DB_POSTGRESDB_HOST=db
DB_POSTGRESDB_PORT=5432
DB_POSTGRESDB_DATABASE=n8n
DB_POSTGRESDB_USER=n8n_user
DB_POSTGRESDB_PASSWORD=cambiame_por_password_seguro
DB_POSTGRESDB_SCHEMA=public

# --- Seguridad ---
N8N_ENCRYPTION_KEY=genera_tu_clave_con_openssl_rand_hex_32
N8N_BLOCK_ENV_ACCESS_IN_NODE=true

# --- Zona horaria ---
GENERIC_TIMEZONE=America/Mexico_City

# --- Ejecuciones ---
EXECUTIONS_MODE=regular
EXECUTIONS_TIMEOUT=300
EXECUTIONS_DATA_SAVE_ON_ERROR=all
EXECUTIONS_DATA_SAVE_ON_SUCCESS=none
EXECUTIONS_DATA_MAX_AGE=168

# --- Logs ---
N8N_LOG_LEVEL=info
N8N_LOG_OUTPUT=console

# --- Variables personalizadas ($vars) ---
# Se configuran desde la UI en Settings > Variables

Este archivo cubre el 95% de los casos de uso en producción. Si necesitás algo más específico (como modo queue con Redis para alta disponibilidad), la documentación oficial tiene todas las opciones adicionales.

Variables personalizadas ($vars) vs variables de entorno del sistema

Hay una confusión muy común entre las variables de entorno del sistema operativo (las que venimos hablando) y las variables personalizadas de n8n que se acceden con $vars en los workflows. Son cosas completamente diferentes y es importante entender la distinción.

Las variables de entorno del sistema (N8N_HOST, DB_TYPE, etc.) configuran cómo se comporta n8n como aplicación. Se definen antes de que n8n arranque y no se pueden cambiar desde la interfaz web.

Las variables personalizadas ($vars) son valores que vos definís desde la UI de n8n (Settings > Variables) y que podés usar dentro de tus workflows con expresiones como {{ $vars.mi_variable }}. Son ideales para guardar valores que cambian entre ambientes (URLs de API, nombres de proyecto, configuraciones específicas) sin hardcodearlos en cada nodo.

// Ejemplo de uso de $vars en un nodo Code
const apiUrl = $vars.API_BASE_URL;
const apiKey = $vars.API_KEY;

const response = await fetch(`${apiUrl}/endpoint`, {
  headers: { 'Authorization': `Bearer ${apiKey}` }
});

Nota: Las $vars son visibles para cualquier usuario que tenga acceso a los workflows. No las uses para almacenar secretos como contraseñas o tokens de API sensibles — para eso están las credenciales de n8n, que se cifran con la N8N_ENCRYPTION_KEY que configuraste antes.

Errores comunes al configurar variables de entorno n8n

Después de ayudar a decenas de personas a configurar sus instancias, estos son los errores más frecuentes que veo con las variables de entorno n8n:

  1. No definir N8N_HOST o dejarlo en localhost: Todos los webhooks generados van a apuntar a http://localhost:5678 y ningún servicio externo va a poder contactar tu n8n.
  2. Perder la N8N_ENCRYPTION_KEY: Si recreás el contenedor Docker sin montar el volumen correcto y no tenés la clave definida como variable de entorno, perdés todas las credenciales almacenadas.
  3. No configurar GENERIC_TIMEZONE: Los cron triggers se ejecutan en UTC y tus automatizaciones de las 9 AM se disparan a las 3 AM o a las 2 PM dependiendo de tu zona.
  4. Espacios en los valores del archivo .env: Algo como N8N_HOST = mi.dominio.com (con espacios alrededor del =) puede causar errores silenciosos. Siempre usá N8N_HOST=mi.dominio.com sin espacios.
  5. Usar SQLite en producción con muchos workflows: No configurar DB_TYPE para usar PostgreSQL cuando tu instancia tiene más de 10-15 workflows activos es buscar problemas de rendimiento.

Importante: Siempre verificá que tus variables se cargaron correctamente. Podés hacerlo entrando al contenedor con docker exec -it n8n sh y ejecutando env | grep N8N para ver todas las variables de entorno n8n que están activas. Si alguna no aparece, hay un problema en cómo la estás definiendo.

Errores comunes al configurar variables de entorno n8n

Preguntas frecuentes sobre variables de entorno n8n

¿Cómo configuro el archivo .env para n8n en Docker?

Creá un archivo llamado .env en la misma carpeta que tu docker-compose.yml con todas las variables que necesitás (una por línea, formato VARIABLE=valor). Luego agregá env_file: .env en la sección del servicio n8n dentro del docker-compose. Al hacer docker compose up, Docker va a inyectar automáticamente todas las variables de entorno n8n definidas en ese archivo.

¿Qué pasa si no defino N8N_ENCRYPTION_KEY?

Si no definís esta variable, n8n genera una clave automáticamente y la guarda en el archivo ~/.n8n/.n8n_encryption_key. El riesgo es que si perdés ese archivo (por ejemplo, al recrear un contenedor Docker sin volúm

Resumir con:
ChatGPT Claude Google AI Grok Perplexity
Banner de descuento en hosting

Previous

n8n en Railway Gratis: Cómo Desplegarlo Paso a Paso

Next

Agente IA n8n: Cómo Crear Uno desde Cero [Guía 2026]