Volver al blog
open-sourceself-hostinginfrastructureagenciesdevops

Self-host de un agendador social: cuándo tiene sentido

Hacer self-host de un agendador de redes sociales cambia una suscripción mensual por control y trabajo operativo. Cuándo conviene, y cuándo no.

TryPost TeamTryPost Team
9 min de lectura
Self-host de un agendador social: cuándo tiene sentido

Hacer self-host de un agendador de redes sociales convierte una suscripción de $19 al mes en aproximadamente lo mismo en costo de servidor, más tu tiempo como operador. Para algunos equipos, ese trade-off es una ganga. Para otros, es una distracción silenciosa. Este artículo explica qué exige realmente el self-host en 2026, cuándo la cuenta da a tu favor, cuándo no, y cómo decidir antes de quemar un fin de semana en un archivo Docker compose.

Qué significa self-host en 2026

Hacer self-host de un agendador open source no es "la versión gratis de Buffer". Es infraestructura que vos operás. En la práctica, eso suele significar:

  • Una VPS o servidor cloud chico corriendo Docker.
  • Un docker-compose.yml que levanta la app, una base Postgres y una cola Redis.
  • Un proxy reverso (Caddy o nginx) manejando el TLS.
  • Actualizaciones regulares del sistema operativo y de las imágenes para que los parches de seguridad lleguen.
  • Backups diarios de la base, guardados en algún lugar fuera de la misma máquina.
  • Una manera de leer logs cuando un post falla al publicar.

Si esa lista te resulta familiar, self-host probablemente encaja en tu equipo. Si te resulta extraña, el ahorro se lo va a comer el primer incidente a las 3 de la mañana.

El setup de Docker en sí es directo. Postiz, Mixpost y TryPost entregan un docker-compose.yml funcional. Cloná el repo, configurá las variables de entorno y la app levanta en menos de una hora para la mayoría de los equipos. Lo que viene después es lo que la gente subestima: monitoreo, upgrades, salud de la cola, problemas de refresh de token OAuth, y esa migración ocasional que necesita intervención humana.

Cuándo self-host es la decisión correcta

Algunas condiciones hacen que self-host valga genuinamente la pena.

Los datos tienen que vivir dentro de tu propio perímetro. Algunas agencias firman contratos con clientes que exigen que todos los assets de marketing, captions y métricas se queden en infraestructura controlada por la agencia. Bancos, cuentas de gobierno y sectores regulados (seguros, salud, brands de healthcare) suelen imponer este requisito. Un agendador gestionado guarda tus drafts en la base del proveedor. Para esos clientes, eso es inviable.

Manejás treinta o más brand accounts. La mayoría de los agendadores gestionados cobra por workspace o por cuenta social. Con treinta brands de cliente y cinco cuentas sociales cada una, la cuenta por seat se pone fea rápido. Self-host aplana ese costo a un servidor único, sin importar cuántas cuentas conectes.

Necesitás extender el producto. Si querés enchufar el agendador en tu propio CRM, armar un flujo de aprobación custom que tire del Notion, o crear posts en lote desde una Google Sheet, tener el código en tu mano saca la negociación del medio. Una REST API moderna cubre la mayoría de eso sin hacer fork, pero algunos equipos realmente necesitan tocar el source.

Ya operás otra infraestructura open source. Un equipo que corre su propio Plausible, Mattermost o Penpot se va a sentir en casa sumando otro servicio Docker compose. El costo operativo marginal es bajo porque el playbook ya existe.

Si ninguna de esas condiciones aplica, el caso para self-host se debilita rápido.

Cuándo no tiene sentido

El self-host falla de maneras predecibles.

No tenés a una "persona del servidor está caído". Los tokens OAuth expiran. Los cron jobs pierden ventana. El límite de conexiones de Postgres se rompe. Si nadie en el equipo puede hacer SSH y leer logs a las 9 de la mañana de un lunes, los posts agendados van a empezar a fallar en silencio y nadie lo va a notar por una semana.

Tu tiempo vale más que $19/mes. Un founder gastando una tarde de sábado debugueando un worker de cola se está pagando del modo equivocado. El precio gestionado existe porque la mayoría de los equipos valora correctamente una hora de trabajo enfocado por encima de una suscripción fija.

Necesitás cobertura de red que no podés correr solo. Algunas redes (TikTok, ciertos endpoints de Meta) exigen aprobaciones de API a nivel partner que tardan meses y hay que renovarlas. Los proveedores gestionados mantienen esas relaciones para todos los clientes. Una instancia self-hosted suele chocar contra "esta app no está aprobada para postear" en las redes más restringidas hasta que la app subyacente sea aprobada.

No le pusiste precio a tu propio tiempo. Este es el silencioso. El primer año de self-host se siente gratis porque los costos son difusos: un domingo ajustando Caddy, un martes a la mañana persiguiendo una migración que falló, un jueves agregando fail2ban después de ver brute force al puerto 22 en los logs. Ninguna de esas horas aparece en una línea de presupuesto, pero son reales y suman.

