Хостинг для python скриптов: где держать парсеры и боты

Хостинг для python скриптов — это почти всегда VPS, то есть виртуальный сервер с полным доступом к консоли, где вы сами ставите нужную версию интерпретатора и запускаете процессы, которые живут круглосуточно. Парсер, планировщик рассылок, бот и любой фоновый воркер требуют трёх вещей, которых нет на обычном виртуальном хостинге: права запускать долгоживущие процессы, собственного расписания и доступа по SSH. Подходящие тарифы собраны в разделе VPS для Python — там видно и цены, и объём памяти у каждого провайдера.

Материал для тех, кто написал скрипт на ноутбуке и хочет перенести его на сервер, чтобы он работал без включённого компьютера. Разберём, почему шаред-хостинг тут не помогает, сколько стоит минимальная машина, как запустить скрипт по расписанию через cron и через systemd-таймер, чем эти два способа отличаются, зачем нужно виртуальное окружение venv и как настроить логи с уведомлениями о падениях.

Почему обычный шаред-хостинг не подходит для фоновых скриптов

Шаред-хостинг — это площадка, где сотни сайтов делят один физический сервер, а панель управления даёт вам только каталог с файлами и базу данных. Такая среда спроектирована под веб: пришёл HTTP-запрос, PHP отработал за секунду, процесс закрылся. Скрипт, который висит в памяти сутками и раз в минуту дёргает чужой сайт, в эту модель не укладывается.

Ограничений обычно три. Первое — лимит времени выполнения процесса, часто 30 или 60 секунд, после чего задачу убивают. Второе — запрет на постоянно работающие процессы. Третье — фиксированный набор библиотек: поставить свои зависимости из pip чаще всего нельзя.

Отдельная беда — сеть. На шареде сотни клиентов выходят наружу с одного IP, и если сосед злоупотребил запросами, блокировку получают все, включая ваш парсер. Есть тарифы с поддержкой интерпретатора, они собраны в подборке хостинг для Python-ботов, и для простого скрипта раз в сутки их иногда хватает. Но как только появляется постоянный процесс или свои зависимости, дешевле сразу взять VPS.

Что именно нужно парсеру, планировщику и боту от сервера

Требования у этих трёх типов задач разные, и переплачивать за универсальную конфигурацию не нужно. Парсер упирается в сеть: ему важны скорость канала и предсказуемый исходящий IP, потому что многие сайты ограничивают частоту обращений по адресу. Отсюда правило: для парсеров смотрим на канал и на то, выдаёт ли провайдер выделенный IP-адрес каждому серверу.

Планировщику — скрипту, который раз в час забирает данные из API и складывает в базу, — быстрый канал почти не нужен. Ему важен только аптайм: если машина упала в 3 часа ночи, задача просто не выполнилась, и вы узнаете об этом утром. Провайдеры заявляют аптайм 99,9 %, что означает до 43 минут простоя в месяц, и для планировщика это приемлемо.

Боту нужен постоянно живой процесс и немного памяти под соединение с API мессенджера. Библиотека aiogram с парой десятков обработчиков спокойно помещается в 512 МБ, но если бот скачивает файлы или рисует картинки, берите от 2 ГБ. Отдельные конфигурации под такие задачи есть в разделе VPS для Telegram-бота.

Сколько стоит VPS под Python-скрипты: цены на сентябрь 2026

Нижняя планка рынка держится в районе 59–150 ₽ в месяц за машину с 1 ГБ памяти. Этого хватает на два-три лёгких скрипта, которые вместе не съедают больше 300–400 МБ. Разница между дешёвыми и средними тарифами не столько в железе, сколько в качестве поддержки, стабильности и наличии резервных копий.

Данные проверены 02.09.2026.

Цена в 59 ₽ выглядит заманчиво, но у Cloudcore и HostVDS рейтинг по отзывам 3,3 из 5 — это уровень «работает, пока работает». Для учебного скрипта нормально, для бота, за которым следят клиенты, лучше добавить денег. У AdminVPS рейтинг 4,5, у Aéza 4,6, и разница в 300–500 ₽ в месяц окупается первым же ночным сбоем, которого не случилось.

Если бюджет жёсткий, сравните ещё десяток предложений в подборке недорогих VPS: там есть машины по 139–200 ₽ у RuVDS, Selectel и Timeweb. Учтите, что у самых дешёвых тарифов диск бывает 5–8 ГБ, и логи парсера способны забить его за пару месяцев.

