VPS для Django в 2026: хостинг для Python-проектов

Небольшому проекту на Django хватает 1 vCPU и 1–2 ГБ памяти, рабочему — с PostgreSQL на том же сервере — 2 vCPU и 4 ГБ. У наших провайдеров это AdminVPS Micro за 899 ₽/мес при оплате за месяц (2 vCPU, 4 ГБ, 60 ГБ NVMe) или Timeweb Cloud MSK 40 за 1 000 ₽/мес при оплате за месяц (2 vCPU, 2 ГБ, 40 ГБ NVMe, с публичным IP).

Ниже — требования по размеру проекта, таблица трёх провайдеров, три сценария выбора (администратор в комплекте, почасовая оплата, стабильная нагрузка) и развёртывание по восьми шагам: Python 3.12, PostgreSQL, Gunicorn, Nginx, SSL и systemd.

Раскрытие информации: Этот сайт содержит партнёрские ссылки. При покупке через наши ссылки мы получаем комиссию без дополнительных затрат для вас.

Справочные материалы: Django, Python (Wikipedia).

Django — полноценный веб-фреймворк со своей экосистемой зависимостей, и его требования к инфраструктуре существенно отличаются от требований статических сайтов или простых PHP-приложений.

Python 3.12+. Начиная с Django 5.x, поддержка Python версий ниже 3.10 официально прекращена. На практике стоит ориентироваться на Python 3.12 или 3.13: разработчики CPython публикуют прирост производительности интерпретатора относительно 3.9; своих замеров мы не делали.

База данных. Django официально поддерживает PostgreSQL (рекомендуется), MySQL/MariaDB и SQLite (только для разработки). PostgreSQL 15+ обеспечивает лучшую работу с JSON-полями, оконными функциями и параллельными запросами.

Оперативная память. Каждый воркер Gunicorn потребляет от 50 до 150 МБ RAM в зависимости от объёма импортируемых библиотек. При запуске 4 воркеров + PostgreSQL + Redis минимально необходим 1 ГБ, комфортно — от 2 ГБ.

Процессор. Django хорошо масштабируется горизонтально, но для одного сервера важна тактовая частота ядер. Для средних проектов достаточно 2 vCPU.

SSD-хранилище. Тип диска критичен для скорости работы PostgreSQL и статических файлов. NVMe SSD быстрее SATA SSD на случайном чтении и записи — насколько именно, зависит от диска и нагрузки; своих замеров мы не проводим.

Малый проект (до 1 000 посетителей/сут.): 1 vCPU, 1–2 ГБ RAM, 20 ГБ SSD, Python 3.12+, PostgreSQL 14+. У наших провайдеров это AdminVPS Lite за 349 ₽/мес или Promo за 499 ₽/мес, обе цены при оплате за месяц.

Средний проект (1 000–10 000/сут.): 2 vCPU, 4 ГБ RAM, 40 ГБ NVMe SSD, PostgreSQL 15+. Это AdminVPS Micro за 899 ₽/мес при оплате за месяц или Timeweb Cloud MSK 50 за 1 080 ₽/мес при оплате за 12 месяцев.

Крупный проект (10 000+/сут.): 4+ vCPU, 8–16 ГБ RAM, 80+ ГБ NVMe SSD, PostgreSQL 15+ или кластер. У AdminVPS это Start за 1 289 ₽/мес (8 ГБ) или Pro за 3 379 ₽/мес (16 ГБ), обе цены при оплате за месяц.

Важно: SQLite не подходит для продакшна даже на малых проектах при конкурентных запросах. Всегда используйте PostgreSQL или MariaDB на VPS для Django.

