Хостинг для Python 2026: Django, FastAPI и Telegram-бот на shared, VPS или PaaS

Запрос «хостинг для Python» прячет три разные задачи: сайт на Django или Flask, API на FastAPI и Telegram-бот. Общее у них одно: это процесс, который должен работать постоянно, а не PHP-скрипт, который хостинг запускает на каждый запрос. Поэтому обычный shared на cPanel, рассчитанный на сайты, подходит редко, а VPS и PaaS почти всегда. Ниже: что нужно приложению, три пути, запуск бота, цены с официальных страниц и чек-лист перед оплатой. Подходящие серверы собраны в категории хостинг для Python, VPS отдельно сравнены в рейтинге VPS.

О методе. 10 октября 2026 года мы открыли страницы цен Railway, DigitalOcean и Friendhosting и переписали тарифы так, как они там показаны. Страницы Fornex и Vultr отдали нам ошибку 403. Для Vultr мы взяли ставки из его публичного API тарифов, для Fornex цену не приводим: смотрите её на сайте.

Что нужно Python-приложению от хостинга

PHP-сайт хостинг запускает сам: Apache или PHP-FPM вызывает скрипт на каждый запрос. С Python иначе. Фреймворк не принимает соединения из интернета, поэтому между ним и браузером нужен сервер приложений. Документация Django прямо предупреждает: команда runserver — лёгкий сервер для разработки, для продакшна она не годится.

Интерфейсов между веб-сервером и Python два. WSGI — основной стандарт для синхронного кода, на нём классически работают Django и Flask. ASGI — асинхронный, его использует FastAPI и асинхронная часть Django. Отсюда и стек: WSGI-приложение запускают через Gunicorn, ASGI — через Uvicorn (отдельно или воркером под Gunicorn). Сам Gunicorn документация советует держать за прокси и называет Nginx: с синхронными воркерами прокси должен буферизовать медленных клиентов, иначе сервер уязвим для DoS.

Число воркеров влияет на выбор тарифа. Gunicorn предлагает стартовую формулу (2 × ядра) + 1 и отмечает, что даже под большую нагрузку обычно хватает 4–12 воркеров. В FastAPI то же делает флаг: fastapi run --workers 4. Но каждый воркер — отдельный процесс со своей копией приложения в памяти. Три воркера на одноядерном VPS с 1 ГиБ вместе с PostgreSQL могут упереться в память, поэтому начинайте с двух и смотрите free -m под нагрузкой.

Как опознать OOM в журнале ядра и чем его лечить, разобрано в статье про OOM killer в Linux. Минимум, который должен дать хостинг:

• SSH и право ставить пакеты: pip, venv (или poetry, uv) и системные библиотеки, нужные для сборки колёс.
• Процесс, который живёт постоянно и переживает выход из SSH и перезагрузку сервера: systemd-юнит, supervisor или менеджер платформы.
• Reverse proxy и HTTPS: Nginx с сертификатом на VPS, готовый домен с TLS на PaaS.
• База: SQLite для небольшого проекта, PostgreSQL для остальных.

Три пути: shared с Python, VPS и PaaS

Shared с Python: работает, но с оговорками

В cPanel есть приложение «Setup Python App». Оно появляется там, где хостер поставил CloudLinux и Python Selector: WSGI-приложения отдаёт Apache через модуль Passenger. Для маленького Flask или Django-сайта это самый простой старт: выбираете версию Python, папку приложения и адрес, а Gunicorn и systemd не нужны. Это описание по документации CloudLinux и cPanel, а не по нашим замерам.

Оговорок три. Функция есть не у каждого хостера, и на shared её часто включают только после обращения в поддержку. Passenger говорит на WSGI, поэтому асинхронный FastAPI приходится оборачивать в адаптер, и преимущество ASGI пропадает. И главное: на shared обычно не разрешают долгие фоновые процессы, так что бот на long polling или воркер Celery там не живут. В нашем каталоге ни одна карточка shared-хостера прямо не заявляет поддержку Python, поэтому мы не называем «shared с Python» поимённо. Спросите поддержку о трёх вещах: есть ли Python Selector, какая версия Python и что с фоновыми процессами.

Есть и специализированные сервисы вроде PythonAnywhere. По его странице цен (октябрь 2026) бесплатный тариф Beginner даёт одно веб-приложение, лимит 100 CPU-секунд, без always-on tasks и с выходом в интернет только на список разрешённых сайтов (api.telegram.org в нём есть). Платный Developer стоит $10 в месяц, с одним always-on task и без ограничений на исходящие запросы. Для хобби-бота на webhook хватает.

VPS: полный контроль и фиксированная цена

VPS — это Linux-сервер, на котором всё ставите вы: нужную версию Python, Nginx, systemd-юнит, PostgreSQL на той же машине. Так работает большинство продакшн-проектов на Python. Минус очевиден: обновления, безопасность и бэкапы на вас. Зато счёт фиксированный, а ограничений на процессы нет.

Старт по страницам провайдеров. DigitalOcean: Basic Droplet $4 за 512 МиБ и 1 vCPU, $6 за 1 ГиБ и 25 ГиБ диска, $12 за 2 ГиБ; тарификация посекундная с месячным потолком. Vultr: $5 за 1 vCPU, 1 ГБ RAM и 25 ГБ, $10 за 2 ГБ, $20 за 2 vCPU и 4 ГБ. Friendhosting: €4,99 за 1 vCPU, 1 ГБ и 10 ГБ NVMe, €9,49 за 2 vCPU, 2 ГБ и 20 ГБ NVMe. У Fornex тариф мы не приводим, зато в каталоге у него 7 дней теста и 30 дней на возврат денег: можно проверить сервер под своим приложением. Что ещё смотреть в конфигурации, разобрано в статье про выбор конфигурации VPS.