Как подобрать конфигурацию под свой тип скрипта

Отталкивайтесь не от цены, а от того, что скрипт делает с данными. Если он держит в памяти список из миллиона строк, память важнее ядер. Если он ждёт ответа от чужого API — важнее сеть, а процессор простаивает на 95 % времени.

Таблица ниже — стартовые ориентиры. Берите на шаг выше, если планируете держать несколько скриптов одновременно.

Отдельно про диск. Само окружение с интерпретатором и десятком библиотек занимает 300–600 МБ, браузерный движок Playwright добавляет ещё около 1,5 ГБ. Значит, на тарифе с диском 10 ГБ у вас останется 7–8 ГБ под данные и логи — и это надо считать заранее, а не когда сервер встанет с ошибкой «нет места».

Пошаговый запуск: от чистого сервера до первого скрипта

Дальше — минимальный маршрут для Ubuntu 24.04. Он занимает 15–20 минут, если сервер уже создан и вы получили пароль root на почту. Подробности про первичную настройку — ключи, обновления, пользователь без прав администратора — разобраны в отдельном руководстве как настроить VPS с нуля.

1. Подключитесь по SSH: ssh root@ВАШ_IP. Порт по умолчанию 22.
2. Обновите пакеты и поставьте интерпретатор: apt update && apt install -y python3 python3-venv python3-pip git.
3. Создайте каталог проекта: mkdir -p /opt/parser — по традиции в /opt держат прикладной софт.
4. Залейте код через git clone или скопируйте файлы командой scp с локальной машины.
5. Соберите виртуальное окружение и поставьте зависимости (об этом ниже).
6. Запустите скрипт руками один раз и убедитесь, что он отработал без ошибок.
7. Только после успешного ручного запуска ставьте задачу на расписание.

Шестой пункт пропускают чаще всего, а он экономит часы. Cron не покажет вам ошибку на экране: он молча выполнит команду, получит код возврата 1 и забудет об этом. Проверять работоспособность надо до автоматизации, а не после.

Виртуальное окружение venv: зачем нужно и как его создать

Виртуальное окружение — это отдельная папка, куда складываются библиотеки конкретного проекта, чтобы они не смешивались с системными. Без него первая же команда pip install начнёт менять пакеты, от которых зависит сама операционная система. В Ubuntu 24.04 такая установка вообще заблокирована и выдаёт ошибку externally-managed-environment.

Второй аргумент — версии. Одному скрипту нужен requests 2.28, другому 2.32, и в общей системе они конфликтуют. С venv у каждого проекта своя копия, и обновление одного не ломает другой.

cd /opt/parser
python3 -m venv venv
source venv/bin/activate
pip install --upgrade pip
pip install requests beautifulsoup4
pip freeze > requirements.txt

Команда python3 -m venv venv создаёт папку venv с собственным интерпретатором. source venv/bin/activate включает окружение в текущей сессии — в приглашении командной строки появится префикс (venv). Файл requirements.txt фиксирует список версий, чтобы через полгода развернуть тот же набор одной командой pip install -r requirements.txt.

Главная тонкость: в cron и в systemd активировать окружение не нужно и не получится. Там указывают полный путь к интерпретатору внутри венва — /opt/parser/venv/bin/python. Этот путь сам подтягивает нужные библиотеки, никакого activate не требуется. Больше о специфике площадок под интерпретатор — в справке про хостинг с поддержкой Python.

Расписание через cron: синтаксис и рабочие команды

Cron — системный планировщик, который есть в любом дистрибутиве Linux и работает с 1975 года почти без изменений. Он читает таблицу заданий и запускает команды в указанное время. Своя таблица есть у каждого пользователя, открывается командой crontab -e.

Строка задания состоит из пяти полей времени и самой команды. Поля идут в порядке: минута (0–59), час (0–23), день месяца (1–31), месяц (1–12), день недели (0–7, где 0 и 7 — воскресенье). Звёздочка означает «любое значение», а запись */15 — «каждые 15 единиц».

crontab -e

# каждые 15 минут
*/15 * * * * /opt/parser/venv/bin/python /opt/parser/main.py >> /var/log/parser.log 2>&1

# каждый день в 04:30
30 4 * * * /opt/parser/venv/bin/python /opt/parser/daily.py >> /var/log/daily.log 2>&1

