Python · 3.13
Python hosting 24/7
Put up a discord.py bot, a FastAPI API or a queue worker and leave it running. The platform installs requirements.txt at build, starts the process in an isolated container and restarts it on its own, on every plan, when it goes down.
Who designed Python
Guido van Rossum, at CWI in Amsterdam, started Python at Christmas 1989 as a spiritual successor to ABC: significant indentation, a short vocabulary, one obvious way to do each thing. 0.9.0 landed on alt.sources in 1991; 1.0 in 1994. He wanted a language you could read like prose, with a library for everyday work, not a minimal core. The name comes from Monty Python, not the snake.

Guido van Rossum
Doc Searls · CC BY-SA 2.0
Code you can read
Indentation is syntax because ABC taught Guido that: the program should fit in the head of the person who reads it, not only the person who writes it. That is the visible difference from C and Perl.
One obvious way
Fewer paths, less ceremony, a small vocabulary. The Zen came later; the bet was already there in 1991, against languages where every team invents a dialect.
From script to lab
It shipped with a library for everyday work and became the language of science, teaching and automation. The purpose was programming without ceremony — the reach was the consequence.
What the platform does for a Python project
Almost all of it works with no configuration.
requirements.txt at build
Dependencies are installed when the image is built, not on every boot. The container starts with everything ready, and an install failure shows up in the build log instead of becoming a crash in production.
Three versions, one config line
3.13, 3.12 and 3.11 available. Switching means changing VERSION in vertracloud.config and deploying again — there is no image to pick and no Dockerfile to maintain.
Auto-restart with a brake
A process that crashes is restarted on its own, on every plan: a traceback does not take the service down. If it breaks 5 times in 10 minutes, auto-restart is disabled for 24 hours, instead of restarting forever and burning your memory.
Live logs and metrics
stdout and stderr show up in the dashboard terminal as they happen, with the container's CPU, RAM and storage right beside them. The last traceback before a crash is kept.
What people run in Python here
From the script that runs on its own to the API that takes traffic: the same application covers both roles.
Bots with discord.py and aiogram
discord.py, hikari, aiogram and python-telegram-bot run as a background process, with no HTTP port. The token goes in the environment variables in the dashboard, never in a .env inside the zip.
FastAPI and Flask APIs
Publish the application to get a subdomain on vertraweb.app with TLS. For Flask and Django, use Gunicorn bound to 0.0.0.0:80 — the development server does not accept external traffic.
Scrapers and queue workers
A scheduled collector, a queue consumer, an ETL routine: long-running processes that just need to stay up. Auto-restart covers the occasional network drop without anyone stepping in.
Data and queue in a managed database
A PostgreSQL 17 created in the dashboard serves psycopg, SQLAlchemy or asyncpg over the internal host, and a Redis 7 works as the Celery broker. TLS is mandatory, and the client certificate is downloaded in the dashboard.
Python versions available
3.13 is both recommended and latest; 3.12 and 3.11 stay available for anyone tied to a package that has not caught up. Declare VERSION in vertracloud.config.
| Version | vertracloud.config | Status |
|---|---|---|
| 3.13 | VERSION=3.13 | RecommendedLatest |
| 3.12 | VERSION=3.12 | |
| 3.11 | VERSION=3.11 |
The whole configuration
vertracloud.config is an optional INI file at the root of the project. MAIN points to the entry file; VERSION picks the Python; MEMORY sets the container's RAM ceiling.
NAME=meu-bot
MAIN=main.py
VERSION=3.13
MEMORY=512A plan for every stage of the project
Memory and storage change with the plan; the language does not. Compare what each plan unlocks and pick the one that fits the project today.
Compare plansAlso runs here
Same platform, same deploy, a different stack.
Frequently asked questions about Python hosting
Dependencies, version and the development server: the three most common questions.
Which Python versions can I use?
3.13 (recommended), 3.12 and 3.11. The choice is made with the VERSION key in vertracloud.config; without it, the application starts on the recommended one.
How are dependencies installed?
From requirements.txt at the root of the project, during the build. Generate the file with pip freeze > requirements.txt. If a package is not there, the deploy goes up and the application breaks with ModuleNotFoundError on the first import.
My Flask or Django application does not open in the browser. Why?
The development server listens on 127.0.0.1 and gets no external traffic. Use Gunicorn: gunicorn app:app --bind 0.0.0.0:80. The application also has to be published to have a subdomain.
Is my project's .env read?
No. The platform does not load a .env file: variables are registered in the environment variables tab in the dashboard and injected into the container. That is what keeps secrets out of the zip.
Do I need to send the venv in the zip?
No — and don't. Leave venv, .venv, __pycache__ and .cache out of the package: they inflate the upload and are rebuilt at build time. The environment is assembled on the server, for Linux.
Ship your Python project today
Create an account, upload a zip with requirements.txt or connect your GitHub repository, and follow the package installation in the dashboard terminal.
Create account