PaaS: деплой из Git без администрирования

В PaaS вы подключаете репозиторий, платформа собирает приложение и запускает его. Railway для Python сама подбирает команду запуска: по документации Railpack, для Django она ищет manage.py и стартует Gunicorn, для FastAPI — Uvicorn. Если определение не сработало, команду вписываете в настройках сервиса. Платформа работает с PostgreSQL, MySQL и Redis и с фоновыми процессами. Другие платформы этого типа собраны в категории PaaS.

Оплата идёт по потреблению. Railway Hobby стоит $5 в месяц и включает $5 потребления, дальше вы платите за ресурсы: по ставкам на странице это примерно $20 за vCPU и $10 за ГБ RAM в месяц плюс $0.05 за ГБ исходящего трафика. Наш расчёт по этим ставкам: бот, который держит 256 МБ, даёт около $2.5 за память и копейки за CPU, то есть укладывается во включённые $5. Сервис, который постоянно держит 1 ГБ, обойдётся примерно в $10 только за RAM, дороже Droplet за $6 с тем же гигабайтом. DigitalOcean App Platform проще: контейнер на 1 vCPU и 512 МиБ стоит $5 в месяц, бесплатных динамических приложений нет, а воркер тарифицируется как обычный контейнер.

Python-хостинг с серверами в Европе

Европейский регион даёт более короткий отклик для аудитории из ЕС и Украины. Боту расположение почти не важно: он ходит к серверам Telegram, а не к пользователю. Для сайта и API разница измеряется десятками миллисекунд. Европейские площадки у таких хостов из нашего каталога:

Если вам нужен просто самый дешёвый европейский сервер, цены разных провайдеров сведены в статье про самый дешёвый VPS в Европе, а о том, как выбрать страну размещения, — в гайде по VPS в Европе.

Хостинг для Telegram-бота на Python: webhook или long polling

Telegram даёт боту два способа получать обновления, и они взаимоисключающие: пока задан webhook, метод getUpdates не работает. От выбора зависит, какой хостинг вам нужен.

Практический вывод для хостинга простой. Long polling требует процесса, который живёт постоянно, поэтому идёт на VPS, PaaS или платный always-on task. Webhook — обычный HTTP-обработчик, именно он позволяет держать бота на shared с Python. Для production задайте secret_token: Telegram добавляет его в заголовок X-Telegram-Bot-Api-Secret-Token к каждому запросу, и вы отсекаете чужие вызовы. Параметр max_connections (от 1 до 100, по умолчанию 40) ограничивает параллельные запросы, на маленьком VPS его стоит снизить. Отвечайте 200 сразу, а тяжёлую работу отдавайте в очередь.

База данных и фоновые задачи: PostgreSQL, Celery, Redis

SQLite хватает боту с десятком пользователей, но она допускает одного пишущего за раз. Как только появляются несколько воркеров или Celery, берите PostgreSQL. На VPS он делит память с приложением, так что обычно это разница между тарифом на 1 ГиБ и на 2 ГиБ. В PaaS база — отдельный сервис с оплатой по потреблению; DigitalOcean предлагает ещё и управляемые базы.

Для фоновых задач Celery поддерживает RabbitMQ, Redis и Amazon SQS как стабильные брокеры, а RQ работает только с Redis. О Redis и его форке Valkey мы писали отдельно: Valkey вместо Redis. На VPS воркер — ещё один systemd-юнит, на PaaS — отдельный сервис со своей командой запуска и своим счётом. Задачи раз в сутки часто обходятся cron без Celery вообще.

Что брать под ваш проект и сколько это стоит

Это ориентир, замеров здесь нет: реальную память приложения покажет free -m через сутки под настоящей нагрузкой. Граница между PaaS и VPS простая: пока сервис почти всё время простаивает, дешевле оплата по потреблению, а когда он стабильно держит гигабайт и ядро, выигрывает фиксированный VPS. Если нужна видеокарта, цены за час собраны в статье про аренду GPU.

Для бота или небольшого API я бы не искал «хостинг с Python» в разделе shared. Недорогой VPS или кредит PaaS стоит столько же, сколько час, который вы потратите на выяснение, почему хостер прибил ваш процесс.

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

Чек-лист перед оплатой

• Для shared: напишите в поддержку и спросите, есть ли Python Selector (Application Manager), какая версия Python, разрешены ли фоновые процессы и какой лимит памяти.
• Для VPS: проверьте, есть ли root, можно ли поставить нужную версию Python и сколько RAM на старте. Меньше 1 ГиБ под Django с базой не берите.
• Отключите DEBUG, задайте ALLOWED_HOSTS и SECRET_KEY через переменные окружения, запустите manage.py check --deploy.
• Поставьте Gunicorn или Uvicorn под systemd и Nginx впереди; сертификат получите через certbot.
• Включите бэкапы базы и снимки диска до первого релиза, а не после первой потери данных.
• Воспользуйтесь тестовым периодом или возвратом денег: в каталоге это 7 дней теста и 30 дней на возврат у Fornex, 30 дней теста у Zomro.

Итог

Коротко: для Django-сайта или API в продакшне берите VPS от 1–2 ГиБ, для прототипа и быстрого деплоя из Git — PaaS вроде Railway. Бота на webhook можно держать и на shared с Python, если поддержка подтвердила Python Selector и отсутствие жёстких лимитов. Для европейской аудитории смотрите площадки с Нидерландами или Германией: Fornex, Friendhosting, DigitalOcean. Полный список с отзывами и тестовым периодом — в категории хостинг для Python.