La mejor forma de hospedar una aplicación Python

Python sirve para casi todo: un bot de Discord, una API en FastAPI, un sitio en Django, un script que recoge datos cada hora, un modelo de IA. Por eso la pregunta "¿dónde hospedo Python?" no tiene una sola respuesta. Un bot tiene que estar encendido las 24 horas, una tarea programada corre dos minutos al día y un modelo con torch necesita mucha RAM.

El punto de partida es el tipo de aplicación. De él salen los criterios que cambian la elección, la recomendación por escenario y lo que debes preparar antes del deploy.

¿Qué tipo de aplicación Python vas a hospedar?#

Casi todo proyecto entra en uno de estos cuatro grupos:

• Proceso de larga duración: bots de Discord y Telegram, workers de colas, scrapers continuos. Están encendidos todo el tiempo y mantienen conexiones abiertas.
• Aplicación web: APIs y sitios. Pueden ser WSGI (Flask, Django clásico), servidas por Gunicorn o Waitress, o ASGI (FastAPI, Starlette, Django asíncrono), servidas por Uvicorn. Reciben peticiones HTTP y tienen que escuchar en un puerto.
• Tarea programada: un script que corre cada cierto tiempo, como un informe diario o una limpieza de la base de datos. Pasa la mayor parte del tiempo detenido.
• IA y datos: aplicaciones que cargan modelos con torch, transformers o pandas. Aquí pesan la RAM y el tamaño de las dependencias.

El tipo define la primera decisión: si el proceso tiene que estar siempre encendido o puede despertar bajo demanda.

¿Qué criterios importan al elegir?#

1. Siempre encendido o bajo demanda. Los bots y las conexiones WebSocket exigen un proceso continuo. Las tareas cortas pueden correr bajo demanda.
2. Límite de tiempo por ejecución. Las funciones serverless tienen un tope: en AWS Lambda, una invocación dura como máximo 15 minutos.
3. RAM. Cada worker web es un proceso Python separado y suma memoria. Los modelos de IA pueden ocupar varios GB. Mira cómo dimensionar RAM y CPU.
4. Dependencias nativas. Bibliotecas como numpy, psycopg y torch traen código compilado. Si el entorno no tiene el paquete listo (wheel) para tu versión de Python y tu sistema, la instalación intenta compilar y puede fallar.
5. Versión de Python. Usa una versión que todavía tenga soporte. El calendario oficial muestra qué versiones están en esa fase y cuándo deja de recibir correcciones cada una.
6. Cuánto quieres administrar tú. Sistema operativo, actualizaciones de seguridad, firewall, proxy inverso y reinicio automático: alguien tiene que encargarse. O lo haces tú, o la plataforma donde hospedas.

¿Cuáles son las opciones y sus pros y contras?#

Dos puntos suelen inclinar la balanza. Primero, serverless no sirve para bots: Lambda limita la ejecución a 15 minutos y también el tamaño del paquete .zip, lo que deja fuera bibliotecas grandes como torch, salvo con una imagen de contenedor (los tamaños actuales están en la página de límites de Lambda). Segundo, un VPS da libertad, pero cada hora configurando el servidor es una hora fuera de tu código. Los artículos VPS o plataforma en la nube y serverless o contenedores profundizan en esas dos comparaciones.

¿Cuál es la mejor opción para cada escenario?#

• Bot de Discord, Telegram o WhatsApp: proceso siempre encendido, en una plataforma de contenedores o en un VPS. El bot se reconecta solo cuando el proceso se reinicia, siempre que algo lo reinicie.
• API en FastAPI o Flask con tráfico constante: contenedor siempre encendido, con servidor de producción. Sin cold start, la primera petición del día responde igual de rápido que las demás. Mira cómo hospedar FastAPI, Flask y Django.
• Sitio en Django con base de datos: contenedor o VPS, más una base de datos hospedada aparte. Mira la mejor base de datos para Python.
• Script que corre una vez al día: serverless con programación, o un proceso siempre encendido con un programador interno si ya tienes una aplicación corriendo.
• Aplicación con torch o transformers: contenedor o VPS con RAM de sobra. Revisa que el entorno tenga los paquetes listos para no compilar nada en el deploy.
• Aprender y probar: tu propia computadora. Cuando el proyecto tenga que quedar en línea, migra.

