Python hosting in 2026: Django, FastAPI and Telegram bots on shared, VPS or PaaS

"Python hosting" covers three different jobs: a Django or Flask site, a FastAPI backend and a Telegram bot. They share one trait. Each is a process that has to stay up, not a PHP script the host launches on every request. That is why plain cPanel shared hosting, built for websites, rarely fits, while a VPS or a PaaS almost always does. Below: what the app needs, the three routes, how to run a bot, prices and a checklist. Suitable servers are collected in our Python hosting category, and VPS plans are compared in the VPS ranking.

On 10 October 2026 we opened the pricing pages of Railway, DigitalOcean and Friendhosting and copied the plans as shown. The Fornex and Vultr pages returned a 403 error. For Vultr we took the rates from its public plans API; for Fornex we give no price, so check it on their site.

What a Python app needs from hosting

A host runs a PHP site for you: Apache or PHP-FPM calls the script on each request. Python works differently. The framework does not accept internet connections itself, so an application server has to sit between it and the browser. The Django documentation is blunt about it: runserver is a development server and is not suitable for production.

There are two interfaces between a web server and Python. WSGI is the standard for synchronous code, and Django and Flask traditionally run on it. ASGI is asynchronous and is what FastAPI and the async side of Django use. So a WSGI app runs under Gunicorn and an ASGI app under Uvicorn (alone or as a Gunicorn worker). The Gunicorn docs recommend Nginx in front: with synchronous workers the proxy must buffer slow clients, or the server is open to denial-of-service.

The worker count is part of choosing a plan. Gunicorn suggests (2 × cores) + 1 as a starting formula and notes that 4–12 workers usually handle even heavy traffic. FastAPI has a flag for it: fastapi run --workers 4. But each worker is a separate process with its own copy of the app in memory. Three workers on a single-core 1 GiB VPS plus PostgreSQL can run out of RAM, so start with two and watch free -m under load.

More on spotting an OOM kill is in our guide to the Linux OOM killer. The minimum a host should give you:

• SSH and the right to install packages: pip, a venv (or poetry, uv) and the system libraries needed to build wheels.
• A process that stays alive and survives an SSH logout and a server reboot: a systemd unit, supervisor or the platform's own manager.
• A reverse proxy and HTTPS: Nginx with a certificate on a VPS, a ready domain with TLS on a PaaS.
• A database: SQLite for a small project, PostgreSQL for the rest.

Three routes: shared with Python, VPS and PaaS

Shared with Python: it works, with caveats

cPanel has an app called "Setup Python App". It appears where the host has installed CloudLinux and Python Selector: WSGI apps are served by Apache through the Passenger module. For a small Flask or Django site it is the easiest start: you pick a Python version, an app folder and a URL, and you need neither Gunicorn nor systemd. This is the description from the CloudLinux and cPanel documentation, not from our own tests.

There are three caveats. Not every host has the feature, and on shared plans it is often switched on only after you ask support. Passenger speaks WSGI, so an async FastAPI app needs an adapter and loses the ASGI advantage. And shared plans usually forbid long-running background processes, so a long-polling bot or a Celery worker will not survive there. In our catalogue no shared-hosting card states Python support outright, so we do not name a "shared host with Python". Ask support whether Python Selector is available, which Python version it offers and what the rule is on background processes.

There are also Python-specific services such as PythonAnywhere. By its pricing page (October 2026) the free Beginner plan gives one web app, a 100 CPU-second limit, no always-on tasks and outbound access only to an allowlist of sites (api.telegram.org is on it). The paid Developer plan is $10 a month, with one always-on task and no outbound restrictions. For a hobby webhook bot that is enough.

VPS: full control and a fixed price

A VPS is a Linux server where you install everything yourself: the Python version you need, Nginx, a systemd unit, PostgreSQL on the same machine. Most production Python projects run this way. The downside: updates, security and backups are your job. The upside: a fixed bill and no limits on processes.

Entry plans from the provider pages. DigitalOcean: a Basic Droplet is $4 for 512 MiB and 1 vCPU, $6 for 1 GiB and 25 GiB of disk, $12 for 2 GiB; billing is per second with a monthly cap. Vultr: $5 for 1 vCPU, 1 GB of RAM and 25 GB, $10 for 2 GB, $20 for 2 vCPU and 4 GB. Friendhosting: €4.99 for 1 vCPU, 1 GB and 10 GB of NVMe, €9.49 for 2 vCPU, 2 GB and 20 GB. We give no Fornex tariff, but in our catalogue it has a 7-day trial and a 30-day money-back window, enough to test a server with your own app. For sizing, see our guide to VPS configuration.