• Поддержка актуальных версий ОС и Python. Убедитесь, что провайдер предоставляет образы Ubuntu 22.04/24.04 LTS или Debian 12.
• Тип и скорость дискового хранилища. Для Django хостинга критична скорость случайных операций ввода-вывода (IOPS). Отдавайте предпочтение NVMe SSD.
• Гарантированные ресурсы CPU и RAM. Избегайте тарифов, где CPU и RAM являются «burstable». Для Gunicorn нужны выделенные ядра.
• Пропускная способность и стоимость трафика. Многие провайдеры предлагают безлимитный входящий, но тарифицируют исходящий трафик.
• Качество технической поддержки. Хостинг Python-проектов требует понимания стека: Gunicorn, Nginx, Systemd, Certbot.
• Соотношение цены и производительности. Сравнивайте реальные бенчмарки (sysbench, fio, pgbench), а не только спецификации.
• Географическое расположение дата-центра. Для аудитории из России — Москва, Санкт-Петербург, Амстердам или Франкфурт.

Сводная таблица на август 2026 года. У каждой цены указано условие оплаты — без него число расходится с сайтом провайдера уже через месяц.

AdminVPS: от 349 ₽/мес при помесячной оплате (1 vCPU 3,6 ГГц, 1 ГБ RAM, 15 ГБ NVMe). Под Django берите Micro — 899 ₽/мес за 2 vCPU, 4 ГБ RAM и 60 ГБ NVMe. Базовое администрирование входит, пока подключена панель, — а она бесплатна только первый месяц; полное — в линейке «Всё включено».

Timeweb Cloud: Cloud MSK 40 — 1 000 ₽/мес с публичным IP (2 vCPU 3,3 ГГц, 2 ГБ RAM, 40 ГБ NVMe), MSK 50 с 4 ГБ RAM — 1 200 ₽/мес; обе цены при оплате за месяц, за 12 месяцев вперёд — 900 и 1 080 ₽. Оплата почасовая.

Timeweb: та же линейка Cloud MSK, цены указаны при оплате за год — 900 ₽/мес за MSK 40. Виртуальный хостинг под простые проекты — от 393 ₽/мес при помесячной оплате.

Универсального «лучшего» тарифа нет: под Django одинаково плохо подходят и слишком слабый сервер, и переплата за неиспользуемые ресурсы. Ниже — три сценария и провайдер под каждый из них.

Общее правило по ресурсам: 2 ГБ памяти — минимум, на котором Django запустится вместе с PostgreSQL; 4 ГБ — рабочий объём для проекта с базой, статикой и парой фоновых задач; 8 ГБ и выше — когда добавляются Celery, Redis и очереди.

Подходит, если Django-проект первый или разворачивать сервер некому. В линейке «Всё включено» (она дороже обычных тарифов) настройку Nginx, Gunicorn, PostgreSQL и SSL сделают за вас, а не оставят на восемь шагов инструкции ниже.

Под рабочий проект берите Micro — 899 ₽/мес при помесячной оплате: 2 vCPU 3,6 ГГц, 4 ГБ RAM, 60 ГБ NVMe. Если добавляются Celery и Redis, ближе тариф Start: 4 vCPU, 8 ГБ RAM, 80 ГБ NVMe за 1 289 ₽/мес.

Django, Gunicorn, PostgreSQL и Nginx есть в каталоге приложений — ставятся без ручной сборки. В тариф входят NVMe на всех планах и бесплатная защита от DDoS уровней L2–L4.

Ограничение: нет почасовой оплаты и API для автоматического создания серверов. Для одного-двух проектов это не мешает, для динамической инфраструктуры — да.

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

Начальный тариф Cloud MSK 40 — 1 000 ₽/мес при оплате за месяц (900 ₽ при оплате за 12 месяцев), публичный IPv4 входит в тариф: 2 vCPU 3,3 ГГц, 2 ГБ RAM, 40 ГБ NVMe. Для Django с базой лучше MSK 50 — 4 ГБ RAM за 1 200 ₽/мес.

Когда проект перерастёт один сервер, здесь же есть управляемый Kubernetes, объектное хранилище S3 под медиафайлы и управляемый PostgreSQL — базу можно вынести с сервера приложения без переезда к другому провайдеру.

