Autoalojar el servidor de TRMNL con Terminus, lo que costaría y por qué lo aplazo

Si has llegado aquí desde el post de los cuatro paneles TRMNL en mi mesa, sabes que tengo cuatro pantallas e-ink alimentadas por un FastAPI corriendo en mi propio VPS. Lo que no conté es que el setup, aun siendo casi todo mío, tiene un trozo que no controlo. La pantalla habla con la nube de TRMNL para saber qué plugins tiene asignados, recibe desde ahí las imágenes ya renderizadas y se sincroniza cada quince minutos con una cuenta que vive en usetrmnl.com. Yo pago veinte dólares por desbloquear la Developer Edition que me deja usar Private Plugins (los que tiran de mis endpoints) y a cambio de esa cuota tengo acceso al servidor cloud y al catálogo público.

Funciona muy bien. Pero la pregunta razonable, sobre todo viniendo de alguien que ya tiene CrowdSec, Pangolin, Umami, Infisical y un FastAPI propio corriendo en el mismo VPS, es la obvia. ¿Y si me llevo también ese último trozo a casa? El proyecto que lo permite existe, se llama Terminus, lo mantiene el propio equipo de TRMNL como referencia oficial de BYOS (Bring Your Own Server), y está en GitHub con licencia MIT. Lo he estado mirando con calma esta semana. La conclusión corta es que sí se podría, y bastante rápido, pero hoy no compensa. Este post es el ejercicio de pensarlo de principio a fin para no tener que volver a hacerlo cuando llegue el momento.

Lo que hay que sustituir, exactamente

La cloud de TRMNL hace tres cosas que mis Private Plugins no hacen. La primera es el catálogo de plugins, esa pantalla web donde defines la URL de polling, las cabeceras y el markup Liquid. Si me lo llevo a casa, esa pantalla la hospedo yo. La segunda es la renderización del Liquid a imagen e-ink, porque el TRMNL no renderiza HTML in-device, sino que recibe un PNG en blanco y negro listo para mostrar. La tercera es el endpoint que el dispositivo consulta para decir "soy el aparato X, ¿qué te toca enviarme ahora?", con todo su ciclo de autenticación, sleep y wake.

Las tres piezas juntas son lo que Terminus implementa. El stack es Ruby con Hanami como framework web, Postgres para el catálogo, Valkey (el fork libre de Redis que se mantiene desde la AGPL de Redis) con Sidekiq para los jobs en background, ImageMagick para convertir el HTML/SVG renderizado a la imagen del e-paper y htmx para la interfaz de gestión. Trae compose.yml oficial, documentación de Raspberry Pi y de Kubernetes, y un botón de "deploy to Render" para quien no quiera complicarse. Está en beta (pre-1.0), con unas 550 estrellas y 2200 commits, mantenido activamente.

El detalle que más me gustó al investigarlo es que el dispositivo no necesita firmware nuevo. Para apuntarlo a un servidor propio basta con entrar en el WiFi portal del aparato, ir a Advanced, marcar Custom Server y meter la URL del Terminus. Vuelta atrás trivial, lo dejas en blanco y vuelve a hablar con la nube por defecto. Esto cambia mucho la conversación, porque el coste de probar BYOS no es flashear nada, es solo configurar.

Cómo lo montaría dentro de Dokploy

Si decidiera lanzarme, el camino sería el mismo que con cualquier otra app del VPS. Proyecto nuevo en Dokploy, repo público de usetrmnl/terminus apuntado, build desde el compose.yml. Postgres ya lo tengo desplegado para Umami, Infisical y otros, así que abriría una base nueva en la misma instancia en vez de levantar otra. Valkey lo añadiría como servicio aparte, con un volumen para persistir las colas de Sidekiq. ImageMagick viene en la imagen del propio Terminus, no requiere infra extra. El frontend de gestión, que es htmx puro, se serviría desde el mismo contenedor.

El dominio externo sería algo como trmnl-server.josemanuelortega.dev, detrás de Traefik con su certificado de Let's Encrypt. Y aquí entra el detalle que importa, el TRMNL desde mi LAN no debería salir a Internet para hablar con Terminus. Lo razonable es exponerlo solo en la red interna, con una IP del VPS por WireGuard o por la propia Tailscale que uso para casa, o directamente con un dominio interno servido por mi DNS local. Si dejo el dispositivo hablando con un dominio público, gano la posibilidad de moverlo de red sin reconfigurar pero pierdo el aislamiento. Probablemente lo haría privado al principio y solo lo expondría si me hace falta.