PaaS: deploy from Git without administering anything

With a PaaS you connect a repository and the platform builds and runs the app. Railway picks the start command for Python itself: per the Railpack docs it starts Gunicorn when it finds manage.py and Uvicorn for FastAPI, and if detection fails you type the command into the service settings. It also runs PostgreSQL, MySQL, Redis and background processes. Other platforms of this kind are in our PaaS category.

You pay for usage. Railway Hobby is $5 a month and includes $5 of usage; beyond that you pay for resources, which by the rates on the page is about $20 per vCPU and $10 per GB of RAM a month, plus $0.05 per GB of outbound traffic. Our calculation at those rates: a bot holding 256 MB costs about $2.5 for memory and pennies for CPU, so it fits inside the included $5. A service that permanently holds 1 GB is about $10 for RAM alone, more than a $6 Droplet with the same gigabyte. On DigitalOcean App Platform a container with 1 vCPU and 512 MiB is $5 a month, dynamic apps have no free tier, and a worker is billed like any container.

Python hosting with servers in Europe

A European region gives lower latency for an audience in the EU and Ukraine. For a bot the location barely matters, since it talks to Telegram's servers, not to the user. For a site or an API the difference is tens of milliseconds. These hosts from our catalogue have European locations:

For the cheapest European server, see our piece on the cheapest VPS in Europe; how to pick the country is in the Europe VPS guide.

Hosting a Telegram bot in Python: webhook or long polling

Telegram gives a bot two ways to receive updates, and they are mutually exclusive: while a webhook is set, the getUpdates method does not work. Your choice decides which hosting you need.

For hosting, the conclusion is simple. Long polling needs a process that lives all the time, so it goes on a VPS, a PaaS or a paid always-on task. A webhook is an ordinary HTTP handler, which is what lets a bot live on shared hosting with Python. In production set a secret_token: Telegram sends it in the X-Telegram-Bot-Api-Secret-Token header, so you can drop foreign calls. The max_connections parameter (1 to 100, default 40) caps parallel requests; lower it on a small VPS. Answer 200 straight away and hand heavy work to a queue.

Database and background jobs: PostgreSQL, Celery, Redis

SQLite is fine for a bot with a dozen users, but it lets only one writer in at a time. Once there are several workers or Celery, take PostgreSQL. On a VPS it shares memory with the app, which is usually the difference between a 1 GiB and a 2 GiB plan. On a PaaS the database is a separate service billed by usage; DigitalOcean also offers managed databases.

For background jobs, Celery supports RabbitMQ, Redis and Amazon SQS as stable brokers, while RQ works only with Redis. We covered Redis and its fork in Valkey instead of Redis. On a VPS a worker is one more systemd unit; on a PaaS it is a separate service with its own start command and its own bill. A job that runs once a day often needs only cron.

What to take for your project, and what it costs

These are guide figures, not measurements: free -m after a day under real load shows what your app actually uses. The line between PaaS and VPS is simple. While a service sits idle most of the time, paying by usage is cheaper; once it steadily holds a gigabyte and a core, the fixed VPS bill wins. If you need a graphics card, hourly prices are in our piece on renting a GPU.

For a bot or a small API I would not look for Python hosting in the shared section. A cheap VPS or a PaaS credit costs about as much as the hour you will spend working out why the host killed your process.

Ігор Джазов, редактор Tophosting

Checklist before you pay

• For shared: ask support whether Python Selector (Application Manager) is available, which Python version, whether background processes are allowed and what the memory limit is.
• For a VPS: check for root, whether you can install the Python version you need, and how much RAM you start with. Do not take less than 1 GiB for Django with a database.
• Turn off DEBUG, set ALLOWED_HOSTS and SECRET_KEY through environment variables, and run manage.py check --deploy.
• Put Gunicorn or Uvicorn under systemd with Nginx in front, and get the certificate through certbot.
• Switch on database backups and disk snapshots before the first release, not after the first data loss.
• Use the trial or the money-back window: in our catalogue that is a 7-day trial and 30 days of money-back at Fornex, and a 30-day trial at Zomro.

Summary

In short: for a Django site or an API in production take a VPS with 1–2 GiB; for a prototype and a quick deploy from Git take a PaaS such as Railway. A webhook bot can even live on shared hosting with Python if support has confirmed Python Selector. For a European audience, look at hosts with the Netherlands or Germany: Fornex, Friendhosting, DigitalOcean. The full list with reviews and trial periods is in the Python hosting category.