Horas incorrectas en n8n: configurar correctamente UTC, GENERIC_TIMEZONE y Cron
De forma predeterminada, n8n se ejecuta en America/New_York en lugar de Europe/Berlin. Así se configura correctamente GENERIC_TIMEZONE y la zona horaria del workflow.
Las variables de entorno de n8n más relevantes en la práctica para instalaciones autoalojadas alemanas: host, URL de webhook, zona horaria, seguridad y base de datos de un vistazo.
Quien aloja por sí mismo una instancia de n8n configura ajustes centrales como la accesibilidad, la zona horaria, la base de datos y la seguridad no a través de la interfaz, sino mediante variables de entorno que se establecen al iniciar el contenedor o el proceso. De las más de cien variables documentadas, solo un puñado son realmente decisivas para la mayoría de las instalaciones autoalojadas alemanas, por ejemplo N8N_HOST para el nombre de host, WEBHOOK_URL para el acceso público detrás de un reverse proxy o GENERIC_TIMEZONE para que los workflows programados se disparen a la hora correcta. Este artículo ordena las variables más relevantes en la práctica por área temática y muestra en cada caso un ejemplo de uso. Fecha: julio de 2026.
Estas variables determinan cómo es accesible n8n interna y externamente, y en qué zona horaria se ejecutan los workflows programados.
Especialmente para empresas para las que la soberanía de datos alemana y el control sobre sus propios datos son importantes, vale la pena echar un vistazo detallado a las variables relevantes para la seguridad.
Para la operación productiva, la mayoría de las instalaciones cambian de la base de datos SQLite incluida a PostgreSQL, lo cual se configura mediante variables propias.
La mayoría de los problemas al autoalojar n8n no surgen por variables faltantes, sino por URLs mal configuradas o una zona horaria que no coincide con la ubicación del servidor. Quien quiera configurar, proteger o migrar su propia instancia de n8n a Postgres, encuentra en los servicios de n8n de NordFlux apoyo para la configuración y puesta en marcha.
Depende del tipo de instalación. Con Docker esto se hace mediante flags -e o un archivo .env en el docker-compose.yml, con una instalación clásica como variables de entorno del sistema que se establecen antes de iniciar el proceso n8n.
n8n genera entonces automáticamente una clave aleatoria en el primer inicio. Si esta se pierde, por ejemplo durante una reconstrucción del contenedor sin almacenamiento persistente, las credenciales ya guardadas ya no se pueden descifrar.
Solo si n8n se ejecuta detrás de un reverse proxy o bajo una dirección pública diferente a la configurada internamente. Con acceso directo a través de N8N_HOST y N8N_PORT, la variable normalmente no es necesaria.
Sí, la mayoría de las variables solo surten efecto tras reiniciar el proceso n8n. Los workflows en ejecución y los datos ya guardados no se ven afectados, siempre que la conexión a la base de datos no cambie.
Más detalles sobre todas las variables documentadas se encuentran en la documentación de n8n sobre variables de entorno así como específicamente sobre la configuración de la base de datos.
NordFlux crea empleados digitales para las organizaciones: automatizaciones y agentes KI que asumen el trabajo repetitivo. Usted mantiene el control.
De forma predeterminada, n8n se ejecuta en America/New_York en lugar de Europe/Berlin. Así se configura correctamente GENERIC_TIMEZONE y la zona horaria del workflow.
¿Webhook de n8n funciona en pruebas pero está en silencio en producción? Así encuentra la causa: activación, WEBHOOK_URL, conflictos de ruta.
¿La redirección OAuth de n8n apunta a localhost? Así se soluciona redirect_uri_mismatch con N8N_HOST y WEBHOOK_URL.
Variables mal configuradas como WEBHOOK_URL o GENERIC_TIMEZONE suelen pasar desapercibidas hasta que los webhooks fallan o los cron jobs se ejecutan a la hora equivocada. Con el hosting gestionado de n8n de NordFlux, la configuración queda documentada y probada desde el principio. También revisamos instancias existentes en busca de valores por defecto arriesgados.