Alojamiento de apps Python: despliega Django, Flask y FastAPI

El alojamiento de apps Python empieza por el proceso que tu aplicación necesita para ejecutarse. Django y Flask suelen usar un servidor WSGI; FastAPI usa un servidor ASGI. Un worker de Celery o un script programado tiene otro ciclo de vida. Elige un host que soporte esos procesos, la base de datos y el almacenamiento que tu app necesita.

Lizard publica esta guía. Comprobamos la documentación enlazada de frameworks y proveedores el 9 de septiembre de 2026. Los ejemplos usan nombres de módulos explícitos que debes adaptar a tu proyecto.

Elige el runtime antes que el host

El servidor de desarrollo es para desarrollo. Consulta la guía de despliegue oficial de Django, guía de producción de Flask y guía de workers de FastAPI.

Opciones de alojamiento Python por necesidad

Usa la comparativa de PaaS para la decisión de alojamiento más amplia. Una insignia de Python en una tabla de características no basta para confirmar soporte de worker o base de datos.

El alojamiento Python gratuito necesita un límite de carga

Un plan gratuito puede restringir peticiones salientes, dormir un proceso web inactivo, limitar la ejecución de tareas o incluir solo un crédito de prueba. Esos términos pueden valer para una demostración y ser inadecuados para un receptor de webhook o un worker de cola.

Comprueba las reglas de servicios gratuitos de Render y las características de cuenta gratuita de PythonAnywhere. Para Cloud Run, la página de precios describe el uso gratuito junto a recursos facturables. Una base de datos, registro de imágenes o uso de red pueden quedar fuera de la asignación que estás mirando.

Prueba la primera petición tras un periodo de inactividad y confirma si el trabajo programado o en segundo plano sigue ejecutándose. Describe la opción gratuita en términos de esos límites, no como alojamiento ilimitado.

Comandos de build y start

Para un proyecto que use requirements.txt, instala sus dependencias fijadas con:

python -m pip install -r requirements.txt

Usa el gestor de paquetes y lockfile que ya tenga tu repositorio si usa uv, Poetry u otra herramienta. Incluye el servidor de producción en las dependencias. No confíes en un paquete instalado solo en tu portátil.

Para Django, donde myproject/wsgi.py define la aplicación:

gunicorn myproject.wsgi:application --bind "0.0.0.0:${PORT:-3000}"

Para Flask, donde app.py exporta app:

gunicorn app:app --bind "0.0.0.0:${PORT:-3000}"

Para FastAPI, donde main.py exporta app:

uvicorn main:app --host 0.0.0.0 --port "${PORT:-3000}"

Estos comandos esperan un shell que expanda la variable de puerto. Un CMD Docker en array JSON no la expande automáticamente. Usa el soporte de variables documentado del runtime, un wrapper de shell, o un pequeño programa que lea el entorno.

Ajusta la cuenta de workers a partir de mediciones y memoria disponible. Más procesos pueden usar más memoria y conexiones a base de datos; añadir workers no sustituye a comprobar una consulta lenta o una tarea bloqueante.

Un contenedor FastAPI mínimo

Para una aplicación con main.py y un requirements.txt bloqueado que contiene FastAPI y Uvicorn, este Dockerfile inicia un proceso de servidor:

FROM python:3.12-slim
WORKDIR /app
COPY requirements.txt .
RUN pip install --no-cache-dir -r requirements.txt
COPY . .
RUN useradd --create-home appuser
USER appuser
EXPOSE 3000
CMD ["sh", "-c", "exec uvicorn main:app --host 0.0.0.0 --port ${PORT:-3000}"]

Elige una versión de Python compatible con tu proyecto. Pon .env, entornos virtuales locales, cachés y datos de Git en .dockerignore. Este ejemplo no instala paquetes extra de sistema operativo; añade solo los que necesiten tus dependencias.

En Lizard, puedes traer un Dockerfile o usar la ruta de build desde código fuente. La guía de despliegue explica las opciones. Tu app debería exponer un pequeño endpoint de health, y también deberías probar un endpoint que ejercite sus dependencias reales.

