Sustituí mi programador de redes sociales por un flujo de trabajo n8n autoalojado

Cinco dólares por canal y mes. Esa era la cifra que miraba fijamente en la pantalla de renovación, porque decidía en silencio en cuántos sitios se me permitía publicar. Cuatro canales significaban cuatro por cinco. Si más adelante añadía una segunda marca, la factura volvía a subir por las mismas publicaciones programadas que yo ya escribía.

Ya tenía n8n funcionando en un VPS para dos automatizaciones sin relación, así que me di un fin de semana para ver si podía convertirlo en un programador de redes sociales n8n para X, LinkedIn, Instagram y Facebook. Lleva cuatro meses en marcha. Esto es lo que el cambio me costó de verdad, qué se rompió y en qué casos sigo sin recomendarlo.

La versión corta

• Conseguí publicar en X, LinkedIn, Facebook e Instagram desde el mismo flujo de trabajo, pero las cuatro ramas no exigieron la misma cantidad de trabajo.
• Instagram fue el problema: el requisito de cuenta profesional, las reglas de medios, los límites de publicación y el ciclo de vida de los tokens generaron un mantenimiento que no tenía con Buffer.
• Dejé TikTok fuera porque el catálogo de nodos de aplicación integrados de n8n no lo incluye, y no estaba dispuesto a que una integración personalizada o comunitaria formara parte de mi calendario de publicación.
• Community Edition eliminó la tarifa del software, no el coste. Seguía pagando el alojamiento y me encargaba de las actualizaciones, las credenciales, las copias de seguridad, la monitorización y la recuperación de publicaciones fallidas.
• Mi veredicto: el cambio mereció la pena porque quería la redacción y la publicación en una sola cadena. Si solo hubiera querido un calendario visual y colas fiables, me habría quedado.

Qué estaba pagando y qué inclinó finalmente la balanza

Los precios actuales de Buffer sitúa Essentials en 5 $ por canal al mes con facturación anual, mientras que el plan gratuito admite hasta tres canales y diez publicaciones programadas por canal. Mis cuatro canales de pago quedaban por tanto en 20 $ al mes con facturación anual. Es una manera razonable de vender un programador pulido, pero me cobraba justo por lo que quería ampliar: reformular una idea para varios sitios a la vez.

Al final no fue el precio lo que me decidió. Ya redactaba las publicaciones con un modelo en otra ventana y luego las pegaba a mano en el programador. Dos herramientas hacían una sola cadena evidente. En cuanto vi el flujo de trabajo que quería, pagar una suscripción para mantener la redacción y la publicación en dos mitades separadas dejó de tener sentido para mí.

Qué hace mi flujo de trabajo

Mi flujo de trabajo es deliberadamente aburrido. Un Schedule Trigger se dispara unas cuantas veces al día, lee la siguiente fila aprobada de mi Google Sheet, adapta el texto a cada plataforma, envía cada versión por su propia rama de publicación y registra el resultado. Mantengo un estado de aprobación humana en la hoja y solo publico las filas que he aprobado. Las ramas fallidas lanzan una alerta fuera de n8n, para que una credencial rota no desaparezca dentro de un registro de ejecución.

El paso de redacción llama a la API de un modelo alojado. Barajé brevemente ejecutar un modelo en la misma máquina, pero con unas pocas decenas de publicaciones al mes, los factores de coste de autoalojar un modelo los factores de coste eran mayores que mi factura de API. El uso, la privacidad o la latencia podrían cambiar esa decisión, pero no tenía motivo para operar infraestructura extra solo para reescribir publicaciones. El flujo de trabajo no es ingenioso, y en parte por eso confié en él.

La realidad plataforma por plataforma (Instagram es el problema)

Tres de mis cuatro ramas transcurrieron casi sin incidentes. Instagram consumió más tiempo que todo el resto del proyecto junto, y fue la plataforma donde las publicaciones perdidas me resultaban más difíciles de ignorar. La tabla muestra las rutas que usé o evalué; los detalles de debajo son las partes que afectaron a mi configuración.

Para LinkedIn, la documentación del nodo LinkedIn cubre la creación de publicaciones para personas y organizaciones, y la guía de credenciales de LinkedIn de n8n indica que publicar como organización implica pasar tu app por la Community Management App Review de LinkedIn. Eso cubría lo que yo necesitaba. La documentación de credenciales de X dice que X aplica límites de tasa por tiempo en cada endpoint, según el nivel de tu plan de acceso de desarrollador. Con mi volumen de publicación nunca llegué al techo, pero lo sigo tratando como un límite que X puede cambiar, no como una promesa de n8n.