Mis cuatro Private Plugins actuales no son código de Terminus, son configuración. Cada plugin es URL + cabeceras + Liquid. Migrarlos sería abrir el dashboard de Terminus, crear cuatro plugins con los mismos parámetros y pegar el mismo markup que ahora vive en la UI de usetrmnl.com. Los endpoints del FastAPI no se tocan porque siguen siendo los mismos, lo único que cambia es quién pregunta. Terminus pasaría a ser el cliente que hoy es la nube de TRMNL.

Las alternativas más ligeras

Terminus es la implementación flagship, pero no la única. El propio equipo tiene byos_sinatra, una versión DIY en Ruby con Sinatra mucho más reducida, sin Postgres ni Sidekiq, pensada para quien quiere hackear el server más que gestionarlo. La comunidad mantiene larapaper en Laravel para gente del mundo PHP y existe un byos_node_lite en Node.js que es lo más cercano a "un FastAPI pero para BYOS". Si mi prioridad fuese no tener que aprender Hanami y mantener todo el stack en un lenguaje que ya domino, el camino Node sería el primer candidato. Si la prioridad es tener el catálogo oficial y compatibilidad de versiones con el firmware sin tener que pensar, Terminus.

El otro eje a tener en cuenta es de quién dependes. Terminus lo mantiene el equipo de TRMNL, así que la garantía de que siga funcionando con futuras versiones de firmware es máxima. Las implementaciones comunitarias dependen de cuán activo esté su maintainer. Para algo que está pegado a una pantalla en mi mesa todo el día, ese factor pesa.

Lo que se gana y lo que se pierde

Lo que se gana al autoalojar es independencia. Si TRMNL cambia el modelo de precios, cierra la Developer Edition o sufre una caída, mis paneles siguen vivos porque todo el camino del dato pasa por máquinas que controlo. Gano también la posibilidad de modificar el comportamiento del servidor (por ejemplo, frecuencias de refresco distintas por plugin, ventanas de no actualizar de noche, o un endpoint propio para forzar refresh desde mi bot de Telegram). Y, no menor, gano poder añadir más dispositivos sin pagar más suscripciones.

Lo que se pierde es justo el efecto red de la cloud. El marketplace de plugins comunitarios desaparece porque no estoy conectado al catálogo central, y los plugins prefabricados (calendario, clima, frases del día) hay que portarlos o reescribirlos uno a uno. Las actualizaciones de firmware siguen viniendo de TRMNL, pero ahora me toca a mí leer las release notes del Terminus para asegurar que mi versión soporta la nueva del firmware del dispositivo. Y aparece el riesgo de operación normal, una pieza más que monitorizar, una pieza más cuyos backups planificar, una pieza más en mi panel de Overview que vigilar.

Por qué hoy no toca

El cálculo razonable, hoy, es no migrar. La Developer Edition fueron 20 dólares de pago único cuando compré la pantalla, una cifra que ya no se nota. Mis Private Plugins están funcionando, son cien por cien código mío, la única dependencia es que el servidor de TRMNL responda. No tengo evidencia de que ese servidor falle ni de que el modelo de precios se vaya a tocar. Si mañana alguno de los dos pasara, el plan está escrito y montar Terminus me llevaría como mucho un fin de semana, todo el aprendizaje técnico está pensado en este post y la migración de los plugins son cuatro copy-pastes.

Hay también un argumento blando que rara vez incluyo en estos análisis pero pesa. Cada pieza que autoalojas es una pieza que se rompe en horario equivocado. Sábado por la tarde mi mente prefiere no acordarse de que Valkey está en swap. La cloud de TRMNL para esto cumple, lo razonable es dejarla ahí mientras cumpla. La pregunta no es "¿puedo autoalojarlo?" sino "¿el coste de seguir pagando es mayor que el coste de mantener un servicio más?". Hoy, no.

Cuándo dispararía el cambio

El plan se activa si pasa cualquiera de estas. Si TRMNL cierra o encarece la Developer Edition por encima de lo que pago hoy. Si el cloud me da latencia notable y se nota en la pantalla. Si quiero un dispositivo que no salga nunca de mi LAN, por ejemplo uno expuesto a invitados de casa. Si llego a necesitar más de cinco o seis paneles activos y quiero gestionarlos con catálogo propio. O si en algún punto futuro empiezo a quererle cambiar cosas al firmware o al protocolo, porque ahí ya sí necesito ser dueño del otro extremo de la conversación.

Mientras tanto, queda como nota mental, escrita en el sitio donde la sé encontrar. Si dentro de seis meses el escenario cambia, vuelvo a este post, escribo el segundo con la implementación real y enlazo aquí los logs del primer fin de semana. Hoy el sistema cumple su propósito y me deja seguir con otros frentes.