n8n autoalojado en producción: las cuatro cosas que se rompen

Casi todas las instalaciones de n8n que nos piden revisar empezaron igual: alguien levantó la imagen de Docker en una VM que sobraba, montó tres flujos que ahorraban una tarde a la semana al equipo, y luego se enteraron otras veinte personas. Seis meses después sostiene el procesado de facturas y nadie sabe dónde viven las credenciales.

La herramienta está bien. El problema es el contenedor único. Esto es lo que cambia cuando una plataforma de automatización deja de ser un proyecto paralelo.

1. Modo cola, o un flujo lento para a todos

Por defecto n8n ejecuta todo en un solo proceso. Un flujo que espera noventa segundos a una API lenta son noventa segundos en los que tus webhooks hacen cola detrás, y un nodo con una fuga de memoria se lleva el editor por delante.

El modo cola parte eso en una instancia principal que sirve la interfaz y los webhooks, una cola en Redis y procesos worker que ejecutan. Pon EXECUTIONS_MODE=queue, apunta QUEUE_BULL_REDIS_HOST a un Redis gestionado y levanta dos o más workers. La primera consecuencia es que escalas los workers sin tocar el editor. La segunda, menos evidente, es que la caída de un worker ya no echa a todo el mundo de la sesión.

Dale a los workers un límite de concurrencia acorde con lo que toleran las APIs de destino, no con lo que permite la CPU. La mayoría de incidentes que vemos en n8n no son n8n fallando: son n8n acertando treinta veces por segundo contra una API que limita a cinco.

2. Postgres, y la tabla de ejecuciones que se come el disco

SQLite es el valor por defecto y es el valor equivocado para cualquier cosa compartida. Múdate a Postgres antes de tener datos que te importen, porque la migración es una exportación y reimportación de credenciales que no le gusta a nadie.

Después configura el purgado. EXECUTIONS_DATA_PRUNE, EXECUTIONS_DATA_MAX_AGE y EXECUTIONS_DATA_PRUNE_MAX_COUNT existen porque el registro de ejecuciones guarda el payload completo de cada nodo, y un flujo que mueve documentos guardará esos documentos. Hemos visto una tabla de ejecuciones de 400 GB en una empresa cuyos datos de negocio reales no llegaban a dos gigas. Guarda entre catorce y treinta días, y pon EXECUTIONS_DATA_SAVE_ON_SUCCESS=none en los flujos de mucho volumen donde solo te importan los fallos.

3. Las credenciales son la joya de la corona, y se cifran con una sola clave

n8n cifra las credenciales guardadas con N8N_ENCRYPTION_KEY. Si esa clave se genera en el primer arranque y vive solo en el volumen del contenedor, tu copia de seguridad no sirve de nada sin ella y tu plan de recuperación es ficción.

Fija la clave explícitamente desde tu gestor de secretos, igual que harías con la contraseña de una base de datos. Y trata la instancia como un sistema de producción con acceso a todas las cuentas SaaS de la empresa, porque es exactamente lo que es: una instancia de n8n en una empresa mediana suele guardar tokens del CRM, del proveedor de correo, de la contabilidad, del almacén de datos y de una cuenta cloud. Comprometer el editor es comprometerlos todos, y por eso el editor no debería estar en internet sin SSO delante, y por eso el radio de acción de lo que un agente puede tocar merece una sesión de diseño propia.

4. Los flujos son código, y no están en git

El editor es una base de datos, y eso significa sin diffs, sin revisión y sin vuelta atrás. El arreglo es aburrido: exporta los flujos a JSON, haz commit y promociona entre una instancia de preproducción y otra de producción en lugar de editar producción en caliente.

La función de control de versiones de n8n hace esto de forma nativa en los planes de pago; en la edición comunitaria, un flujo programado que llama a la API interna, escribe el JSON en un repositorio y abre una pull request te da el ochenta por ciento en una tarde. En cualquiera de los dos casos, la regla que importa es cultural, no técnica: producción no es un editor.

Lo que cuesta operarlo bien

Una instalación con forma de producción son una instancia principal y dos workers, unos 2 vCPU y 4 GB entre todos para la mayoría de cargas, un Postgres gestionado pequeño y un Redis gestionado pequeño. En AWS o Azure eso se queda entre 120 y 200 euros al mes, y sustituye a una factura de Zapier o Make que en la misma empresa suele ser de tres a diez veces eso cuando el volumen de tareas es real. El intercambio es que esos 150 euros de infraestructura vienen con la carga operativa de un servicio que ahora es tuyo: actualizaciones, copias, una guardia.

Esa es la decisión, no la lista de funcionalidades. La escribimos entera en n8n, Make o Zapier.

Qué hacer esta semana

Busca tu instancia de n8n: la hay, y probablemente está en la VM de alguien. Comprueba tres cosas: si N8N_ENCRYPTION_KEY está fijada explícitamente, cuánto ocupa la tabla execution_entity y quién llega al editor. Esas tres respuestas suelen convertir una conversación cómoda en un proyecto.