Telegram como centro de control: así manejo mi servidor de IA desde el móvil sin tocar SSH

El problema: un servidor que trabaja 24/7 y un dueño que no puede estar delante 24/7

Mi servidor no es un VPS en la nube. Es una Raspberry Pi 5 de 8 GB que está en mi casa, debajo del escritorio, con Debian 12. Ahí dentro corren, a día 4 de agosto de 2026, 62 tareas programadas: el pipeline editorial de esta web, monitores de SEO, backups nocturnos, watchdogs de facturación, el sistema de auto-reparación y varios agentes de IA que investigan y escriben solos.

Durante meses mi rutina era absurda: me levantaba, abría el portátil, hacía SSH, miraba logs, veía que algo había fallado a las 3 de la mañana y que llevaba seis horas muerto. El servidor trabajaba solo, pero yo supervisaba a mano. La automatización estaba rota por el extremo humano.

La solución no fue montar un dashboard. Fue algo mucho más aburrido y efectivo: Telegram. Ya lo tenía en el móvil, ya lo miraba cincuenta veces al día. En lugar de obligarme a visitar una interfaz nueva, llevé el servidor a donde yo ya estaba.

Por qué Telegram y no un dashboard, Discord o el correo

En mi experiencia, elegir el canal equivocado te hace abandonar el sistema en dos semanas. Lo pensé con calma antes de elegir. Estas fueron mis razones reales, con sus pegas:

Contra el correo: un correo de alerta a las 3 de la mañana no lo veo hasta las 9. Telegram sí lo veo, y además puedo responderle al mensaje. El correo es unidireccional; un chat no.

Contra un dashboard web: un dashboard hay que alojarlo, protegerlo, mantenerlo y abrirlo. Yo ya tuve uno (puerto 9119, un panel que me monté para Hermes). Lo uso, pero para consultar estado de vez en cuando, no para el día a día. El dashboard no me avisa: tengo que ir yo a mirar.

Contra Discord: lo valoré. Los canales son cómodos para separar temas. Pero mi móvil ya vive en Telegram, y quería una sola conversación donde todo el sistema me hablara. Además, la API de bots de Telegram es gratuita, estable desde 2015 y no pide tarjeta para nada.

El resultado es que hoy mi chat con el bot es, literalmente, el centro de operaciones. Los agentes publican artículos y me lo cuentan. Un cron falla y me llega el error con el log recortado. El gasto de APIs supera lo previsto y recibo un aviso antes de que la factura duela. Todo en un hilo, en el bolsillo.

La arquitectura: cómo está conectado todo (sin humo)

El esquema que tengo funcionando desde mediados de junio de 2026 es este:

1. El agente vive en la Raspberry Pi. Uso Hermes Agent de Nous Research como cerebro. Su configuración principal a agosto de 2026: modelo DeepSeek V4 Flash para el 80% de las tareas (0,09 $ por millón de tokens de entrada) y DeepSeek V4 Pro para lo complejo (0,43 $). El gasto total mensual de todo el sistema ronda los 18 € al mes, y eso incluye la publicación de 14 artículos semanales en esta web.

2. El gateway de Telegram es la puerta. Hermes tiene un gateway que escucha mensajes entrantes en el bot y los convierte en instrucciones para el agente. En mi config.yaml hay una línea que lo cambia todo: allowed_chats con mi ID de usuario. Si el mensaje no viene de mi chat, se ignora. Sin esa línea, cualquiera que encuentre el nombre del bot podría darle órdenes a mi servidor. Volveré a esto en la sección de seguridad porque es el error número uno.

3. Los 62 crons entregan por Telegram. Cada tarea programada tiene configurada la entrega de resultados en el chat. Si un cron termina bien y no tiene nada que contar, no me molesta. Si algo falla o hay un resultado relevante, me llega. Es la diferencia entre logging (escribir en un archivo que nadie lee) y notificación (que alguien se entere).

4. El flujo inverso también existe. Desde el chat puedo pedirle al agente que ejecute comandos, revise logs, regenere el sitemap o publique una corrección. No todo: las operaciones destructivas las sigo haciendo a mano por SSH, a propósito. Pero el 90% de las consultas y la mitad de las reparaciones las resuelvo escribiendo mensajes.

Paso a paso: monta tu propio centro de control

Esto es lo que haría hoy si empezara de cero, en el orden que lo haría.

Paso 1: crear el bot con BotFather (5 minutos)

En Telegram buscas @BotFather, envías /newbot, eliges nombre y usuario. Te devuelve un token con esta forma: 123456789:ABCdefGHI.... Ese token es la llave de tu servidor. Guárdalo en un archivo fuera del repositorio, con permisos 600. Yo lo tengo en ~/.hermes/.env, que es donde viven todos mis secretos de APIs. Si el token acaba en un commit público de GitHub, alguien puede leer los mensajes de tu bot y enviarlos en su nombre. Pasa más de lo que crees.

Paso 2: averiguar tu chat_id