Хвост >> /var/log/parser.log 2>&1 перенаправляет обычный вывод и текст ошибок в один файл. Без него вывод уходит в системную почту, которой на свежем сервере нет, и диагностика превращается в гадание. Проверить, что задание записалось, можно командой crontab -l, а факты запусков видно в grep CRON /var/log/syslog.

Ловушка новичков — окружение. Cron запускает команду с почти пустым набором переменных: PATH урезан, домашний каталог может отличаться, текущая папка не та, где лежит скрипт. Поэтому в заданиях всегда пишут абсолютные пути и к интерпретатору, и к файлу, и к данным, которые скрипт открывает.

systemd-таймер: чем он отличается от cron и как его настроить

Systemd — это менеджер служб, который в современных дистрибутивах управляет запуском всего на сервере. Его таймеры делают то же, что cron, но состоят из двух файлов: сервис описывает, что запускать, а таймер — когда. Взамен вы получаете логи в едином журнале, контроль зависимостей и корректный перезапуск.

Ключевое отличие в поведении при простое. Если сервер был выключен в момент срабатывания, cron задачу просто пропустит, а systemd с параметром Persistent=true выполнит её сразу после загрузки. Второе отличие: systemd умеет перезапускать упавший процесс — для бота это принципиально, cron так не умеет вовсе.

sudo nano /etc/systemd/system/parser.service

[Unit]
Description=Parser job

[Service]
Type=oneshot
WorkingDirectory=/opt/parser
ExecStart=/opt/parser/venv/bin/python /opt/parser/main.py

sudo nano /etc/systemd/system/parser.timer

[Unit]
Description=Run parser every 15 minutes

[Timer]
OnCalendar=*:0/15
Persistent=true

[Install]
WantedBy=timers.target

sudo systemctl daemon-reload
sudo systemctl enable --now parser.timer
systemctl list-timers --all | grep parser
journalctl -u parser.service -n 50 --no-pager

Команда daemon-reload заставляет systemd перечитать новые файлы, enable --now включает таймер и в автозагрузку, и прямо сейчас. Список list-timers покажет, когда следующее срабатывание, а journalctl выведет последние 50 строк вывода задачи.

Что выбрать новичку: cron или systemd

Правило простое. Если задача выполняется и завершается — берите cron: одна строка, минута на настройку, работает везде. Если процесс должен жить постоянно и подниматься после падения — берите systemd-сервис, без вариантов.

Для постоянно работающего бота сервис описывают почти так же, но с Type=simple, строкой Restart=always и паузой RestartSec=5 — тогда после сбоя процесс поднимется через 5 секунд. Готовый разбор такого юнита с нуля есть в инструкции как развернуть Telegram-бота на VPS.

Логи: куда писать и как не забить диск

Логи — единственный способ понять, что происходило со скриптом ночью. Минимум, который стоит писать в каждой итерации: время старта, сколько объектов обработано, сколько ошибок, время работы в секундах. Встроенный модуль logging делает это в две строки настройки и умеет сразу дописывать в файл.

Опасность в том, что лог растёт. Парсер с 5 строками каждые 15 минут даёт за месяц около 15 тысяч строк — это мелочь. А скрипт с подробным выводом нагенерирует 100–300 МБ в неделю и забьёт диск в 10 ГБ за пару месяцев. Решение — ротация утилитой logrotate.

sudo nano /etc/logrotate.d/parser

/var/log/parser.log {
    daily
    rotate 7
    compress
    missingok
    notifempty
}

Такая настройка каждый день переименовывает лог, сжимает старую копию и хранит 7 архивов, то есть недельную историю. Проверить конфигурацию без ожидания суток можно командой sudo logrotate -d /etc/logrotate.d/parser — флаг -d показывает, что будет сделано, ничего не меняя. Свободное место контролируйте командой df -h, тревожный порог — заполнение выше 80 %.

Уведомления об ошибках: узнать о падении раньше пользователя

Скрипт, который упал молча, хуже скрипта, который не написан: вы уверены, что данные собираются, а их нет уже неделю. Самый дешёвый способ узнавать о сбоях — отправлять сообщение в мессенджер прямо из блока обработки исключений. Достаточно обернуть основную функцию в try/except и в ветке ошибки дёрнуть API бота с текстом исключения.

