Lo que se rompe cuando usted se autohospeda n8n

Empecemos por lo que no se rompió.

Llevamos cuatro automatizaciones corriendo en un servidor propio, con varias actualizaciones aplicadas, y no ha fallado ninguna. Eso contradice buena parte de lo que se escribe sobre autohospedaje, y sería deshonesto no decirlo.

Las capturas de esta página son de flujos de demostración, montados con datos inventados para el artículo. Los que corren en producción tocan datos del negocio y no se publican.

También sería deshonesto dejarlo ahí. Cuatro automatizaciones no son una prueba, y autohospedar no falla todos los días: falla de golpe, en una actualización mayor. La próxima tiene fecha, y es el mes que viene.

La fecha: n8n 3.0, octubre de 2026

Es el cambio más grande que n8n ha anunciado, y le pega sobre todo a quien tiene su propia instalación.

Lo que más rompe: exigirá Docker. n8n 3.0 deja de admitir instalaciones hechas con npm o npx. Si su servidor corre así, no es una actualización: es una migración, y hay que hacerla antes.

Se retiran más de treinta nodos, entre ellos algunos muy usados: Function, Function Item, Cron, Interval, HTML Extract y Read PDF. Un flujo que use cualquiera de ellos deja de funcionar y hay que rehacerlo con lo que quede.

Y varias cosas más que valen la pena mirar antes de actualizar:

• La carpeta de datos binarios cambia de nombre.
• Los paquetes de comunidad sin verificar quedan desactivados por defecto.
• El tiempo máximo del ejecutor de tareas baja de 5 minutos a 1.
• El límite de descompresión baja de 2 GiB a 256 MiB.
• Desaparece el ayudante de expresión $getPairedItem.
• El modo de datos binarios en memoria deja de ser válido.

Qué hacer con esto, en concreto: antes de actualizar, revise en los ajustes el informe de migración que n8n genera, exporte los flujos importantes y haga la lista de los que usan nodos retirados. Esa lista es el trabajo real, y no lo hace nadie por usted.

Lo que se llena solo

Este es el que rompe en silencio, y por eso es el peor.

Cada ejecución guarda datos, y n8n lo dice sin rodeos: según su volumen y sus ajustes, la base de datos puede crecer hasta quedarse sin espacio.

La buena noticia es que la limpieza automática viene activada. Borra lo terminado cuando pasa de 336 horas —14 días— o cuando supera las 10.000 ejecuciones, lo que ocurra primero. Nunca borra las ejecuciones marcadas con etiquetas ni las que están corriendo o en espera.

La mala noticia, y es la letra chica que casi nadie lee: si su base es SQLite, el espacio borrado no se le devuelve al disco. Queda reservado para futuras ejecuciones. Para recuperarlo de verdad hay que activar el vaciado al arranque o ejecutarlo a mano.

Traducido: usted puede tener la limpieza funcionando perfectamente y el disco llenándose igual. Es exactamente el tipo de avería que no se ve venir, porque el sistema le está diciendo que todo está bien.

Es también la razón por la que n8n recomienda PostgreSQL en producción y no la base que trae por defecto.

El reloj que no es el suyo

Este lo descubrimos preparando este artículo, y es de los que no dan error nunca.

Un disparador configurado a las 4:00 no corre a las 4:00 suyas: corre a las 4:00 del huso horario que tenga configurada la instancia. Y ese huso lo pone quien la instaló, no usted.

En esa captura el disparador está puesto a las 4 de la mañana, y la salida del nodo declara el huso de la instancia: Nueva York. Con la instancia en UTC−4 y el operador en UTC−6, ese flujo corre a las 2 de la madrugada hora local, no a las 4.

Para un respaldo da lo mismo. Para un reporte que tiene que estar listo a la apertura, o para un aviso a un cliente, son dos horas de diferencia que nadie le va a señalar: el flujo corre, no falla, y llega cuando no debe.

Revíselo el primer día. La salida de cualquier nodo de horario se lo dice, como en la captura. Se corrige en los ajustes de la instancia, o flujo por flujo.

Lo que no se rompe, pero deja de estar

Nuestro caso, y lo contamos porque es la falla más común de todas.

El respaldo diario —descrito entre las automatizaciones que sí amortizan— corre desde hace meses. Se restauró una vez, al montarlo, para comprobar que servía. Funcionó. No se ha vuelto a probar desde entonces, con el argumento de que el sistema mueve poco dato.

Ese argumento es el que usa todo el mundo, y no es bueno. La prueba del primer día demuestra que el respaldo servía ese día. No dice nada del que corrió esta madrugada, ni de si el formato sigue siendo compatible, ni de si la credencial del destino sigue viva.

Un respaldo no probado no es un respaldo: es una intención. Y esta es una avería que no aparece en ningún registro, porque no hay nada roto que avise.

Lo que se cae solo, con el tiempo

Tres categorías que no son fallas del servidor sino del mundo alrededor, y que le tocan igual:

Así se ve una avería cuando usted está mirando: el paso en rojo y el motivo escrito. El problema es que casi nunca está mirando. Estas tres son las que llegan solas:

Las credenciales caducan. Los accesos que usted autorizó una vez expiran, se revocan o cambian de política. El flujo deja de correr, y el aviso suele ser que algo no llegó.

Las aplicaciones de terceros cambian. Un servicio actualiza su interfaz, retira un campo o cambia su forma de autenticación, y el nodo que dependía de eso se queda sin saber qué hacer.

Su propia dependencia crece sin que usted la vea. Cada automatización que agrega es un proceso más que alguien tiene que saber arreglar. Ese alguien es usted.

Ninguna de las tres es culpa de n8n ni del hospedaje, y en la nube pasan igual. La diferencia es quién las arregla.

Por qué a nosotros no se nos ha roto nada

Vale la pena explicarlo, porque el motivo dice más que el hecho:

• Poco volumen. Cuatro automatizaciones, no cuarenta.
• Pocas integraciones externas. Menos superficie donde algo cambie.
• Un panel que se encarga de las actualizaciones. Buena parte del trabajo que esta pieza describe lo está haciendo el panel, no la persona.
• Y poco tiempo. Meses, no años. La primera actualización de verdad grande todavía no llegó.

Ninguna de esas cuatro es una virtud. Son condiciones, y tres de ellas se acaban cuando el negocio crece.

Qué haría antes de octubre

Cinco cosas, en este orden:

1. Averigüe cómo está instalado su n8n. Si no fue con Docker, esa es la primera tarea y no es pequeña.
2. Liste los flujos que usan nodos que se retiran. Function, Cron, Interval, HTML Extract, Read PDF y los demás.
3. Exporte todo antes de tocar nada. Los flujos y las credenciales.
4. Restaure un respaldo a propósito. No después de la actualización: antes, para saber que tiene a dónde volver.
5. Actualice en un momento en que pueda atender lo que salga mal. No un viernes a las seis.

Lo que esto cuesta

Todo lo anterior son horas suyas, y ese es el punto que decide si autohospedar le conviene. Están contadas, con su equivalente en dinero, en la cuenta a 12 y 36 meses.

Y si después de leer esto prefiere que el servidor sea problema de otro, esa también es una respuesta correcta. En la nube de n8n, casi nada de esta página le aplica: las actualizaciones las hacen ellos, la base de datos la administran ellos, y el disco no es suyo.

Lo que usted compra al autohospedarse no es solo el ahorro. Es el trabajo.

Si llegó aquí antes de empezar, la ruta completa está en la guía del local.