Postiz: programar publicaciones en redes sociales desde tu propio servidor
Postiz es una herramienta libre para programar publicaciones en redes sociales: escribes una vez, eliges canales y fechas, y ella las publica. Lo mismo que hacen los servicios de pago del ramo, con la diferencia de que corre en tu servidor y las credenciales de las cuentas conectadas no salen de ahí.
La monté en el clúster de plataforma del homelab. Y lo interesante no fue instalarla, sino darme cuenta de que una herramienta que uso veinte minutos a la semana no tenía ningún sentido encendida las otras ciento sesenta y siete horas. Así que la mayor parte del tiempo no corre: está a cero réplicas hasta que alguien abre su dirección.
Lo que hace es esto: un calendario, los canales conectados a la izquierda, y cada publicación colocada en su hueco. Los que se ven programados ahí son los artículos de este mismo blog — el mismo sitio donde estás leyendo esto se distribuye desde esa pantalla.
Nada que no haga un servicio de pago. La diferencia es dónde viven las credenciales de las cuentas conectadas y quién puede leerlas, que en un negocio pequeño es la única razón de peso para autoalojar algo así.
Lo que «gratis y autoalojado» no incluye
Aquí conviene bajar las expectativas, porque es la parte que no aparece en ninguna página de producto. Que el software sea libre y corra en tu servidor no significa que publicar salga gratis: significa que el software no te cobra. Las plataformas, sí.
Una herramienta alojada por otro te da las cuentas conectadas y listo, porque quien la opera ya ha hecho el trabajo sucio: registrar su aplicación en cada plataforma, pasar las revisiones y sostener las credenciales. Al autoalojar, ese trabajo pasa a ser tuyo.
Para cada red hay que darse de alta en su portal de desarrollador, crear una aplicación propia, declarar para qué la quieres, configurar las direcciones de retorno del inicio de sesión y pedir los permisos de publicación. Algunas plataformas revisan esa solicitud antes de concederla, y no todas la conceden a la primera. No es difícil; es tedioso, y hay que repetirlo tantas veces como redes quieras conectar.
Conviene tenerlo claro antes de montarlo, porque cambia el cálculo. Autoalojar no sustituye a pagar una herramienta: sustituye a pagar una herramienta por operar la tuya, y sigues pagando a las plataformas que cobran por su API. Lo que ganas es dónde viven las credenciales, qué se guarda de tu actividad y no depender de que un servicio decida cambiar sus precios o cerrar.
Para mí compensa por lo primero. Si tu motivo es únicamente ahorrar, ese cálculo puede no salirte.
Lo que cuesta tener algo encendido
Postiz no es una aplicación: son cinco. La web, una base de datos PostgreSQL, un Redis, un servidor de flujos de trabajo y su Elasticsearch. Ese conjunto ocupa memoria de forma permanente para atender un uso que es, siendo honesto, esporádico.
En un servidor gestionado eso lo paga otro. En hardware propio lo pagas en memoria que no puedes dedicar a otra cosa, que en un homelab es el recurso que primero se acaba.
Escalar a cero, y que la primera petición espere
La pieza es KEDA con su complemento HTTP. En lugar de que el tráfico entre directo a la aplicación, entra a un interceptor que retiene la primera petición, levanta el despliegue de cero a una réplica, y la reenvía cuando está listo. Quien abre la página no ve un error: ve que tarda.
replicas:
min: 0
max: 1
scaledownPeriod: 3600
scalingMetric:
concurrency:
targetValue: 100Tras una hora sin tráfico vuelve a cero. Una hora es un número escogido con criterio: lo bastante largo como para que una sesión de trabajo no sufra un arranque en frío a media tarea, y lo bastante corto como para no dejarlo encendido toda la noche porque entraste un momento.
El problema de verdad son las dependencias
Escalar la web a cero es la parte fácil. Si la base de datos y el resto siguen encendidas, el ahorro es una fracción del total. Así que también están a cero, y ahí aparece el problema interesante: ¿quién levanta a quién?
La solución es que las dependencias no escuchan tráfico, sino que siguen al propio pod de la web. Cuando el interceptor lo despierta, ese pod aparece en el clúster y las cuatro dependencias arrancan en paralelo por seguir su presencia.
- Petición
- Interceptorla retiene
- Postiz0 → 1
- Postgres, Redissiguen al pod
- Respuesta
Lo que hace que esto no se bloquee es un detalle del contador: un pod que todavía está pendiente o inicializándose ya cuenta como presente. Si solo contaran los pods en marcha, tendríamos un abrazo mortal —la web esperando a su base de datos, la base de datos esperando a que la web esté lista—. Al contar desde que existe, ambas arrancan a la vez y el arranque de la aplicación absorbe el desorden reintentando hasta que sus dependencias responden.
Qué se gana y qué se paga
Se gana la memoria de cinco procesos durante el noventa y tantos por ciento del tiempo. En un clúster doméstico eso es la diferencia entre poder levantar otro servicio o no.
Se paga en la primera visita. Levantar la aplicación y sus dependencias no es instantáneo, así que abrir la página después de un rato tarda unos segundos largos. Para una herramienta que abro yo, es un precio que no me cuesta pagar; para algo de cara a un cliente, sería inaceptable.
Ese es el criterio para decidirlo: escalar a cero encaja cuando el uso es esporádico, identificable y tolera un arranque en frío. Si alguna de las tres no se cumple, el ahorro no compensa la primera impresión.
Seguir leyendo
Montar un homelab desde cero: Kubernetes y GitOps - Homelab (03/06)
Un entorno entero por cada pull request, y que se borre solo
Montar un homelab desde cero: observabilidad - Homelab (05/06)
Un despliegue por cliente o un espacio por cliente
Búsqueda y agentes sobre tu propia documentación