У systemd есть встроенный механизм: директива OnFailure= в секции [Unit] запускает указанный вспомогательный сервис, если основной завершился с ошибкой. В этом сервисе вызывают curl с текстом из журнала — и вы получаете уведомление в течение нескольких секунд после сбоя.

Второй уровень контроля — внешний. Скрипт после успешной итерации отправляет короткий запрос на сервис мониторинга, а тот присылает алерт, если сигнала не было дольше 30 минут. Так ловится случай, когда упал весь сервер и изнутри сообщить уже некому. Как собрать полноценную систему наблюдения, описано в гайде по настройке мониторинга сервера.

Частые ошибки при переносе скриптов на сервер

Большинство проблем повторяется от проекта к проекту и стоит не денег, а нервов и потерянных данных. Ниже те, что встречаются чаще всего у тех, кто переезжает с ноутбука на VPS впервые.

• Относительные пути в коде: локально файл открывался, в cron скрипт стартует из другого каталога и падает.
• Запуск системным python3 вместо venv/bin/python — библиотеки «пропадают», хотя pip их ставил.
• Токены и пароли прямо в коде, который лежит в публичном репозитории; выносите их в переменные окружения.
• Нет ограничения на частоту запросов в парсере: 100 обращений в секунду к чужому сайту заканчиваются баном IP.
• Задача каждую минуту, а отрабатывает 90 секунд — копии накладываются и съедают память.
• Нет резервных копий данных: диск сервера не бессмертен, настройте бэкапы по этой инструкции.

Частые вопросы

Можно ли обойтись бесплатным хостингом для Python-скрипта? Для учебной задачи, которая запускается раз в сутки и работает 10 секунд, бесплатные площадки годятся. Но там нет гарантий аптайма, процесс глушат по таймауту, а данные могут исчезнуть без предупреждения. Разница с самым дешёвым VPS — 59 ₽ в месяц, и она окупается спокойствием.

Сколько скриптов уместится на сервере с 1 ГБ памяти? Простой скрипт на requests занимает 40–80 МБ, бот на aiogram — 100–150 МБ. Оставьте системе 250–300 МБ, и получится 4–6 небольших задач одновременно. Как только начинается работа с pandas или браузером, счёт идёт на гигабайты, и нужен тариф от 2 ГБ.

Нужен ли выделенный IP для парсера? Желательно. На виртуальном сервере IP обычно и так свой, в отличие от шареда, где адрес общий на сотни клиентов. Собственный адрес означает, что репутация зависит только от вашего поведения: соблюдайте паузы между запросами, и блокировок не будет.

Что делать, если задание в cron не запускается? Проверьте три вещи по порядку: абсолютный путь к интерпретатору, права на исполнение у файла и наличие переноса строки в конце crontab. Затем посмотрите системный журнал командой grep CRON /var/log/syslog — там видно, была ли попытка запуска вообще.

Можно ли запускать скрипты на Windows-сервере? Да, интерпретатор работает и там, а роль планировщика играет «Планировщик заданий». Но лицензия поднимает цену на 200–400 ₽ в месяц, а для фоновых задач графический интерфейс не нужен. Для скриптов практичнее Linux.

Как обновлять код на сервере без простоя? Держите проект в git-репозитории: git pull в каталоге проекта занимает пару секунд, после чего сервис перезапускается командой sudo systemctl restart parser.service. Для задач по расписанию простоя вообще не будет — обновление успеет пройти между запусками.

Хватит ли одного ядра для Telegram-бота? Для бота с сотней-двумя пользователей — да, процессор там почти всегда простаивает, нагрузка сводится к ожиданию ответов от сети. Второе ядро нужно, если бот обрабатывает медиа, конвертирует файлы или обслуживает тысячи активных чатов.

Итог

Фоновые скрипты живут на VPS, а не на шареде: там есть свои процессы, свои библиотеки и своё расписание. Стартовать можно с машины за 59–150 ₽ в месяц с 1 ГБ памяти, а под бота с базой или парсер с браузером закладывать 2–4 ГБ и 299–593 ₽. Разовые задачи ставьте в cron, постоянно работающие — в systemd с автоперезапуском, и обязательно настройте логи с уведомлением о падении.

Готовые конфигурации с фильтром по памяти, диску и локации собраны в разделе VPS для Python-скриптов — сравните цены и выберите тариф под свою задачу.