Python · 3.13
Hosting Python 24/7
Levanta un bot en discord.py, una API FastAPI o un worker de cola y déjalo corriendo. La plataforma instala el requirements.txt en el build, arranca el proceso en un contenedor aislado y lo reinicia sola, en cualquier plan, cuando se cae.
Quién diseñó Python
Guido van Rossum, en el CWI de Ámsterdam, empezó Python en Navidad de 1989 como sucesor espiritual de ABC: indentación significativa, vocabulario corto, una forma obvia de cada cosa. La 0.9.0 salió en 1991 en alt.sources; la 1.0, en 1994. Quería un lenguaje que se leyera como prosa y trajera biblioteca para lo cotidiano, no un núcleo minimalista. El nombre viene de Monty Python, no de la serpiente.
Guido van Rossum
Doc Searls · CC BY-SA 2.0
Código que se lee
La indentación es sintaxis porque ABC se lo enseñó a Guido: el programa debería caber en la cabeza de quien lo lee, no solo de quien lo escribe. Es la diferencia visible frente a C y Perl.
Una forma obvia
Menos caminos, menos ceremonia, un vocabulario pequeño. El Zen llegó después; la apuesta ya estaba en 1991, contra lenguajes en los que cada equipo inventa un dialecto.
Del script al laboratorio
Vino con biblioteca para lo cotidiano y acabó siendo la lengua de la ciencia, la enseñanza y la automatización. El propósito era programar sin ceremonia — el alcance fue la consecuencia.
Lo que la plataforma hace por un proyecto Python
Casi todo funciona sin configuración.
requirements.txt en el build
Las dependencias se instalan cuando se construye la imagen, no en cada arranque. El contenedor sube con todo listo, y un fallo de instalación aparece en el log del build en vez de convertirse en un crash en producción.
Tres versiones, una línea de config
3.13, 3.12 y 3.11 disponibles. Cambiar es tocar VERSION en el vertracloud.config y desplegar de nuevo — no hay imagen que elegir ni Dockerfile que mantener.
Auto-reinicio con freno
El proceso que cae se reinicia solo, en cualquier plan: un traceback no tumba el servicio. Si se rompe 5 veces en 10 minutos, el auto-reinicio se desactiva durante 24 horas, en vez de reiniciar para siempre quemando tu memoria.
Logs y métricas en vivo
stdout y stderr aparecen en la terminal del panel mientras ocurren, con la CPU, la RAM y el almacenamiento del contenedor al lado. El último traceback antes de un crash queda guardado.
Lo que la gente corre en Python aquí
Del script que corre solo a la API que recibe tráfico: la misma aplicación cubre los dos papeles.
Bots en discord.py y aiogram
discord.py, hikari, aiogram y python-telegram-bot corren como proceso en segundo plano, sin puerto HTTP. El token va en las variables de entorno del panel, nunca en un .env dentro del zip.
APIs FastAPI y Flask
Publica la aplicación para recibir un subdominio en vertraweb.app con TLS. Para Flask y Django, usa Gunicorn escuchando en 0.0.0.0:80 — el servidor de desarrollo no acepta tráfico externo.
Scrapers y workers de cola
Un recolector programado, un consumidor de cola, una rutina de ETL: procesos largos que solo necesitan quedarse de pie. El auto-reinicio cubre la caída ocasional de red sin intervención.
Datos y cola en una base gestionada
Un PostgreSQL 17 creado en el panel atiende a psycopg, SQLAlchemy o asyncpg por el host interno, y un Redis 7 sirve de cola para Celery. TLS es obligatorio, y el certificado de cliente se descarga en el panel.
Versiones de Python disponibles
La 3.13 es la recomendada y la más reciente; la 3.12 y la 3.11 siguen disponibles para quien depende de un paquete que aún no acompañó. Declara VERSION en el vertracloud.config.
| Versión | vertracloud.config | Estado |
|---|---|---|
| 3.13 | VERSION=3.13 | RecomendadaMás reciente |
| 3.12 | VERSION=3.12 | |
| 3.11 | VERSION=3.11 |
La configuración entera
El vertracloud.config es un archivo INI opcional en la raíz del proyecto. MAIN apunta al archivo de entrada; VERSION elige el Python; MEMORY define el techo de RAM del contenedor.
NAME=meu-bot
MAIN=main.py
VERSION=3.13
MEMORY=512Un plan para cada etapa del proyecto
La memoria y el almacenamiento cambian según el plan; el lenguaje, no. Compara lo que abre cada plan y elige el que le sirve al proyecto hoy.
Comparar planesTambién corre aquí
Misma plataforma, mismo deploy, otro stack.
Preguntas frecuentes sobre hosting Python
Dependencia, versión y servidor de desarrollo: las tres dudas más comunes.
¿Qué versiones de Python puedo usar?
3.13 (recomendada), 3.12 y 3.11. La elección se hace con la clave VERSION en el vertracloud.config; sin ella, la aplicación arranca en la recomendada.
¿Cómo se instalan las dependencias?
Con el requirements.txt en la raíz del proyecto, durante el build. Genera el archivo con pip freeze > requirements.txt. Si un paquete no está ahí, el deploy sube y la aplicación se rompe con ModuleNotFoundError en el primer import.
Mi aplicación Flask o Django no abre en el navegador. ¿Por qué?
El servidor de desarrollo escucha en 127.0.0.1 y no recibe tráfico externo. Usa Gunicorn: gunicorn app:app --bind 0.0.0.0:80. La aplicación también tiene que estar publicada para tener subdominio.
¿Se lee el .env de mi proyecto?
No. La plataforma no carga archivos .env: las variables se registran en la pestaña de variables de entorno del panel y se inyectan en el contenedor. Es lo que evita subir secretos dentro del zip.
¿Tengo que enviar la venv en el zip?
No — y no la envíes. Deja fuera del paquete venv, .venv, __pycache__ y .cache: inflan el upload y se reconstruyen en el build. El entorno se monta en el servidor, para Linux.
Sube tu proyecto Python hoy
Crea la cuenta, envía un zip con el requirements.txt o conecta el repositorio de GitHub, y sigue la instalación de los paquetes en la terminal del panel.
Crear cuenta