¿Cómo preparar la aplicación Python para producción?#

Sea cual sea la opción, cuatro hábitos evitan la mayoría de los problemas.

1. Fija las dependencias. Lista todo en requirements.txt con versión, o usa un lockfile (uv, Poetry). Así el servidor instala exactamente lo que probaste:

# versiones de ejemplo: fija las que probaste (míralas con pip freeze)
fastapi==0.143.0
uvicorn==0.54.0

2. Usa un servidor de producción. La documentación de Flask es directa: no uses el servidor de desarrollo en producción, porque no está pensado para ser seguro, estable ni eficiente. Django dice lo mismo de runserver. Para FastAPI, ejecuta Uvicorn escuchando en todas las interfaces (0.0.0.0), no solo en 127.0.0.1. Un main.py mínimo:

import os

from fastapi import FastAPI

app = FastAPI()


@app.get("/health")
def health():
    return {"status": "ok"}


if __name__ == "__main__":
    import uvicorn

    port = int(os.environ.get("PORT", "8000"))
    uvicorn.run(app, host="0.0.0.0", port=port)

Para varios procesos, la documentación de FastAPI usa la opción --workers:

uvicorn main:app --host 0.0.0.0 --port 8000 --workers 2

En Flask o Django, el equivalente es Gunicorn. La documentación de Gunicorn sugiere empezar con (2 × núcleos de CPU) + 1 workers y ajustar bajo carga. Recuerda que cada worker consume su propia RAM.

3. Lee la configuración del entorno. Tokens, contraseñas y URLs de base de datos van en variables de entorno, nunca en el código. El puerto también: cada hosting te dice cuál usar.

4. Escribe los logs en la salida estándar. Usa print o el módulo logging apuntando a stdout. Casi todo hosting muestra esa salida en su panel, y es ahí donde vas a diagnosticar errores.

¿Qué errores aparecen al hospedar Python?#

• ModuleNotFoundError: un paquete que falta en requirements.txt o un nombre de instalación distinto del nombre del import. Mira Cannot find module y ModuleNotFoundError.
• La app arranca pero nadie llega a ella: el servidor escucha en 127.0.0.1 o en un puerto distinto del que espera el hosting.
• Proceso terminado sin un error claro: falta de memoria, común con muchos workers o modelos grandes. Reduce los workers o aumenta la RAM.
• Datos que desaparecen: SQLite o archivos guardados en el disco de un entorno que se recrea en cada deploy. Usa una base de datos o un storage externo.
• La compilación falla en el deploy: la versión de Python del servidor no tiene wheel para alguna dependencia. Alinea tu versión local con la del servidor.

Cómo hacerlo en Square Cloud#

Entre los diversos runtimes de Square Cloud, como Node.js, Python y Go, el de Python trae wheels listas de torch y transformers, para que esas bibliotecas no se compilen en el deploy. Haces el deploy subiendo un ZIP en el panel, con la CLI, desde GitHub (el push hace el deploy, con la GitHub Action oficial o un webhook) o con la extensión de VS Code. El archivo de configuración squarecloud.app es opcional: el panel lo genera en el deploy (runtime, memoria, archivo principal), o lo escribes en la raíz del proyecto.

Las aplicaciones corren en contenedores siempre encendidos, sin cold start ni modo de suspensión, lo que sirve tanto para bots como para APIs. El reinicio automático viene activado en el deploy desde el panel: vuelve a arrancar la aplicación cuando el proceso termina con un error. Al iniciar, la plataforma ejecuta pip install -r requirements.txt, con las variables de entorno ya definidas, y el disco de la aplicación se conserva entre reinicios y deploys.

La RAM del plan es un pool compartido: al menos 256 MB por aplicación en segundo plano, como un bot, y 512 MB por aplicación web. El Hobby cuesta desde R$12,49 al mes, con 1 GB. Las variables de entorno se definen por aplicación en el panel, la API, la CLI o VS Code, y el cambio se aplica en el próximo reinicio, sin rebuild.

Una aplicación web escucha en 0.0.0.0, en el puerto de la variable PORT. Los snapshots manuales están disponibles en todo plan. Mira los detalles del entorno de Python en la página de runtimes.