La guía de publicación de contenido de Meta documenta JPEG como único formato de imagen admitido y un límite de 100 publicaciones a través de la API en una ventana móvil de 24 horas para la ruta documentada. La regla del JPEG me costó una tarde, porque mis exportaciones eran PNG por defecto y el fallo no se veía desde dentro de n8n. Mantengo ese límite de publicación atado a la ruta y la versión de API actuales, en lugar de darlo por permanente.

Se rompió dos veces en cuatro meses. Las dos, Instagram. Los tokens de acceso de larga duración no son eternos, y la referencia de Meta sobre la renovación de tokens dice que un token solo puede renovarse mientras no haya caducado y tenga al menos 24 horas. Si se te pasa esa ventana, la renovación deja de ser la vía de recuperación. Mi error fue tratar la autenticación como trabajo de instalación en vez de mantenimiento continuo. Un flujo de publicación necesita vigilancia de caducidades, una renovación anticipada y una alerta cuando la renovación falla.

TikTok simplemente no formó parte de mi sustitución. El catálogo de nodos de aplicación integrados no lo incluye. Podría haber usado el nodo HTTP Request, un nodo propio o uno de la comunidad, pero eso me habría hecho responsable de más gestión de credenciales y más averías. Estaba sustituyendo un programador, no ofreciéndome voluntario para mantener otra integración de plataforma.

Las cuentas del coste, incluyendo mi tiempo

Tomé Buffer Essentials con cuatro canales como referencia. Los precios publicados a continuación corresponden a facturación anual y se verificaron en agosto de 2026; he dejado los importes en dólares y en euros en sus monedas publicadas en vez de fingir que son directamente equivalentes.

Los precios de la nube de n8n sitúan Starter en aproximadamente la misma franja de entrada que mis cuatro canales de Buffer Essentials. Eso liquidó la opción gestionada en mi caso: habría pagado una cantidad mensual parecida por un motor de flujos de trabajo y habría perdido la interfaz de publicación más agradable. La comparativa de la Community Edition confirmó que podía quedarme con la edición autoalojada básica sin pagar por el software, pero eso no hizo gratis ni el servidor ni mi tiempo.

Tampoco convertiría el tamaño de mi máquina en un mínimo universal de producción de 4 GB de RAM y 2 vCPU. Los requisitos previos de despliegue de n8n dan un rango de recursos amplio. Mi carga es pequeña, pero otra instalación puede cambiar rápido con ejecuciones concurrentes, cargas de medios, pasos de código, carga de base de datos y un historial de ejecuciones más largo. La respuesta honesta es partir de la carga de trabajo y vigilar memoria y CPU.

SQLite es la base de datos por defecto de n8n y puede bastar para una instalación de una sola instancia y bajo volumen. Aun así, prefiero PostgreSQL en cuanto el historial de ejecuciones importa o se espera que el despliegue crezca. PostgreSQL es además lo que necesita una configuración distribuida en modo de cola , porque n8n no admite esa arquitectura sobre SQLite. Prefiero tomar esa decisión al instalar antes que migrar una base de datos cuando el flujo de trabajo ya se ha vuelto importante.

El VPS nunca fue la parte cara. Mi fin de semana sí. Luego llegó la tarde perdida por el JPEG, los fallos de tokens y la comprobación recurrente de que las publicaciones habían salido de verdad. Si pongo precio a mis propias horas, el ahorro se encoge rápido y puede volverse negativo. Ese es el punto en el que el autoalojamiento deja de ser barato. Sigo pensando que el cambio mereció la pena, pero en la primera semana no lo habría dicho.

LEER

El stack autoalojado para indie hackers: la mejor forma de reemplazar tu enorme factura de SaaS

Qué se rompió y qué cambié

Los dos fallos visibles fueron fallos de token de Instagram, pero el problema de fondo era el silencio. Un programador de suscripción me da una superficie de producto diseñada para mostrar problemas de cuenta. Mi primer flujo de trabajo podía fallar dentro de n8n mientras el síntoma público era simplemente un día sin publicaciones. Eso me enseñó que un publicador autoalojado tiene que fallar en voz alta y recuperarse sin duplicados.

