Despliegue de un bot de Telegram en producción en un VPS: aiogram, systemd y Nginx
TL;DR
En esta guía detallada, configuraremos y desplegaremos paso a paso un bot de Telegram basado en el framework aiogram 3.x en un servidor privado virtual (VPS), utilizando systemd para la gestión de procesos y Nginx como proxy inverso para garantizar la seguridad y estabilidad. También configuraremos copias de seguridad automáticas y monitoreo para que su bot funcione de manera confiable 24/7.
Aprenderá a elegir un VPS adecuado y prepararlo para su funcionamiento.
Instalaremos Python 3.12, aiogram 3.x, Gunicorn y Nginx.
Configuraremos un servicio systemd para el inicio y reinicio automático del bot.
Aseguraremos una conexión HTTPS para los webhooks de Nginx con Let's Encrypt.
Implementación de las mejores prácticas para copias de seguridad, mantenimiento y resolución de problemas.
Su bot de Telegram funcionará de forma estable, segura y automática.
Qué configuramos y por qué
Diagrama: Qué configuramos y por qué
Desplegaremos un bot de Telegram escrito en Python utilizando el framework aiogram 3.x en un entorno de producción en un VPS. La tarea principal es asegurar su funcionamiento estable, seguro y automatizado sin necesidad de intervención manual después de la configuración inicial. Al final, obtendrá un bot de Telegram confiable que procesará las solicitudes de los usuarios 24/7, utilizando webhooks para recibir actualizaciones instantáneas de la API de Telegram.
El uso de webhooks (en lugar de long polling) es el método preferido para los bots de producción, ya que reduce significativamente la carga del servidor al eliminar la necesidad de consultar constantemente la API de Telegram. Cuando ocurre un evento (por ejemplo, un nuevo mensaje), Telegram envía una solicitud HTTP a su servidor. Para recibir estas solicitudes, necesitaremos el servidor web Nginx, que actuará como un proxy inverso, redirigiendo las solicitudes a nuestro bot, y también proporcionará cifrado TLS/SSL, que es un requisito obligatorio de Telegram para los webhooks.
Alternativas: Cloud-Managed vs. Self-Hosted
Existen varios enfoques para el despliegue de bots de Telegram:
Cloud-Managed (Serverless/PaaS): Soluciones como AWS Lambda, Google Cloud Functions, Heroku, Vercel o PythonAnywhere permiten desplegar rápidamente un bot sin necesidad de conocimientos profundos de administración de servidores. Ofrecen escalado automático y gestión de infraestructura.
Ventajas: Facilidad de despliegue, no es necesario administrar el servidor, escalado automático.
Desventajas: Flexibilidad limitada, costo potencialmente más alto con grandes cargas, dependencia de un proveedor específico, a veces dificultades con el almacenamiento persistente.
Self-Hosted en VPS/Dedicado: Alojar el bot en su propio VPS o servidor dedicado le otorga control total sobre el entorno.
Ventajas: Control total sobre la configuración, mayor flexibilidad, costo potencialmente más bajo a largo plazo, confidencialidad de los datos, posibilidad de alojar múltiples servicios en un mismo servidor.
Desventajas: Requiere conocimientos de administración de Linux, configuración y soporte manuales, responsabilidad por la seguridad y estabilidad.
Para aquellos que valoran el control total, la flexibilidad y desean comprender profundamente el proceso, el enfoque autoalojado en un VPS es la elección óptima. Permite adquirir una valiosa experiencia trabajando con Linux, servidores web y servicios del sistema, lo cual es crucial para cualquier desarrollador o fundador.
Qué configuración de VPS se necesita para esta tarea
Diagrama: Qué configuración de VPS se necesita para esta tarea
Los requisitos de VPS para un bot de Telegram pueden variar mucho dependiendo de su funcionalidad, número de usuarios e intensidad de uso. Para la mayoría de los bots, especialmente en la etapa inicial, no se requiere hardware potente.
Requisitos mínimos (para un bot pequeño de hasta 1000 usuarios activos):
CPU: 1 núcleo (x86-64). Los procesadores modernos son lo suficientemente potentes.
RAM: 1-2 GB. Las aplicaciones Python y Nginx con systemd ocupan alrededor de 300-500 MB de RAM, el resto es para caché y cargas pico.
Disco: 25-50 GB SSD. El SSD acelera significativamente el funcionamiento del sistema y las operaciones de disco. El volumen es necesario para el SO, los registros, el código del bot y posibles datos (por ejemplo, bases de datos SQLite).
Red: 100 Mbps, preferiblemente 1 Gbps. Para los webhooks es importante un canal estable y rápido, pero para la mayoría de los bots no se requiere un ancho de banda enorme.
Plan de VPS recomendado para un bot mediano (hasta 10 000 usuarios activos, con base de datos):
CPU: 2 núcleos.
RAM: 4 GB.
Disco: 100-150 GB SSD. Si se planea usar PostgreSQL/MongoDB en el mismo servidor, es mejor 200 GB.
Red: Puerto de 1 Gbps con suficiente volumen de tráfico (1-2 TB al mes).
Cuándo se necesita un Servidor Dedicado y no un VPS
Un servidor dedicado (dedicated server) suele ser necesario para proyectos muy grandes:
Carga muy alta: Decenas y cientos de miles de usuarios activos, cálculos intensivos, procesamiento de grandes volúmenes de datos.
Requisitos de hardware específicos: Por ejemplo, GPU para modelos de IA, una cantidad muy grande de RAM (64 GB+), arreglos RAID para la tolerancia a fallos de los discos.
Máximo rendimiento y aislamiento: Cuando el VPS puede estar sujeto al efecto "vecino ruidoso" (reducción del rendimiento debido a otros usuarios en el mismo servidor físico).
Para la mayoría de los bots de Telegram, un VPS es más que suficiente. Si su bot crece hasta una escala que requiera un servidor dedicado, lo sabrá por el monitoreo de recursos.
Ubicación: en qué influye
La elección de la ubicación del VPS es importante por varias razones:
Latencia: Cuanto más cerca esté el servidor de su audiencia objetivo (y de los servidores de la API de Telegram), menor será la latencia. Para los bots de Telegram, esto no es tan crítico como para los juegos en línea, pero una latencia más baja siempre es mejor.
Legislación: En algunos países puede haber leyes estrictas sobre el almacenamiento de datos o restricciones sobre cierto contenido. Asegúrese de que la ubicación elegida cumpla con sus requisitos legales.
Costo: Los precios de los VPS pueden variar según la ubicación.
Para una audiencia de habla rusa y la mayoría de los países europeos, una buena opción es un VPS en Alemania, Países Bajos o Finlandia. Si su audiencia está en EE. UU., elija una ubicación en la costa este u oeste de EE. UU.
Preparación del servidor
Diagrama: Preparación del servidor
Después de obtener acceso a un VPS nuevo (se asume que es Debian 12/13 o Ubuntu 24.04 LTS), es necesario realizar una serie de configuraciones básicas para mejorar la seguridad y la comodidad de uso.
1. Actualización del sistema
Lo primero es siempre actualizar la lista de paquetes y los paquetes instalados a las versiones más recientes.
sudo apt update # Actualizamos la lista de paquetes disponibles
sudo apt upgrade -y # Actualizamos los paquetes instalados, -y para confirmación automática
sudo apt autoremove -y # Eliminamos paquetes innecesarios que quedaron después de las actualizaciones
2. Creación de un nuevo usuario y configuración de sudo
Trabajar con la cuenta root no es seguro. Cree un nuevo usuario y otórguele permisos sudo.
sudo adduser botuser # Creamos un nuevo usuario llamado botuser
sudo usermod -aG sudo botuser # Añadimos el usuario botuser al grupo sudo
Ahora, salga de la sesión root (si está en ella) e inicie sesión con el nuevo usuario:
exit # Salimos de la sesión actual
ssh botuser@SU_IP_DEL_SERVIDOR # Iniciamos sesión con el nuevo usuario
3. Configuración de claves SSH (recomendado)
Para un acceso más seguro al servidor, utilice claves SSH en lugar de contraseñas. Si aún no tiene una clave SSH, genérela en su computadora local:
ssh-keygen -t ed25519 -C "[email protected]" # Generamos una nueva clave SSH (en la máquina local)
Luego, copie la clave pública al servidor:
ssh-copy-id botuser@SU_IP_DEL_SERVIDOR # Copiamos la clave pública al servidor (en la máquina local)
Después de esto, puede deshabilitar la autenticación por contraseña en el archivo /etc/ssh/sshd_config para el usuario root y en general. Busque y modifique las siguientes líneas:
sudo nano /etc/ssh/sshd_config # Abrimos el archivo de configuración del servidor SSH
Modifique o añada:
# PermitRootLogin prohibit-password (o no)
PasswordAuthentication no
ChallengeResponseAuthentication no
UsePAM no
Reinicie el servicio SSH:
sudo systemctl restart sshd # Reiniciamos el servicio SSH
4. Configuración del firewall (UFW)
Uncomplicated Firewall (UFW) es una utilidad conveniente para administrar iptables. Permitiremos solo los puertos necesarios: SSH (22), HTTP (80) y HTTPS (443).
sudo apt install ufw -y # Instalamos UFW
sudo ufw default deny incoming # Denegamos todas las conexiones entrantes por defecto
sudo ufw default allow outgoing # Permitimos todas las conexiones salientes por defecto
sudo ufw allow OpenSSH # Permitimos conexiones SSH (puerto 22)
sudo ufw allow http # Permitimos conexiones HTTP (puerto 80)
sudo ufw allow https # Permitimos conexiones HTTPS (puerto 443)
sudo ufw enable # Habilitamos el firewall. Confirme con 'y'
sudo ufw status verbose # Verificamos el estado del firewall
5. Instalación de Fail2Ban
Fail2Ban escanea los registros de los servicios (SSH, Nginx, etc.) y bloquea las direcciones IP desde las cuales se producen intentos de adivinación de contraseñas u otras acciones maliciosas.
sudo apt install fail2ban -y # Instalamos Fail2Ban
sudo systemctl enable fail2ban # Habilitamos el inicio automático del servicio al arrancar
sudo systemctl start fail2ban # Iniciamos Fail2Ban
sudo systemctl status fail2ban # Verificamos el estado del servicio
La configuración básica de Fail2Ban ya es bastante buena, pero puede crear un archivo /etc/fail2ban/jail.local para personalizarla:
Ahora que el servidor está preparado, instalaremos el software necesario para nuestro bot.
1. Instalación de Python y entorno virtual
Para el año 2026, la versión actual de Python será probablemente Python 3.12 o 3.13. Instalaremos Python 3.12 y crearemos un entorno virtual aislado para el bot.
sudo apt install python3.12 python3.12-venv python3.12-dev -y # Instalamos Python 3.12, venv y archivos dev
Crearemos un directorio para nuestro proyecto y un entorno virtual dentro de él:
mkdir ~/my_telegram_bot # Creamos un directorio para el proyecto
cd ~/my_telegram_bot # Nos movemos al directorio del proyecto
python3.12 -m venv .venv # Creamos un entorno virtual con Python 3.12
source .venv/bin/activate # Activamos el entorno virtual
Después de activar el entorno virtual (verá (.venv) al principio de la línea de comandos), todos los paquetes de Python instalados estarán aislados en este directorio.
2. Instalación de dependencias de Python
Instalaremos aiogram, gunicorn (servidor ASGI para ejecutar nuestra aplicación) y python-dotenv para trabajar con variables de entorno.
Nginx actuará como un proxy inverso para nuestro bot, aceptando solicitudes de la API de Telegram y reenviándolas a Gunicorn, que ejecuta el bot. Nginx también gestionará los certificados SSL.
sudo apt install nginx -y # Instalamos Nginx
sudo systemctl enable nginx # Habilitamos el inicio automático de Nginx al arrancar
sudo systemctl start nginx # Iniciamos Nginx
sudo systemctl status nginx # Verificamos el estado de Nginx
4. Instalación de Certbot (para Let's Encrypt)
Certbot es una utilidad para obtener y renovar automáticamente certificados SSL/TLS de Let's Encrypt, necesarios para la conexión HTTPS.
sudo apt install certbot python3-certbot-nginx -y # Instalamos Certbot y el plugin para Nginx
Configuración
Diagrama: Configuración
Ahora que todos los componentes están instalados, procederemos a configurarlos.
1. Código del bot de Telegram
Crearemos un archivo simple bot.py en el directorio ~/my_telegram_bot. Este archivo contendrá la lógica de nuestro bot.
nano ~/my_telegram_bot/bot.py
Contenido de bot.py:
import os
from dotenv import load_dotenv
from aiogram import Bot, Dispatcher, types
from aiogram.enums import ParseMode
from aiogram.webhook.aiohttp_server import Simple
from aiohttp import web
# Cargamos las variables de entorno del archivo .env
load_dotenv()
# Obtenemos el token del bot de las variables de entorno
BOT_TOKEN = os.getenv("BOT_TOKEN")
WEBHOOK_HOST = os.getenv("WEBHOOK_HOST")
WEBHOOK_PATH = os.getenv("WEBHOOK_PATH")
WEB_SERVER_HOST = os.getenv("WEB_SERVER_HOST", "127.0.0.1")
WEB_SERVER_PORT = int(os.getenv("WEB_SERVER_PORT", 8000))
if not BOT_TOKEN:
raise ValueError("BOT_TOKEN environment variable not set.")
if not WEBHOOK_HOST:
raise ValueError("WEBHOOK_HOST environment variable not set.")
if not WEBHOOK_PATH:
raise ValueError("WEBHOOK_PATH environment variable not set.")
WEBHOOK_URL = f"https://{WEBHOOK_HOST}{WEBHOOK_PATH}"
# Inicialización del bot y del despachador
bot = Bot(token=BOT_TOKEN, parse_mode=ParseMode.HTML)
dp = Dispatcher()
# Manejador del comando /start
@dp.message(commands=["start"])
async def handle_start(message: types.Message):
await message.reply(f"Hola, {message.from_user.full_name}! Soy tu nuevo bot.")
# Manejador de mensajes de texto
@dp.message()
async def handle_message(message: types.Message):
await message.reply(f"Usted dijo: {message.text}")
async def on_startup(dispatcher: Dispatcher, bot: Bot):
# Establecemos el webhook al iniciar
await bot.set_webhook(WEBHOOK_URL)
print(f"Webhook establecido en: {WEBHOOK_URL}")
async def on_shutdown(dispatcher: Dispatcher, bot: Bot):
# Eliminamos el webhook al finalizar
await bot.delete_webhook()
print("Webhook eliminado.")
def main():
# Creamos una aplicación web AioHTTP para los webhooks
app = web.Application()
webhook_requests_handler = Simple(dispatcher=dp, bot=bot, path=WEBHOOK_PATH)
webhook_requests_handler.register(app, path=WEBHOOK_PATH)
# Registramos las funciones de inicio y parada
app.on_startup.append(lambda app: on_startup(dp, bot))
app.on_shutdown.append(lambda app: on_shutdown(dp, bot))
# Iniciamos el servidor web
web.run_app(app, host=WEB_SERVER_HOST, port=WEB_SERVER_PORT)
if __name__ == "__main__":
main()
2. Configuración de variables de entorno (.env)
Nunca almacene datos confidenciales (tokens, contraseñas) directamente en el código. Utilice variables de entorno. Cree un archivo .env en el directorio raíz del proyecto.
nano ~/my_telegram_bot/.env
Contenido de .env:
BOT_TOKEN="ВАШ_ТОКЕН_БОТА" # Obténgalo de @BotFather
WEBHOOK_HOST="ВАШ_ДОМЕН_ИЛИ_IP" # Por ejemplo, example.com
WEBHOOK_PATH="/webhook/bot" # Ruta única para el webhook
WEB_SERVER_HOST="127.0.0.1" # Gunicorn solo escuchará localmente
WEB_SERVER_PORT=8000 # Puerto en el que funcionará Gunicorn
Reemplace ВАШ_ТОКЕН_БОТА por el token real obtenido de @BotFather, y ВАШ_ДОМЕН_ИЛИ_IP por su dominio o dirección IP pública del VPS.
3. Configuración del servicio Systemd para el bot
Systemd nos permitirá ejecutar el bot como un servicio del sistema, reiniciarlo automáticamente en caso de fallos y gestionarlo.
[Unit]
Description=Telegram Bot Service
After=network.target
[Service]
User=botuser # Usuario bajo el cual se ejecutará el bot
Group=www-data # Grupo, si es necesario para acceder a los archivos de Nginx
WorkingDirectory=/home/botuser/my_telegram_bot # Directorio de trabajo del proyecto
EnvironmentFile=/home/botuser/my_telegram_bot/.env # Ruta al archivo con variables de entorno
ExecStart=/home/botuser/my_telegram_bot/.venv/bin/gunicorn --workers 1 --bind 127.0.0.1:8000 bot:app # Inicio de Gunicorn
Restart=always
RestartSec=5 # Reiniciar 5 segundos después de un fallo
StandardOutput=journal
StandardError=journal
SyslogIdentifier=telegram-bot
[Install]
WantedBy=multi-user.target
Nota importante: En aiogram 3.x los webhooks se configuran a través de aiohttp.web.Application. Gunicorn puede ejecutar aplicaciones aiohttp. La línea ExecStart indica a Gunicorn que debe iniciar la aplicación app del módulo bot. En nuestro bot.py ejecutamos web.run_app dentro de main(). Para Gunicorn, necesitamos exportar app de bot.py. Modificaremos bot.py para que app esté disponible para Gunicorn:
# ... (inicio del archivo bot.py) ...
# Creamos una aplicación web AioHTTP para los webhooks
app = web.Application()
webhook_requests_handler = Simple(dispatcher=dp, bot=bot, path=WEBHOOK_PATH)
webhook_requests_handler.register(app, path=WEBHOOK_PATH)
# Registramos las funciones de inicio y parada
app.on_startup.append(lambda app_instance: on_startup(dp, bot))
app.on_shutdown.append(lambda app_instance: on_shutdown(dp, bot))
# ... (fin del archivo bot.py) ...
# Elimine o comente el bloque if __name__ == "__main__":
# if __name__ == "__main__":
# main()
Ahora Gunicorn podrá encontrar e iniciar app. Después de editar el archivo de servicio, recargue systemd e inicie el bot:
sudo systemctl daemon-reload # Recargamos systemd para que vea el nuevo servicio
sudo systemctl enable telegram-bot # Habilitamos el inicio automático del bot al arrancar
sudo systemctl start telegram-bot # Iniciamos el servicio del bot
sudo systemctl status telegram-bot # Verificamos el estado del bot
Asegúrese de que el servicio esté en ejecución y no contenga errores. Los registros se pueden ver con el comando: sudo journalctl -u telegram-bot -f.
4. Configuración de Nginx como proxy inverso
Crearemos un archivo de configuración de Nginx para nuestro bot. Reemplace example.com por su dominio.
sudo nano /etc/nginx/sites-available/telegram-bot
Contenido de telegram-bot:
server {
listen 80;
server_name ВАШ_ДОМЕН_ИЛИ_IP; # Por ejemplo, example.com
location / {
return 301 https://$host$request_uri; # Redirigimos todo el tráfico HTTP a HTTPS
}
}
server {
listen 443 ssl;
server_name ВАШ_ДОМЕН_ИЛИ_IP; # Por ejemplo, example.com
ssl_certificate /etc/letsencrypt/live/ВАШ_ДОМЕН_ИЛИ_IP/fullchain.pem; # Será creado por Certbot
ssl_certificate_key /etc/letsencrypt/live/ВАШ_ДОМЕН_ИЛИ_IP/privkey.pem; # Será creado por Certbot
ssl_protocols TLSv1.2 TLSv1.3; # Protocolos recomendados
ssl_ciphers "EECDH+AESGCM:EDH+AESGCM:AES256+EECDH:AES256+EDH";
ssl_prefer_server_ciphers on;
ssl_session_cache shared:SSL:10m;
ssl_session_timeout 10m;
location /webhook/bot { # Debe coincidir con WEBHOOK_PATH en .env
proxy_pass http://127.0.0.1:8000; # Hacemos proxy de las solicitudes a Gunicorn
proxy_set_header Host $host;
proxy_set_header X-Real-IP $remote_addr;
proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
proxy_set_header X-Forwarded-Proto $scheme;
proxy_redirect off;
proxy_buffering off; # Deshabilitamos el almacenamiento en búfer para los webhooks
}
# Si el bot va a servir estáticos o tener otros endpoints HTTP
# location / {
# root /var/www/html;
# index index.html;
# }
}
Cree un enlace simbólico a este archivo desde sites-enabled y verifique la configuración de Nginx:
sudo ln -s /etc/nginx/sites-available/telegram-bot /etc/nginx/sites-enabled/ # Creamos un enlace simbólico
sudo nginx -t # Verificamos la sintaxis de la configuración de Nginx
sudo systemctl restart nginx # Reiniciamos Nginx
5. Obtención del certificado SSL con Certbot
Ahora que Nginx está configurado, obtendremos el certificado SSL. Asegúrese de que su dominio ya apunte a la dirección IP de su VPS.
sudo certbot --nginx -d ВАШ_ДОМЕН_ИЛИ_IP # Ejecute Certbot, reemplazando por su dominio
Certbot hará algunas preguntas (correo electrónico, acuerdo con los términos). Modificará automáticamente la configuración de Nginx, añadiendo ssl_certificate y ssl_certificate_key. Después de obtener el certificado con éxito, Nginx se reiniciará automáticamente.
Verifique que Certbot haya configurado la renovación automática del certificado:
sudo systemctl status certbot.timer # Verificamos el estado del temporizador para la renovación automática
Certbot suele crear una tarea cron o un temporizador systemd para la renovación automática de certificados. Esto ocurre dos veces al día, y el certificado se renueva si su validez expira en un plazo de 30 días.
6. Verificación del funcionamiento
Después de todas las configuraciones, asegúrese de que el bot esté funcionando y sea accesible:
Verificación de Nginx: Abra en el navegador https://ВАШ_ДОМЕН_ИЛИ_IP/. Si ve la página de bienvenida de Nginx o una redirección, significa que Nginx está funcionando.
Verificación del webhook: Intente enviar un mensaje a su bot en Telegram. Debería responder.
Verificación del servicio systemd:
sudo systemctl status telegram-bot
sudo journalctl -u telegram-bot -f # Ver registros del bot en tiempo real
Debería ver mensajes sobre el inicio del bot y la configuración del webhook.
Verificación del puerto de Gunicorn: Desde el servidor puede verificar si Gunicorn está escuchando en el puerto local:
ss -ltn | grep 8000
Debería ver una línea que indique que 127.0.0.1:8000 está en estado LISTEN.
Copias de seguridad y mantenimiento
Diagrama: Copias de seguridad y mantenimiento
Una estrategia de copias de seguridad fiable y un mantenimiento regular son cruciales para cualquier servicio en producción.
1. Qué respaldar
Código del bot: Directorio ~/my_telegram_bot/ (sin .venv).
Archivos de configuración:.env, /etc/systemd/system/telegram-bot.service, /etc/nginx/sites-available/telegram-bot, /etc/nginx/sites-enabled/telegram-bot.
Datos del bot: Si el bot utiliza una base de datos (SQLite, PostgreSQL, MongoDB), es necesario hacer copias de seguridad de sus datos regularmente. Para SQLite es simplemente un archivo, para PostgreSQL/MongoDB es un volcado de la base de datos.
Claves SSH: (opcional, pero útil) ~/.ssh/.
2. Script simple de copia de seguridad automática
Usamos rsync para crear copias de archivos y pg_dump (si tienes PostgreSQL) para la base de datos.
nano ~/backup_script.sh
Contenido de backup_script.sh:
#!/bin/bash
# Directorio para copias de seguridad
BACKUP_DIR="/var/backups/telegram_bot"
# Directorio con el código del bot
BOT_CODE_DIR="/home/botuser/my_telegram_bot"
# Nombre del archivo de la base de datos SQLite (si se usa)
SQLITE_DB_NAME="bot_database.db"
# Nombre de la base de datos PostgreSQL (si se usa)
POSTGRES_DB_NAME="telegram_bot_db"
# Usuario de PostgreSQL
POSTGRES_USER="botuser"
# Creamos el directorio para las copias de seguridad si no existe
mkdir -p "$BACKUP_DIR"
# 1. Copia de seguridad del código del bot y .env
echo "Starting code and .env backup..."
rsync -avz --exclude '.venv/' "$BOT_CODE_DIR/" "$BACKUP_DIR/code_$(date +%Y%m%d_%H%M%S)/"
cp "$BOT_CODE_DIR/.env" "$BACKUP_DIR/config_$(date +%Y%m%d_%H%M%S)/.env"
# 2. Copia de seguridad de los archivos de configuración de Nginx y Systemd
echo "Starting config files backup..."
cp /etc/systemd/system/telegram-bot.service "$BACKUP_DIR/config_$(date +%Y%m%d_%H%M%S)/telegram-bot.service"
cp /etc/nginx/sites-available/telegram-bot "$BACKUP_DIR/config_$(date +%Y%m%d_%H%M%S)/nginx_telegram-bot"
# 3. Copia de seguridad de la base de datos (elija la opción adecuada)
# Para SQLite:
if [ -f "$BOT_CODE_DIR/$SQLITE_DB_NAME" ]; then
echo "Starting SQLite database backup..."
cp "$BOT_CODE_DIR/$SQLITE_DB_NAME" "$BACKUP_DIR/db_sqlite_$(date +%Y%m%d_%H%M%S).db"
fi
# Para PostgreSQL (descomentar si se usa)
# echo "Starting PostgreSQL database backup..."
# PGPASSWORD="TU_CONTRASEÑA_POSTGRES" pg_dump -U "$POSTGRES_USER" -Fc "$POSTGRES_DB_NAME" > "$BACKUP_DIR/db_pg_$(date +%Y%m%d_%H%M%S).dump"
echo "Backup finished."
# Limpieza de copias de seguridad antiguas (conservamos las últimas 7 días)
find "$BACKUP_DIR" -type d -name "code_" -mtime +7 -exec rm -rf {} \;
find "$BACKUP_DIR" -type d -name "config_" -mtime +7 -exec rm -rf {} \;
find "$BACKUP_DIR" -type f -name "db_sqlite_.db" -mtime +7 -delete
find "$BACKUP_DIR" -type f -name "db_pg_.dump" -mtime +7 -delete
Haga el script ejecutable:
chmod +x ~/backup_script.sh
Añada el script a cron para su ejecución diaria. Abra crontab para el usuario botuser:
crontab -e
Añada la siguiente línea al final del archivo para ejecutar el script, por ejemplo, cada día a las 3:00 de la madrugada:
Almacenar las copias de seguridad en el mismo servidor que el servicio principal no es seguro. En caso de fallo del servidor o del disco, perderá tanto el servicio como las copias de seguridad. Se recomienda:
Almacenamiento de objetos externo compatible con S3: AWS S3, DigitalOcean Spaces, Backblaze B2, MinIO. Es una solución fiable y escalable. Para el envío automático se puede usar rclone.
VPS separado: Un VPS económico en otro centro de datos, donde copiará las copias de seguridad vía SSH/rsync.
Almacenamiento local con sincronización: Por ejemplo, Google Drive/Dropbox a través de rclone.
Para copias de seguridad más avanzadas, considere borgbackup o restic, que soportan deduplicación, cifrado y copias de seguridad incrementales.
4. Actualizaciones: Rolling vs. Ventana de Mantenimiento
Actualice regularmente el SO y el software para seguridad y estabilidad. Hay dos enfoques principales:
Maintenance Window (Ventana de mantenimiento): Tiempo planificado en el que detiene el servicio, actualiza el SO y el software, prueba y vuelve a iniciar.
Ventajas: Proceso controlado, menor riesgo de problemas inesperados.
Desventajas: El servicio no estará disponible durante la actualización.
sudo systemctl stop telegram-bot # Detenemos el bot
sudo apt update && sudo apt upgrade -y # Actualizamos el sistema
# ... (actualizamos las dependencias de Python, si es necesario)
sudo systemctl start telegram-bot # Iniciamos el bot
Rolling Updates (Actualizaciones graduales): Aplicable a clústeres o sistemas con múltiples instancias de servicio, donde se actualiza una instancia a la vez sin interrumpir el funcionamiento de todo el servicio. Para un solo VPS esto no es relevante, pero es conceptualmente importante.
Para la mayoría de los bots de Telegram, una ventana de mantenimiento una vez cada 1-2 meses es suficiente. Es importante revisar siempre los logs después de las actualizaciones.
Solución de problemas + Preguntas frecuentes
Aquí se recopilan los problemas y preguntas típicas que pueden surgir durante el despliegue y la operación del bot.
Nginx devuelve 502 Bad Gateway
Esto significa que Nginx no puede comunicarse con su servidor Gunicorn.
Qué verificar:
Asegúrese de que el servicio del bot (telegram-bot.service) esté en ejecución: sudo systemctl status telegram-bot.
Revise los logs del bot: sudo journalctl -u telegram-bot -f. Es posible que el bot no haya podido iniciarse debido a un error en el código o la ausencia de variables de entorno.
Asegúrese de que Gunicorn esté escuchando en el puerto correcto (127.0.0.1:8000 en nuestro caso): ss -ltn | grep 8000.
Revise el archivo de configuración de Nginx (/etc/nginx/sites-available/telegram-bot) en busca de errores en proxy_pass.
El bot no responde a los mensajes en Telegram
Si el bot no responde, pero Nginx funciona (no hay 502), el problema puede estar en el webhook o en la lógica del bot.
Qué verificar:
Revise los logs del bot (sudo journalctl -u telegram-bot -f). Es posible que haya errores en los manejadores de mensajes.
Asegúrese de que la API de Telegram pudo establecer el webhook: en los logs del bot al iniciar, debería haber una línea Webhook establecido en: https://TU_DOMINIO/webhook/bot.
Verifique que su dominio se resuelva correctamente a la dirección IP de su VPS (use dig TU_DOMINIO).
Asegúrese de que el firewall (UFW) permite las conexiones entrantes en los puertos 80 y 443 (sudo ufw status verbose).
Use el método getWebhookInfo de la API de Telegram Bot para verificar el estado del webhook: https://api.telegram.org/botTU_TOKEN_DEL_BOT/getWebhookInfo. Asegúrese de que la url sea correcta y que last_error_message esté vacío.
Certbot no puede obtener un certificado
Esto suele estar relacionado con problemas de disponibilidad de su dominio.
Qué verificar:
Asegúrese de que su dominio (o subdominio) apunte correctamente a la dirección IP de su VPS en los registros DNS. Use dig TU_DOMINIO.
Verifique que Nginx esté en ejecución y escuchando correctamente en el puerto 80 (sudo systemctl status nginx).
Asegúrese de que el firewall (UFW) permite las conexiones entrantes en el puerto 80 (sudo ufw status verbose). Certbot usa el puerto 80 para el desafío HTTP-01.
Deshabilite temporalmente la configuración de Nginx del bot si interfiere con Certbot.
¿Qué configuración mínima de VPS es adecuada?
Para un bot de Telegram simple con una audiencia pequeña (hasta 1000 usuarios activos), un VPS con 1 núcleo de CPU, 1-2 GB de RAM y 25-50 GB de SSD será suficiente. Esto será suficiente para el sistema operativo, el entorno Python, el bot, Nginx y un pequeño volumen de logs. Para bots más complejos con una base de datos activa o cálculos intensivos, se requerirán más recursos.
¿Qué elegir: VPS o dedicado para esta tarea?
Para la gran mayoría de los bots de Telegram, un VPS es la opción óptima. Ofrece suficiente rendimiento, flexibilidad y rentabilidad. Un servidor dedicado solo es necesario para proyectos muy grandes con decenas de miles de usuarios simultáneos, requisitos de hardware específicos (por ejemplo, GPU) o cuando se necesita la máxima aislamiento y rendimiento garantizado. Comience con un VPS y escale a un dedicado si surge una necesidad real.
¿Cómo actualizar las dependencias de Python (aiogram, gunicorn)?
Para actualizar las dependencias de Python, active el entorno virtual y use pip.
Pasos:
Vaya al directorio del proyecto: cd ~/my_telegram_bot
Active el entorno virtual: source .venv/bin/activate
Actualice los paquetes: pip install --upgrade aiogram gunicorn python-dotenv
Desactive el entorno: deactivate
Reinicie el servicio del bot: sudo systemctl restart telegram-bot
Conclusiones y próximos pasos
Diagrama: Conclusiones y próximos pasos
Hemos desplegado con éxito una infraestructura lista para producción para un bot de Telegram en un VPS, utilizando aiogram, systemd y Nginx. Su bot ahora funciona como un servicio de sistema fiable, se inicia automáticamente al reiniciar el servidor, procesa solicitudes a través de una conexión HTTPS segura y cuenta con un sistema básico de copias de seguridad.
Para el desarrollo y la optimización futuros de su proyecto, considere los siguientes pasos:
Monitorización: Implemente un sistema de monitorización (por ejemplo, Prometheus + Grafana o Datadog) para rastrear la carga de CPU, RAM, disco, tráfico de red y el estado del propio bot.
Base de datos: Si el bot va a almacenar muchos datos, migre de SQLite a un SGBD completo, como PostgreSQL o MongoDB, posiblemente en un servidor separado o en un servicio de nube gestionado.
CI/CD: Configure un pipeline de integración y entrega continua (CI/CD) utilizando GitHub Actions, GitLab CI o Jenkins para automatizar el despliegue de nuevas versiones del código del bot.
¿Te fue útil esta guía?
Tus comentarios nos ayudan a mejorar nuestras guías.
Compartir esta publicación:
Envía esta guía a alguien a quien pueda resultarle útil.