Ограничение: администрирование не входит в стоимость, сервер настраиваете сами.

Подходит для внутренних сервисов и небольших сайтов на Django, где нагрузка не меняется месяцами. Компания на рынке с 2006 года и держит около 700 тысяч сайтов.

Линейка та же, Cloud MSK, но цены указаны при оплате за год: 900 ₽/мес за 2 ГБ памяти. Скидки за срок: 3 месяца −5 %, полгода −7 %, год −10 %. Есть бесплатный тест 10 дней.

Если Django нужен не сам по себе, а как часть сайта с админкой на готовой CMS, посмотрите виртуальный хостинг — от 393 ₽/мес при помесячной оплате. Django туда не поставить, но и сервер администрировать не придётся.

Полный гайд по Django деплою на чистый VPS с Ubuntu 22.04/24.04. Стек: Python 3.12 + Gunicorn + Nginx + PostgreSQL + Let's Encrypt.

После подключения по SSH обновите систему и создайте непривилегированного пользователя:

# Обновляем пакеты
sudo apt update && sudo apt upgrade -y

# Создаём пользователя для приложения
sudo adduser django_user
sudo usermod -aG sudo django_user

# Настраиваем базовый файрвол (профиля «Nginx Full» до установки Nginx ещё нет)
sudo ufw allow OpenSSH
sudo ufw allow 80/tcp
sudo ufw allow 443/tcp
sudo ufw enable

Ubuntu 24.04 поставляется с Python 3.12 из коробки — нужен только модуль venv. Отдельный virtualenv ставить не надо: окружение создаёт встроенный venv, а pip3 install в системный Python на Ubuntu 24.04 откажет с ошибкой externally-managed-environment (PEP 668). Для Ubuntu 22.04 добавьте PPA:

# Ubuntu 24.04: Python 3.12 уже стоит, нужен модуль venv
sudo apt install python3.12-venv -y

# Ubuntu 22.04: Python 3.12 из PPA deadsnakes
sudo add-apt-repository ppa:deadsnakes/ppa -y
sudo apt update
sudo apt install python3.12 python3.12-venv python3.12-dev -y

# Проверяем версию
python3.12 --version

# Устанавливаем PostgreSQL
sudo apt install postgresql postgresql-contrib libpq-dev -y
sudo systemctl start postgresql
sudo systemctl enable postgresql

# Создаём базу данных и пользователя
sudo -u postgres psql <<EOF
CREATE DATABASE mydjangodb;
CREATE USER mydjango_user WITH PASSWORD 'SecurePass123';
ALTER ROLE mydjango_user SET client_encoding TO 'utf8';
ALTER ROLE mydjango_user SET default_transaction_isolation TO 'read committed';
ALTER ROLE mydjango_user SET timezone TO 'UTC';
GRANT ALL PRIVILEGES ON DATABASE mydjangodb TO mydjango_user;
ALTER DATABASE mydjangodb OWNER TO mydjango_user;
\q
EOF

Строка ALTER DATABASE … OWNER обязательна на PostgreSQL 15 и новее (в Ubuntu 24.04 стоит 16-я): с 15-й версии создавать таблицы в схеме public может только владелец базы, и GRANT на базу этого права не даёт. Без неё migrate падает с ошибкой «permission denied for schema public» — так и вышло при проверке 11.10.2026.

# Переключаемся на нашего пользователя
su - django_user

# Клонируем репозиторий
git clone https://github.com/yourname/your-django-project.git ~/myproject
cd ~/myproject

# Создаём виртуальное окружение
python3.12 -m venv venv
source venv/bin/activate

# Устанавливаем зависимости
pip install -r requirements.txt
pip install gunicorn psycopg2-binary