Docker compose corriendo en la terminal de un dev, punto de entrada típico de un agendador self-hosted

Cuánto cuesta de verdad

La comparación honesta incluye infraestructura, tiempo y riesgo. No solo el precio de etiqueta.

Infraestructura. Una VPS chica (2 vCPU, 4 GB RAM, 50 GB disco) en Hetzner o similar cuesta entre $5 y $7 por mes. Eso alcanza para un equipo y unos cientos de posts agendados. Sumá un destino de backup (Backblaze B2 o S3 Glacier) por unos $1 por mes para los tamaños de datos que generan los agendadores. Sumá un dominio por $10 a $15 al año. El piso queda alrededor de $7 a $10 por mes.

Tiempo. Setup inicial, más o menos medio día para alguien fluido con Docker. Mantenimiento continuo, una a tres horas por mes si el playbook está documentado y nada se rompe. Sumá otro medio día dos veces al año para upgrades de versión major. A una tarifa interna de $50 por hora (el piso para la mayoría de operadores de agencia), eso da $600 a $1500 al año solo en tiempo de operador.

Riesgo. Los backups hay que probarlos, no solo configurarlos. Una instancia self-hosted con dump nocturno roto que recién detectás el día que necesitás restaurar es peor resultado que una suscripción de $19 con redundancia gestionada por el proveedor. El riesgo tiene un costo esperado real, aunque no aparezca en una factura.

Comparado con los planes Cloud gestionados de TryPost desde $19/mes con posts agendados ilimitados, self-host gana en costo en plata solo cuando el tiempo del operador es genuinamente libre, o cuando la escala (varios workspaces, varias cuentas de cliente) empuja la cuenta gestionada por encima del piso del tiempo de operador. Los planes actuales están en la página de pricing.

Para una vista de herramientas competidoras, la comparación de alternativas open source desglosa cómo los principales players (Buffer, Hootsuite, Later, Postiz, Mixpost) manejan self-hosting, licenciamiento y exigencias operativas.

Un framework corto para decidir

Tres preguntas, contestadas con honestidad.

  1. ¿Ya operás al menos un pedazo de software self-hosted en producción? Si sí, self-host de un agendador es un servicio marginal sumado a una rutina que ya corrés. Si no, la curva operativa es el costo real, y es más grande de lo que la gente estima.
  2. ¿La cuenta gestionada va a pasar de unos $200/mes en tu escala? La mayoría de los equipos abajo de esa línea ahorra pagando gestionado. Arriba, el cálculo cambia, sobre todo a escala de agencia o cuando se suman seats por cliente.
  3. ¿Hay una exigencia contractual o regulatoria para mantener los datos en tu propia infraestructura? Si sí, la decisión está tomada, sin importar el costo. Elegí la opción open source que sirve y presupuestá el tiempo de operador.

Si dos de esas tres respuestas apuntan a self-host, hacelo. Si dos apuntan a gestionado, dejá de pesarlo y pagá la cuenta.

Un equipo chico de agencia revisando un calendario de contenido, la capa operativa que self-host suma al equipo

Cómo TryPost maneja los dos caminos

TryPost es open source, con licencia AGPL, y entrega el mismo docker-compose.yml que corre el producto Cloud gestionado. No hay gap de feature entre self-hosted y Cloud: el AI Copilot, la vista de calendario, las aprobaciones de equipo, el servidor MCP para Claude y ChatGPT, y la REST API funcionan en los dos modos.

Los dos caminos difieren en operaciones, no en capacidad:

  • Self-host. Cloná el repo, corré docker compose up, configurá las variables de entorno para OpenAI, base de datos y proxy reverso. Vos te encargás de los backups, las actualizaciones del SO y las credenciales OAuth por red.
  • Cloud. Planes gestionados desde $19/mes. El equipo de TryPost corre la infraestructura, incluyendo salud de la cola, backups, refresh de OAuth y aprobaciones de API de las plataformas. Vos conectás cuentas y arrancás a agendar.

Una tag del repo acompaña la versión de producción del Cloud, así una instancia self-hosted puede pinear exactamente lo que corre el producto gestionado y quedarse en sincronía. Las notas de upgrade son las mismas en los dos lados.

Si self-host encaja en el perfil de tu equipo, el repo de TryPost en GitHub es por donde arrancar. Si gestionado tiene más sentido, la página de pricing lista los planes actuales y un trial de 7 días.

Conclusión pragmática

La respuesta honesta a "¿debería hacer self-host de mi agendador de redes sociales?" es "tal vez, pero por menos motivos de los que las páginas de marketing sugieren". Soberanía de datos, economía a escala de agencia y madurez operativa ya existente hacen que self-host sea una decisión obvia. Ahorrar $19 al mes no la hace.

Lo que importa es matchear el modelo de deploy con el trabajo real del equipo. Los agendadores son infraestructura operativa, no juguetes. Corrélos donde la matemática operativa cierra, y publicá el contenido desde ahí.

Tip semanal

Un tip de redes sociales por semana

1 email corto y práctico todos los martes. Sin relleno, sin listas genéricas.