• Envío las alertas de fallo a un canal fuera de n8n, con la respuesta de la plataforma y el ID de ejecución del flujo, para no depender del mismo sistema que debe avisarme de que está roto.
• Llevo el control de las fechas de caducidad de los tokens y del estado de las revisiones de la app, y pruebo la renovación con tiempo suficiente para reautorizar antes de que una publicación programada sea el primer aviso.
• Registro un ID de contenido único antes de publicar, lo que permite que una rama de plataforma fallida reintente sin volver a publicar en las ramas que ya salieron bien.
• Hago copia del volumen de datos y de la base de datos de n8n, y considero la prueba de restauración parte de la copia de seguridad en vez de dar por hecho que unos archivos copiados me salvarán.
• Fijo las versiones de la API donde el proveedor lo permite, leo los registros de cambios y pruebo cada rama de plataforma tras un cambio en n8n o en el proveedor.
• Podo el historial de ejecuciones y los archivos multimedia según la retención que de verdad necesito, porque los materiales de redes pueden convertir una automatización diminuta en una copia de seguridad innecesariamente grande.

Yo no ejecutaría esto en una máquina de mi casa. Una publicación programada a las 9 de la mañana exige que el flujo esté en pie a las 9, y la luz doméstica, la conectividad, el NAT y las llamadas entrantes añaden variables que no quiero en un calendario de contenidos. Un VPS elimina esas variables de la red de casa; no elimina mi responsabilidad sobre TLS, copias de seguridad, monitorización, actualizaciones o recuperación.

Quién no debería hacer esto

Quédate con el programador de pago si lo que quieres es un programador. Eso no es un premio de consolación. Si un calendario, las vistas previas, aprobaciones sencillas, una cobertura amplia de canales y un mantenimiento mínimo te compensan la suscripción, comprarlos es la decisión correcta. Sin necesidad de automatización a medida, cambiar esa interfaz por un lienzo de flujos es un retroceso con pasos de más.

Si quieres un producto con la forma de Buffer pero que sea tuyo, yo miraría Postiz antes que n8n. Su versión de código abierto puede correr en tu propio servidor, y su lista de plataformas incluye TikTok entre más de 30 canales admitidos. Es un calendario de publicación en lugar de un lienzo de flujos, lo que lo convierte en un destino más natural para mucha gente que deja un programador de pago.

Lo volvería a hacer solo porque quería la documentación, la redacción, la aprobación, la publicación y el registro en una sola cadena. Ese es el trato que acepté: no programación gratis, sino control pagado con atención. Si lo único que necesitara fuese programar, volvería a la suscripción.

Si quieres seguir la misma vía autoalojada, nuestro despliegue de n8n en un clic elimina el paso inicial de instalar el servidor. No elimina el trabajo que a mí me pareció más importante: las credenciales del flujo, las aprobaciones de las plataformas, las actualizaciones, las copias de seguridad, la monitorización y la recuperación de publicaciones fallidas.

Preguntas frecuentes

¿Las autorizaciones de Buffer se transfieren a n8n?

No. Las conexiones de plataforma que le había concedido a Buffer pertenecían a la app y al flujo de autorización de Buffer. Mi flujo de n8n necesitaba sus propias credenciales, tokens, ámbitos y cualquier revisión de plataforma exigida para la cuenta o la ruta de publicación.

¿Debe cada plataforma social tener su propia rama?

Normalmente sí. Usé ramas separadas para poder adaptar el texto, los medios, las credenciales y el manejo de errores a cada plataforma. Eso también permitía que una petición fallida de Instagram reintentara sin volver a publicar algo que ya había salido bien en X o LinkedIn.

¿Puede un solo flujo de n8n publicar para varios clientes?

Sí, pero yo aislaría credenciales, fuentes de contenido, estados de aprobación y registros por cliente. Los permisos y las cuotas de plataforma siguen aplicándose a la app y la cuenta correspondientes, así que una conexión exitosa nunca debe tomarse como acceso universal.

¿Cómo debe recuperar un flujo las publicaciones perdidas?

Consulto las publicaciones aprobadas cuya hora programada ya pasó y luego publico solo los registros sin resultado satisfactorio. Un ID de contenido único y la respuesta de plataforma guardada evitan que un reinicio o un reintento dupliquen publicaciones que ya salieron.