# Настраиваем переменные окружения
cat > ~/myproject/.env <<EOF
DEBUG=False
SECRET_KEY=your-very-secret-key-here
DATABASE_URL=postgresql://mydjango_user:SecurePass123@localhost/mydjangodb
ALLOWED_HOSTS=yourdomain.com,www.yourdomain.com
EOF

Django сам .env не читает. Этот файл нужен systemd (EnvironmentFile в шаге 8), а базу, папку статики и разрешённые хосты Django берёт из settings.py. Если их не указать, migrate пройдёт без ошибок, но данные молча лягут в файл SQLite рядом с проектом, а не в PostgreSQL; collectstatic без STATIC_ROOT упадёт. Допишите в конец myproject/settings.py:

DATABASES = {"default": {"ENGINE": "django.db.backends.postgresql", "NAME": "mydjangodb", "USER": "mydjango_user",
             "PASSWORD": "SecurePass123", "HOST": "localhost", "PORT": "5432"}}
STATIC_ROOT = BASE_DIR / "staticfiles"
DEBUG = False
ALLOWED_HOSTS = ["yourdomain.com", "www.yourdomain.com"]

Пароль базы и SECRET_KEY в репозиторий не кладите: читайте их из окружения (os.environ) — переменные из .env systemd передаст процессу Gunicorn. Теперь миграции и статика:

# Применяем миграции и собираем статику
python manage.py migrate
python manage.py collectstatic --noinput

# Проверяем, что Gunicorn запускается корректно
cd ~/myproject && source venv/bin/activate
gunicorn --bind 0.0.0.0:8000 myproject.wsgi:application
# Если работает — останавливаем (Ctrl+C)

# Создаём конфигурационный файл Gunicorn
cat > ~/myproject/gunicorn.conf.py <<EOF
bind = 'unix:/run/gunicorn/gunicorn.sock'
workers = 3
worker_class = 'sync'
timeout = 30
keepalive = 2
max_requests = 1000
max_requests_jitter = 50
preload_app = True
accesslog = '/var/log/gunicorn/access.log'
errorlog = '/var/log/gunicorn/error.log'
loglevel = 'info'
EOF

# Создаём директории для логов и сокета (/run очищается при перезагрузке —
# дальше каталог сокета создаёт сам systemd, см. RuntimeDirectory в шаге 8)
sudo mkdir -p /run/gunicorn /var/log/gunicorn
sudo chown django_user:django_user /run/gunicorn /var/log/gunicorn

Gunicorn + Nginx + Django — классическая связка для production. Сначала установите Nginx: на чистой Ubuntu 24.04 его нет, а в предыдущих шагах он не ставился.

sudo apt install nginx -y

Создаём конфиг Nginx:

# /etc/nginx/sites-available/myproject
server {
    listen 80;
    server_name yourdomain.com www.yourdomain.com;

    # Статические файлы
    location /static/ {
        alias /home/django_user/myproject/staticfiles/;
        expires 30d;
        add_header Cache-Control "public, immutable";
    }

    # Медиафайлы
    location /media/ {
        alias /home/django_user/myproject/media/;
        expires 7d;
    }

    # Проксирование на Gunicorn
    location / {
        proxy_pass http://unix:/run/gunicorn/gunicorn.sock;
        proxy_set_header Host $host;
        proxy_set_header X-Real-IP $remote_addr;
        proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
        proxy_set_header X-Forwarded-Proto $scheme;
    }
}

# Nginx работает от www-data, а домашний каталог в Ubuntu 24.04 создаётся
# с правами 750 (HOME_MODE в /etc/login.defs) — без этой строки статика
# и медиа из /home/django_user отдадут 403
sudo usermod -aG django_user www-data

# Активируем конфигурацию
sudo ln -s /etc/nginx/sites-available/myproject /etc/nginx/sites-enabled/
sudo nginx -t
sudo systemctl restart nginx

# Устанавливаем Certbot
sudo apt install certbot python3-certbot-nginx -y

