Python-приложение — это не PHP-скрипт, и хостинг ему нужен другой. PHP работает по модели shared-nothing: каждый запрос обрабатывается изолированно и состояние приложения между запросами не сохраняется, при этом сами процессы-воркеры PHP-FPM живут долго и обслуживают запрос за запросом из общего пула — поэтому такие сайты сотнями селят на один обычный виртуальный хостинг. Django, Flask или FastAPI устроены иначе: приложение обычно держат в постоянном процессе (воркеры gunicorn или uvicorn), который загружает код в память, слушает порт и сам отдаёт ответы. Из-за этой разницы вопрос «где разместить Python-приложение» почти всегда упирается в одно — даёт ли площадка держать постоянный процесс и ставить свой стек.
Ниже разберём, что именно требуется Python-вебу от хостинга (нужная версия интерпретатора, venv, WSGI/ASGI-сервер, nginx, systemd, SSH), чем shared отличается от VPS и облака, почему под «правильный» Python чаще берут виртуальный сервер и как выбрать площадку по шагам. Timeweb возьмём как наглядный пример: у него есть и shared с поддержкой Python, и VDS под полный стек.
Коротко
- Python-веб обычно держат в постоянном процессе с воркерами gunicorn или uvicorn: приложение загружено в память, ему нужны always-on и авто-рестарт после сбоя — в отличие от shared-nothing модели PHP, где состояние между запросами не сохраняется (хотя сами воркеры PHP-FPM долгоживущие).
- Минимальный набор — нужная версия Python, venv для изоляции, pip и requirements.txt для зависимостей, SSH для деплоя.
- Django и Flask реально запустить и на shared с mod_wsgi по WSGI (Django поддерживает и ASGI, но на WSGI-only shared используют именно WSGI-режим); FastAPI работает только по ASGI, поэтому на классическом shared обычно нельзя — под него нужен VPS или облако.
- Обычный shared спроектирован под эфемерную модель PHP и часто убивает долгоживущие процессы или лимитирует время выполнения — отсюда и упор на VPS.
- VPS/VDS даёт root: сами ставите Python, nginx, gunicorn/uvicorn, PostgreSQL, Celery и systemd — полная свобода версий и стека.
- Timeweb как пример: shared с Python (версии 2.7, 3.6, 3.10, WSGI-фреймворки) от 180 ₽/мес при оплате за 3 года; VDS под полный стек — от 693 ₽/мес.
- Serverless (например, Yandex Cloud Functions) — вариант для webhook и нестабильной нагрузки, но холодные старты и лимиты времени выполнения не годятся для «всегда живого» процесса.
Что нужно Python-приложению от хостинга
Прежде чем выбирать тариф, полезно понять, из чего складывается запуск Python-веба в продакшене. Набор требований почти одинаков для Django, Flask и FastAPI и как раз объясняет, почему «просто хостинг под сайты» тут часто мимо.
Нужная версия Python и изолированное окружение
Первое — конкретная версия интерпретатора. Приложение писалось под определённый Python, и площадка должна давать его поставить или выбрать. Второе — изолированное окружение. Стандартный модуль venv создаёт лёгкую виртуальную среду с собственной копией интерпретатора и библиотек: в ней доступны только те пакеты, которые вы явно установили, а системный Python остаётся нетронутым. Это защищает от конфликтов версий между проектами на одной машине.
Зависимости ставятся через pip и фиксируются в файле. Рабочий цикл простой: активируете окружение, ставите пакеты командой pip install -r requirements.txt, а перед деплоем фиксируете точные версии командой pip freeze > requirements.txt. Благодаря этому на сервере поднимется ровно то же окружение, что и локально. Значит, площадке нужны SSH-доступ и возможность самому управлять окружением — без консоли всё это не собрать.
Сервер приложения: gunicorn или uvicorn
Встроенный сервер разработки (тот самый runserver у Django или python app.py) для продакшена не предназначен. В бою перед приложением ставят WSGI- или ASGI-сервер. Django и Flask обычно запускают по WSGI, чаще всего через Gunicorn — это чистый Python-WSGI-сервер под UNIX без внешних зависимостей, ставится обычным pip, а запуск Django-приложения выглядит как gunicorn myproject.wsgi (по умолчанию — один процесс и один поток на 127.0.0.1:8000). При этом «Django — это только WSGI» уже неверно: Django из коробки поддерживает ASGI и async-вьюхи (тогда вместо wsgi берут asgi-точку входа и ASGI-сервер). А вот полноценные WebSocket обычно подключают не «из коробки», а через Django Channels или другой ASGI-компонент — сам ASGI-режим Django этого ещё не даёт.
Для ASGI-приложений (FastAPI, а также Django в асинхронном режиме) нужен ASGI-сервер, например Uvicorn. Чтобы задействовать несколько ядер и держать больше запросов, поднимают несколько worker-процессов — uvicorn main:app --workers 4 или fastapi run --workers 4 main.py; при этом Gunicorn нередко выступает менеджером процессов для Uvicorn-воркеров. Ориентир по числу воркеров: для синхронных (WSGI) — примерно (2 × CPU) + 1, для асинхронных (Uvicorn) — примерно по числу ядер. Отсюда и практическое требование к железу: чем больше ядер, тем больше параллельных воркеров вы поднимете.
Долгоживущий процесс, nginx и фоновые задачи
Ключевая деталь: Python-приложение обычно держат в постоянном процессе (persistent, always-on) с воркерами, а не пересоздают состояние приложения под каждый запрос, как в shared-nothing модели PHP. В продакшене его держат под systemd — это даёт автозапуск при перезагрузке сервера и авто-рестарт после падения, а само приложение биндят на Unix-socket. Плюс Gunicorn обязан работать за прокси-сервером: nginx буферизует медленных клиентов, без чего Gunicorn легко уложить простой атакой на отказ в обслуживании. Отсюда классическая связка nginx (reverse-proxy) → gunicorn → приложение.
Из всего этого вытекает список того, что должна позволять площадка: SSH-доступ (для деплоя, venv и systemd), нужная версия интерпретатора, свой веб-сервер (nginx), возможность держать фоновые процессы (например, воркеры Celery) и отдельная база данных (PostgreSQL и подобные). Если приложение — это Telegram-бот или другой постоянно слушающий сервис, требования те же; отдельный разбор есть в материале про хостинг для Telegram-бота.
Почему обычный shared-хостинг часто не подходит
Классический виртуальный (shared) хостинг проектировался под shared-nothing модель PHP, где состояние приложения не сохраняется между запросами, а обработка отдельного запроса короткоживущая. Поэтому такие площадки нередко убивают долгоживущие пользовательские процессы или ограничивают время выполнения — а постоянному WSGI/ASGI-процессу тогда просто негде жить. Если на shared нет mod_wsgi, для Python остаётся только медленный CGI, что для нагруженного веба уже не вариант.
Это не значит, что Python на shared невозможен в принципе. WSGI-приложение (Django, Flask) вполне поднимается на shared с mod_wsgi — с оговорками про долгоживущие процессы и фоновые задачи. А вот ASGI-приложение (FastAPI) на классическом shared обычно не запустить: там поддерживается только WSGI. То же касается идеи разместить проект на бесплатном хостинге — под учебный WSGI-скрипт этого хватит, но постоянный процесс, свой nginx и systemd там держать негде.
Варианты размещения: shared, VPS, облако, PaaS и serverless
Свести выбор можно к пяти типам площадок. Ниже — короткая карта с их сильными и слабыми сторонами именно под Python-веб.
| Тип | Кому подходит | Ограничения |
|---|---|---|
| Shared с поддержкой Python | Быстрый старт Django/Flask, панель управления, минимум настройки | Только WSGI, лимиты на процессы и время выполнения, FastAPI обычно нельзя |
| VPS/VDS (виртуальный сервер) | «Правильный» продакшен Django/Flask/FastAPI, свой стек и версии | Нужны навыки администрирования: сами настраиваете nginx, systemd, БД |
| Облачный сервер | Тот же root, но с масштабированием, снапшотами и API | Цена выше shared, ответственность за настройку остаётся на вас |
| PaaS (Render, Railway и подобные) | Django/Flask/FastAPI без администрирования сервера: платформа сама держит постоянный web-процесс через gunicorn/uvicorn | Меньше контроля, чем на VPS; на бесплатных планах процесс может «засыпать», постоянный always-on — на платных планах |
| Serverless / Functions (Yandex Cloud Functions и подобные) | API, webhook, событийная и «рваная» нагрузка | Возможны холодные старты и лимиты времени выполнения, не для «всегда живого» процесса |
Здесь важно не путать два разных класса площадок. PaaS-платформы (например, Render или Railway) запускают Python-приложение как постоянный web-сервис через тот же gunicorn или uvicorn: процесс держится всегда, и на платных планах холодных стартов нет — по сути это управляемый постоянный процесс без ручного администрирования сервера (на бесплатных планах процесс может «засыпать» в простое). А вот serverless и функции — это другое. Yandex Cloud Functions поддерживает Python-рантаймы (сейчас — Python 3.12 и 3.14), а зависимости, включая SDK Yandex Cloud, подтягиваются через тот же requirements.txt (pip выполняется при создании версии функции). Старые рантаймы Python 3.7 и 3.8 больше не поддерживаются. Это удобно для обработчиков webhook и редких вызовов, но у модели есть минусы — холодные старты и лимиты времени выполнения. Для приложения, которое должно быть постоянно живым, serverless — не замена серверу, тогда как PaaS как раз держит процесс постоянно.
Почему для Python-веба чаще берут VPS
Когда речь про полноценный сайт или API на Django, Flask или FastAPI, ответ обычно сводится к виртуальному серверу. VPS/VDS даёт root-доступ, а значит — полную свободу: сами ставите нужную версию Python, nginx, gunicorn или uvicorn, PostgreSQL, Redis, Celery и настраиваете systemd под свои сервисы. Это ровно тот набор, который требуют официальные deploy-инструкции Django, FastAPI и Gunicorn, и именно поэтому VPS называют «правильным» способом.
Плата за свободу — администрирование: обновления, безопасность и мониторинг ложатся на вас. Если это первый серверный опыт, стоит заранее прикинуть бюджет и запас по ресурсам; общая логика подбора разобрана в материале про аренду виртуального сервера, а сравнить площадки по совокупности условий помогает рейтинг хостингов России.
Timeweb как пример: shared с Python и VDS/облако
Чтобы не рассуждать абстрактно, посмотрим на одну площадку, где есть оба варианта. У Timeweb есть и виртуальный хостинг с поддержкой Python, и VDS/облачные серверы под полный стек — на них удобно показать разницу.
На виртуальном хостинге Timeweb доступны версии Python 2.7, 3.6 и 3.10 (версия выбирается в панели управления), а взаимодействие идёт через модуль WSGI для Apache. Поддерживаются WSGI-фреймворки — Django, Flask, Bottle, Pyramid. Важный нюанс: раз это WSGI-only, ASGI-приложение (FastAPI) на таком shared не запустить — под него понадобится VPS или облако. SSH-доступ есть на всех тарифах (или веб-консоль в панели), доступны virtualenv и pip; настройка сводится к выбору версии Python и указанию пути к файлу зависимостей. Тарифы shared (цена за месяц при оплате за 3 года): Базовый — 180 ₽ (15 ГБ, 2 сайта), Optimo — 272 ₽ (40 ГБ, 15 сайтов), Century — 381 ₽ (50 ГБ, 35 сайтов), Millennium — 554 ₽ (60 ГБ, 60 сайтов). Есть тест 10 дней и поддержка 24/7.
Если же нужен FastAPI, долгоживущие воркеры, Celery или свой стек целиком, смотрят VDS/облачные серверы Timeweb. Кастомная сборка — от 693 ₽/мес; готовые: Cloud MSK 40 — 882 ₽/мес (2×3.3 ГГц, 2 ГБ RAM, 40 ГБ NVMe), Cloud MSK 50 — 1062 ₽/мес (4 ГБ), Cloud MSK 80 — 1782 ₽/мес (4 CPU, 8 ГБ, 80 ГБ). Канал 1000 Мбит/с, публичный IP, полный root-доступ. ОС на выбор — Ubuntu, Debian, CentOS, AlmaLinux, Arch, Astra Linux CE, Windows; есть cloud-init, API/Terraform, бесплатные снапшоты и авто-бэкапы (6 ₽/ГБ). Заявлены SLA 99.98%, дата-центры уровня TIER III (РФ, Казахстан, Европа), соответствие 152-ФЗ и включённая DDoS-защита L3/L4 (L7 — опционально). Поддержка 24/7, ответ по тикету в пределах примерно 20 минут, перенос с другого хостинга бесплатный. Детальный разбор площадки — в отдельном обзоре Timeweb. Вывод по примеру простой: под Django или Flask можно стартовать и на shared (быстрый вход, панель, тест), а под FastAPI, фоновые воркеры и собственный стек берут VDS — от 693 ₽/мес.
Как выбрать хостинг для Python: по шагам
- Определите фреймворк. Django и Flask можно запустить по WSGI (Django умеет и ASGI, но на shared используют WSGI-режим), теоретически возможен shared; FastAPI работает только по ASGI, поэтому нужен VPS, облако или PaaS.
- Проверьте версию Python. Убедитесь, что площадка даёт нужную версию интерпретатора (на shared — из фиксированного списка, на VPS — любую).
- Оцените характер нагрузки. Постоянно работающий сайт или бот — это VPS; редкие вызовы и webhook — можно смотреть в сторону serverless.
- Проверьте наличие SSH, venv и pip. Без консоли вы не соберёте окружение и не настроите деплой.
- Заложите фоновые процессы и БД. Нужны ли Celery-воркеры, PostgreSQL, Redis — на shared это чаще всего невозможно, на VPS вы ставите их сами.
- Считайте запас, а не минимум. Один-два сайта — стартового shared хватает; свой стек и рост нагрузки — берите VDS с запасом по CPU и RAM.
- Возьмите тест. Прогоните приложение на пробном периоде и только потом оплачивайте вперёд длинный срок.
Честно про ссылку
Ссылка на Timeweb — реферальная: вы регистрируетесь на тех же условиях, а мы получаем небольшое вознаграждение. На цену и тарифы для вас это никак не влияет. Timeweb взят как удобный пример площадки, где под одним аккаунтом есть и shared с поддержкой Python, и VDS под полный стек; это не «единственно верный» выбор, и минусы мы называем прямо — ниже.
О чём предупреждают отзывы
- Стабильность shared: в отзывах жалуются на «502 bad gateway по несколько раз в день» (13% жалоб), на то, что «сайты периодически не работают» (23%), и на необъяснимые тормоза (11%).
- Техподдержка: часть пользователей называет ответы шаблонными, «как от бота»; «медленная техподдержка» встречается в 12% жалоб, а на саппорт в целом приходится до 43% негатива.
- Навязывание тарифов: при росте нагрузки на CPU, по отзывам, могут заблокировать сайт и предлагать более дорогой тариф; встречаются жалобы на блокировку до покупки DDoS-защиты.
- Деградация shared за последние примерно полтора года: по агрегированным отзывам, падения «3–4 раза в неделю» даже на дорогих тарифах.
- Timeweb Cloud (а это как раз VDS/облако, которое рекомендуют под Python) тоже получает жёсткий негатив по стабильности, цене и коммуникации; отдельно упоминают периодические сбои почты (около 5%).
- Это отзывы, а не техфакты: усреднённые оценки — ориентир, а не гарантия для вашего проекта. Проверяйте площадку тестом под свою нагрузку.
Практический вывод для 2026 года
Отталкивайтесь от фреймворка и характера нагрузки. Django или Flask с небольшим трафиком — можно стартовать на shared с поддержкой Python и mod_wsgi (быстро, из панели, дёшево). Как только появляется FastAPI, фоновые воркеры Celery, свой nginx, PostgreSQL и требование «всегда живого» процесса с авто-рестартом — это VPS/VDS с root и systemd. Не хотите администрировать сервер сами — посмотрите PaaS (Render, Railway): платформа держит постоянный процесс через gunicorn/uvicorn, на платных планах без холодных стартов. Serverless держите в уме для webhook и рваной нагрузки, но не как замену постоянному серверу. И перед длинной предоплатой всегда прогоняйте приложение на тесте.
Частые вопросы
Можно ли запустить Django или Flask на обычном (shared) хостинге или обязательно нужен VPS?
WSGI-приложение (Django, Flask) можно поднять и на shared с mod_wsgi — например, на виртуальном хостинге Timeweb поддерживаются Django, Flask, Bottle и Pyramid. Но с оговорками: shared проектировался под эфемерную PHP-модель и часто ограничивает долгоживущие процессы и время выполнения. Если нужны фоновые воркеры, свой nginx и «всегда живой» процесс, берут VPS.
Почему для FastAPI не подходит shared-хостинг и нужен VPS?
FastAPI — это ASGI-фреймворк, а классический shared (в том числе виртуальный хостинг Timeweb) поддерживает только WSGI-фреймворки через модуль WSGI для Apache. ASGI-приложению нужен свой ASGI-сервер (Uvicorn) и долгоживущий процесс, которого на shared обычно негде держать. Поэтому под FastAPI берут VPS или облако с root-доступом.
Какая версия Python нужна и как правильно ставить зависимости?
Нужна конкретная версия интерпретатора, под которую писалось приложение (на shared Timeweb это, например, 2.7, 3.6 или 3.10, на VPS — любая). Для изоляции используют модуль venv: он создаёт отдельное окружение с собственной копией Python и библиотек. Зависимости ставят командой pip install -r requirements.txt, а фиксируют перед деплоем через pip freeze > requirements.txt.
Зачем нужны gunicorn/uvicorn и nginx — нельзя ли просто запустить python app.py или runserver?
Встроенный сервер разработки (runserver, python app.py) не предназначен для продакшена. В бою ставят WSGI-сервер (Gunicorn для Django/Flask) или ASGI-сервер (Uvicorn для FastAPI). При этом Gunicorn обязан работать за прокси-сервером nginx: он буферизует медленных клиентов, без чего Gunicorn легко уложить атакой на отказ в обслуживании. Отсюда связка nginx → gunicorn → приложение.
Как сделать, чтобы приложение работало постоянно и само перезапускалось после сбоя?
Python-серверу нужен долгоживущий процесс, а не запуск на каждый запрос. В продакшене его держат под systemd: это даёт автозапуск при перезагрузке сервера и авто-рестарт после падения, а приложение биндят на Unix-socket за nginx. Такой контроль над сервисами есть на VPS/VDS с root-доступом; на обычном shared постоянный процесс держать негде.