El bot necesita saber quién eres. Le escribes un mensaje cualquiera y consultas https://api.telegram.org/bot<TOKEN>/getUpdates. Ahí aparece "chat":{"id":782138971} (el mío real, por cierto). Ese número es tu chat_id y es el que va en la whitelist.

Paso 3: la whitelist, antes que cualquier otra cosa

Antes de programar el primer comando, el bot debe rechazar a todo el mundo salvo a ti. En Python puro:

ALLOWED_CHATS = {782138971}

def handle_message(message):
    if message.chat.id not in ALLOWED_CHATS:
        return  # silencio absoluto: ni confirmación ni error
    ...

Fíjate en el detalle: cuando alguien no autorizado escribe, el bot no responde nada. Ni un "acceso denegado". Responder es dar información. El silencio es más seguro.

Paso 4: elegir librería

Para Python, las dos opciones serias en 2026 son python-telegram-bot (la más completa, asíncrona) y aiogram (más rápida de escribir). Para un centro de control casero, python-telegram-bot es suficiente y tiene documentación en condiciones. Si solo quieres que un script te mande avisos sin escuchar respuestas, ni siquiera necesitas librería: un POST con curl a https://api.telegram.org/bot<TOKEN>/sendMessage y listo. Así empecé yo.

Paso 5: ejecutar como servicio

El bot debe sobrevivir a reinicios. Un unit de systemd:

# /etc/systemd/system/tg-control.service
[Unit]
Description=Centro de control Telegram
After=network-online.target

[Service]
ExecStart=/usr/bin/python3 /home/pi/tg-control/bot.py
Restart=always
RestartSec=10

[Install]
WantedBy=multi-user.target

El Restart=always con RestartSec=10 me lo puso un fallo real: la API de Telegram corta conexiones largas de polling y el bot se quedaba colgado. Con el reinicio automático ni me entero.

Cuatro usos reales del centro de control

La teoría suena bien, pero el valor está en el día a día. Estos son los cuatro usos que tengo funcionando ahora mismo, con sus cifras.

Caso real 1: el aviso de facturación que me salvó de una factura sorpresa

El 3 de agosto de 2026 publiqué aquí mismo la historia de cómo cuatro centavos tumbaron mis 25 agentes: DeepSeek devolvió un error 402 de facturación y la cascada de reintentos paralizó medio sistema. Cuando pasó, me enteré tarde, porque entonces los avisos eran tímidos.

Después de aquello monté un watchdog de facturación. Cada vez que un agente recibe un 402 o un 429, el sistema cuenta cuántos lleva en la última hora y me manda un resumen a Telegram: qué modelo, cuántos fallos, cuánto saldo queda estimado. La regla que uso: si hay más de 3 errores de billing seguidos en menos de 5 minutos, el watchdog pausa los crons no críticos y me avisa. Prefiero un mensaje a las 4 de la mañana que una factura de 200 € a fin de mes.

Esto no lo inventé yo por listo: las guías de operación de agentes de 2026 insisten todas en lo mismo, los límites de gasto por proceso. La diferencia entre tenerlo y no tenerlo es si te enteras en 30 segundos o al día siguiente.

Caso real 2: el sistema que se repara solo y me cuenta lo que hizo

Desde el 1 de agosto de 2026 tengo un sistema de auto-reparación con 24 patrones de error documentados: permisos que se quedan mal tras un script, archivos que se generan vacíos, procesos que mueren sin log. Cuando un cron falla, el watchdog compara el error contra los 24 patrones; si hay coincidencia, aplica el arreglo conocido, reintenta y me manda el resultado.

El mensaje que recibo tiene siempre la misma forma: qué falló, qué patrón se aplicó, si funcionó. Si no funcionó, ahí sí me toca intervenir. En la práctica, de los 24 patrones, unos 18 se resuelven solos sin que yo haga nada. Los otros 6 son los que de verdad necesitan manos humanas, y esos son los únicos que me interrumpen.

El truco que aprendí: la notificación de éxito también importa, pero sin spam. Si todo va bien durante 24 horas, recibo un único resumen diario. Si algo falla, recibo el fallo al momento. El silencio significa que todo funciona. Ese fue el diseño consciente: el canal solo se llena cuando hay algo que decidir.

Caso real 3: publicar artículos desde el móvil

Este es el caso que más sorprende cuando lo cuento. El pipeline editorial de La Frontera IA (investigación, redacción, imagen, HTML, sitemap, tweet) corre en la Raspberry Pi como un cron diario a las 7:00. Cuando termina, me llega a Telegram: título del artículo, URL y estado de cada paso.

Pero además puedo escribirle al bot: "publica una corrección en el artículo X", "regenera la imagen de Y", "¿cuántos artículos llevamos esta semana?". El agente ejecuta y me responde con el resultado. He corregido erratas en artículos publicados estando en el sofá, sin abrir el portátil. No es una demo de feria: es la rutina diaria de un sitio que publica 14 artículos a la semana y que mantiene una sola persona.