# Получаем сертификат
sudo certbot --nginx -d yourdomain.com -d www.yourdomain.com \
  --non-interactive --agree-tos --email admin@yourdomain.com

# Проверяем автоматическое обновление
sudo certbot renew --dry-run

Сохраните юнит в файл /etc/systemd/system/gunicorn.service:

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

[Unit]
Description=Gunicorn daemon for Django project
After=network.target postgresql.service
Requires=postgresql.service

[Service]
User=django_user
Group=django_user
WorkingDirectory=/home/django_user/myproject
EnvironmentFile=/home/django_user/myproject/.env
ExecStart=/home/django_user/myproject/venv/bin/gunicorn \
    --config /home/django_user/myproject/gunicorn.conf.py \
    myproject.wsgi:application
Restart=on-failure
RestartSec=5
RuntimeDirectory=gunicorn

[Install]
WantedBy=multi-user.target

Строка RuntimeDirectory=gunicorn обязательна: каталог /run стирается при каждой перезагрузке, и без неё Gunicorn не может создать сокет — сайт отдаёт 502, а systemd перезапускает службу по кругу. При проверке 11.10.2026 так и было; со строкой после перезагрузки страница отвечает 200.

# Активируем и запускаем
sudo systemctl daemon-reload
sudo systemctl enable gunicorn
sudo systemctl start gunicorn
sudo systemctl status gunicorn

После выполнения всех шагов ваш Django-проект будет доступен по HTTPS, автоматически стартовать при перезагрузке сервера и корректно обслуживаться через Nginx + Gunicorn.

Наш замер 11.10.2026. Все шаги этой инструкции пройдены на чистом сервере Timeweb Cloud: 2 vCPU 3,3 ГГц, 2 ГБ памяти, 40 ГБ NVMe, Ubuntu 24.04.5 (тариф Cloud MSK Ultra 40 — MSK 40 в тот час заказать не удалось, «нет свободных узлов»). Сервер включился через 24 секунды после заказа, SSH ответил через 45 секунд. Проект — чистый django-admin startproject: Django 6.1.2 (столько ставит pip на эту дату), Gunicorn 26.2.0 с тремя воркерами, PostgreSQL 16.15, Nginx.

• Всё запущено, запросов нет: занято 396 МБ из 1 900 МБ. Gunicorn (мастер и три воркера) — 170 МБ, PostgreSQL — 70 МБ, Nginx — 11 МБ.
• После 3 000 запросов к странице входа админки, по 20 одновременно: занято 603 МБ, доступно 1 296 МБ, ошибок 0.
• Подкачки (swap) на чистом сервере нет: когда память кончится, ядро завершит процесс, а не замедлит его.
• Диск после установки всего стека: 2,3 ГБ из 38 ГБ.

По итогам прогона в инструкцию внесено пять исправлений: установка Nginx (шаг 6), владелец базы для PostgreSQL 15+ (шаг 3), настройки базы и STATIC_ROOT в settings.py (шаг 4), путь юнита и RuntimeDirectory (шаг 8).

Это пустой проект, а не ваше приложение: свои модели, запросы к базе и фоновые задачи займут больше. Замер разовый — один сервер, один день. Скорость сети и диска не мерили, HTTPS из шага 7 не проверяли (для него нужен домен), Ubuntu 22.04 не проверяли.

После развёртывания Django-приложения на VPS настройте мониторинг для отслеживания производительности и оперативного реагирования на проблемы:

• Sentry — для отслеживания ошибок в реальном времени. Бесплатный self-hosted вариант или облачный (10000 событий/мес бесплатно).
• Prometheus + Grafana — для мониторинга системных метрик (CPU, RAM, диск) и метрик приложения (время ответа, количество запросов).
• Django Debug Toolbar — для профилирования SQL-запросов и шаблонов в dev-окружении.
• django-silk — для профилирования запросов в production. Записывает время выполнения каждого view, SQL-запросы и их длительность.