Un despliegue FastAPI comprobado en Lizard

Nuestro ejemplo público de FastAPI tiene un registro de despliegue fechado el 9 de septiembre de 2026. La prueba usó commit df522c1, construido desde GitHub en eu-west-lim-a, con puerto 8000 y un comando de arranque Uvicorn en el Procfile. Usó Python 3.13 con FastAPI 0.141.1 y Uvicorn 0.52.4. No se estableció build manual ni sobrescritura de start.

El registro de comprobación publicado informa de seis comprobaciones superadas a través de la URL HTTPS pública:

Abre el endpoint de health en vivo, prueba la interfaz API, o sigue la guía de despliegue FastAPI.

Estos resultados cubren el despliegue y el comportamiento HTTP para una app pequeña sin base de datos. No miden uptime, capacidad de carga ni tiempo de despliegue end-to-end. El mismo registro da una lectura CLI a las 11:48 UTC de unos 0.034 GB de memoria y unos $0.00051/hora en coste de recursos. Es una lectura en un momento, no una factura mensual; la lectura citada usó las tarifas vigentes en ese momento. El alojamiento actual de Lizard usa pay as you go sin suscripción mensual; almacenamiento, tráfico y comisiones de pago pueden sumar al total. El Dockerfile de arriba es un ejemplo separado y no reproduce la configuración exacta de ese despliegue.

Django, Postgres y Celery necesitan comprobaciones separadas

Conecta Managed Postgres a través de la variable que lean los settings de Django. Ejecuta migraciones como un paso de release controlado, no de forma independiente en cada worker web. Configura el manejo de archivos estáticos y da a los archivos subidos almacenamiento duradero.

Ejecuta Celery como un servicio separado con el mismo código de aplicación relevante y su propio comando de arranque. Configura el broker explícitamente, por ejemplo con Managed Redis si tu aplicación usa Redis. Comprueba reintentos, manejo de tareas duplicadas y apagado antes de aceptar trabajo de producción.

Para un servidor que operas tú, usa la guía VPS de Django. Para un worker gestionado, ve la referencia de despliegue de worker.

Estima la aplicación Python completa

Incluye procesos web, workers, base de datos, archivos almacenados, backups, transferencia y el plan que tu equipo necesite. Railway mide el consumo y aplica su plan de pago al uso. Render publica planes de instancia. PythonAnywhere lista actualmente Developer a $10/mes; comprueba sus características incluidas contra tu app. Fuentes: Railway, Render, PythonAnywhere.

Lizard no tiene suscripción mensual ni cuota por plan de servicio. Para una app pequeña que promedia 0.01 vCPU y 0.1 GB de memoria durante 720 horas, con 10 GB de salida, los cargos de recursos totalizan unos $1.53 antes de comisiones de pago e impuestos. Añade la base de datos, worker y almacenamiento que tu app Python necesite. Ve el ejemplo trabajado y tarifas actuales. Los créditos comprados no expiran, así que un mes tranquilo no requiere comprar otro plan.

FAQ

¿Puedo alojar FastAPI en los mismos servicios que Django? A menudo sí, pero FastAPI necesita un servidor ASGI. Confirma que el host soporta tu comando de arranque y cualquier conexión duradera o worker que use la app.

¿Debo usar runserver en producción? No. Usa un servidor WSGI o ASGI de producción y revisa la guía de despliegue del framework.

¿Por qué dice el host que mi app no está sana? Revisa los logs de build, estado de salida del proceso, ruta de importación, interfaz vinculada y puerto esperado. Luego comprueba variables faltantes y conexiones de dependencias.

¿Necesito un Dockerfile? No en todos los hosts. Un builder de código fuente puede crear la imagen, pero sigues necesitando dependencias correctas y un comando de arranque de producción.

¿Cuál es el mejor host para un worker de Python? Uno que soporte el ciclo de vida y dependencias del worker. Prueba consumo de cola, reintentos y comportamiento de reinicio; un despliegue solo HTTP no basta.