La única regla que me impongo: desde el móvil nunca ejecuto nada que borre datos sin confirmación. Las correcciones y consultas, sí. Los rm y las migraciones, siempre en el ordenador, con el editor abierto. El móvil es para operar, no para cirugía.

Caso real 4: resúmenes de noticias sin abrir Google News

El cuarto uso es el más antiguo y el que menos mantenimiento me da. Un script lee más de 50 fuentes RSS cada 4 horas, pasa los titulares nuevos por la IA para filtrar lo relevante según mis intereses, y me manda un único resumen a Telegram con lo que merece la pena. Llevo desde el 4 de junio de 2026 sin abrir Google News, y no exagero si digo que me ahorro una hora diaria de scroll.

La clave aquí fue la frecuencia de entrega: al principio me mandaba cada titular nuevo y era insoportable. Ahora llega un resumen cada 4 horas, compacto. Menos mensajes, más señal.

Lo que nadie te dijo

El token del bot es un secreto de nivel contraseña, y casi nadie lo trata así. En los tutoriales que hay en Google (busca "bot telegram raspberry pi" y verás) el token aparece pegado en el código de ejemplo, en capturas de pantalla, en hilos de foros. Si tu bot puede ejecutar comandos en tu servidor y el token se filtra, has regalado un shell remoto. Las buenas prácticas de seguridad para bots lo repiten siempre: token fuera del código, en variable de entorno o archivo con permisos restrictivos, y rotarlo con /revoke en BotFather si sospechas. Yo lo roté una vez, en junio de 2026, por puro higiene.

La whitelist no es opcional ni "algo que añadir después". Es lo primero. Hay un tutorial clásico de 2019 (uGeek) que enseña a montar un menú de comandos para controlar dockers y el servidor, y es un proyecto estupendo, pero en los comentarios hay gente preguntando cómo limitar el acceso. Esa pregunta debería estar resuelta antes de escribir la primera línea del menú.

La fatiga de notificaciones mata el sistema más rápido que un bug. Mi primera versión mandaba demasiado. Terminé silenciando el chat y perdí el único aviso que importaba. La regla que uso ahora: si un mensaje no requiere decisión ni me informa de algo que cambió, no se envía. Los resúmenes periódicos sustituyen a los avisos individuales. Me costó tres semanas de ajustes llegar a ese equilibrio, y lo retoco cada vez que añado un cron nuevo.

Telegram no es un canal fiable al 100%, y tu sistema no puede depender de él. Si Telegram se cae (pasa, aunque rara vez), mis crons siguen funcionando: solo se queda sin entregar el aviso. Todos los logs siguen escribiéndose en disco. El bot es la capa de comodidad, no la de verdad. Diseña como si Telegram fuera un lujo, no una dependencia.

El polling consume poco, pero las conexiones largas se cortan. Si usas long polling, asume que la conexión morirá cada cierto tiempo y que tu código debe reconectar sin drama. Con systemd y Restart=always el problema desaparece, pero si tu bot no corre como servicio, te encontrarás con que dejó de escuchar hace 6 horas y no te avisó nadie.

Qué me costó todo esto (cifras reales)

Por si alguien quiere replicarlo, estos son mis números a agosto de 2026:

• Hardware: la Raspberry Pi 5 de 8 GB con su fuente oficial de 27 W y un HAT NVMe para no depender de la microSD me salió por unos 140 € en total. Consumo eléctrico: unos 5 W en reposo, que al precio actual de la luz son menos de 8 € al año.
• APIs de IA: 18 € al mes, casi todo en DeepSeek. El bot de Telegram en sí no cuesta nada: la API de bots es gratuita y sin límites prácticos para un uso personal.
• Tiempo: la primera versión funcional (un bot con 5 comandos y avisos de un solo cron) me llevó una tarde de domingo, unas 4 horas. El sistema actual es acumulación de tres meses, pero cada pieza individual fue de menos de una hora.

Comparado con lo que cuesta un VPS pequeño (5-10 €/mes) la Pi sale cara el primer año y gratis después, pero la razón de fondo no es el dinero: es que quiero que mis datos y mis agentes estén en hardware que puedo desconectar con la mano.

Cómo empezar hoy si no tienes nada montado

Si esto te suena bien pero partes de cero, mi consejo es que no intentes montar mi sistema entero. Empieza por lo mínimo que da valor:

Semana 1: crea el bot, pon la whitelist, y haz que un solo script te mande un mensaje cuando termine. Puede ser un backup, un scraper, lo que sea. El objetivo es experimentar que el servidor te habla.

Semana 2: añade el sentido inverso. Un comando (/estado) que te devuelva CPU, RAM, disco y temperatura de la Pi. Ya tienes un panel de control en el chat.

Semana 3: mete la primera regla de decisión. Si un proceso falla, que el bot lo reintente una vez antes de avisarte. Ese es el germen del auto-healing.

A partir de ahí, cada necesidad que tengas en el día a día es un comando nuevo. El sistema crece por necesidad real, no por diseño previo. El mío creció exactamente así, y por eso cada pieza tiene un motivo de existir.