Для масштабирования Django при росте нагрузки: добавьте Celery + Redis для фоновых задач (отправка email, обработка изображений, генерация отчётов). Настройте кэширование через Redis/Memcached для часто запрашиваемых данных. При достижении лимитов одного VPS — разделите приложение и базу данных на отдельные серверы.

Для статики и медиа-файлов используйте S3-совместимое хранилище (Timeweb Cloud S3) через django-storages. Это разгрузит основной VPS и позволит масштабировать хранилище независимо от вычислительных ресурсов.

Выбор сервера под Django сводится к трём сценариям. Нужен администратор в комплекте — AdminVPS: тариф Micro с 4 ГБ памяти за 899 ₽/мес при помесячной оплате. Нагрузка меняется или нужен тестовый стенд — Timeweb Cloud с почасовой оплатой. Проект простой и стабильный — Timeweb. Для персональных данных подойдёт любой из трёх: у всех российские площадки и закрывающие документы.

Следуйте нашей пошаговой инструкции по настройке стека Django + Gunicorn + Nginx + PostgreSQL — и ваш проект будет работать стабильно и безопасно.

Сравните все тарифы и выберите оптимальный VPS для Django на EasyLinkLife.com прямо сейчас.

Django на VPS — это мощное сочетание зрелого фреймворка и гибкой инфраструктуры. Начните с минимальной конфигурации, настройте CI/CD для автоматического деплоя и масштабируйтесь по мере роста проекта. NVMe-диски и достаточный объём RAM для PostgreSQL обеспечат быструю работу ORM даже со сложными запросами.

Перед выводом Django-приложения в production на VPS пройдите этот чек-лист:

• DEBUG = False в settings.py. Никогда не оставляйте DEBUG = True на production — это раскрывает стек-трейсы и переменные окружения.
• SECRET_KEY вынесен в переменные окружения (.env файл), не захардкожен в settings.py.
• ALLOWED_HOSTS содержит только ваш домен, не ['*'].
• HTTPS настроен через Nginx + Let's Encrypt. SECURE_SSL_REDIRECT = True, SESSION_COOKIE_SECURE = True.
• Статика собрана через collectstatic и отдаётся Nginx напрямую, без прохождения через Django.
• Gunicorn настроен с правильным количеством workers: (2 * CPU_CORES) + 1.
• PostgreSQL используется вместо SQLite (SQLite не подходит для production с конкурентным доступом).
• Настроен мониторинг ошибок через Sentry и логирование через Django logging framework.

Эти базовые меры предотвратят 90% типичных проблем с безопасностью и производительностью Django на VPS.

Для автоматического SSL используйте certbot с Nginx: certbot --nginx -d yourdomain.com. Автопродление отдельно настраивать не нужно: пакет certbot сам ставит таймер systemd certbot.timer (проверено на Ubuntu 24.04 11.10.2026), проверить его — systemctl list-timers | grep certbot. Это обеспечит бесперебойное HTTPS без ручного вмешательства — критически важно для production Django-приложений, обрабатывающих пользовательские данные.

Для мониторинга производительности Django в production используйте django-prometheus — он экспортирует метрики (время ответа, количество ошибок, SQL-запросы) в формате Prometheus для визуализации в Grafana.

Используйте наш каталог провайдеров для выбора VPS с PostgreSQL-совместимой конфигурацией: NVMe-диски для быстрых SQL-запросов и достаточный объём RAM для Django ORM кэширования.

Общие рекомендации по выбору сервера — в руководстве по выбору VPS. Обзоры провайдеров: Timeweb, AdminVPS. Для контейнеризации Django-проекта ознакомьтесь с обзором Docker хостинга. Официальная документация: Django Deployment Guide.

Читайте также: Как выбрать VPS хостинг, Настройка Nginx на VPS, Docker хостинг, Каталог провайдеров.