Django app на VPS: production checklist без типовых ошибок

Django-приложение чаще всего ломается не потому, что “VPS плохой” или “Django сложный”. Оно ломается потому, что локальная разработка и production — это два разных режима. Локально проект работает на runserver, SQLite, DEBUG=True и встроенной раздаче static-файлов. На VPS нужны PostgreSQL, Nginx, Gunicorn или Uvicorn, systemd, SSL, переменные окружения, миграции, backup и понятный порядок deploy.

Реальные проблемы, с которыми чаще всего приходят после первого деплоя: 502 Bad Gateway, админка без CSS, ошибка 500 после DEBUG=False, не применились migrations, Django не видит переменные окружения, PostgreSQL съел RAM, сайт умер после перезагрузки VPS, media-файлы потерялись при обновлении кода, база сломалась после неудачной миграции.

Эта статья — не абстрактная инструкция “как поставить Django”. Это production checklist: что проверить до заказа VPS, что настроить до запуска и какие ошибки не повторять.

Когда Django app нормально размещать на VPS

VPS подходит для Django-проекта, если это сайт, API, CRM, личный кабинет, SaaS MVP, Django REST Framework backend, Telegram-бот с web-интерфейсом, внутренняя админка, dashboard, небольшой marketplace или production-проект с предсказуемой нагрузкой.

Нормальная схема для Django на VPS обычно выглядит так:

• Nginx принимает HTTP/HTTPS-запросы, отдаёт static/media и проксирует приложение.
• Gunicorn запускает Django как WSGI-приложение.
• Uvicorn используется, если проект на ASGI, WebSocket или async-стеке.
• PostgreSQL хранит production-базу.
• systemd держит приложение запущенным после перезагрузки и перезапускает его при сбое.
• Certbot или другой ACME-клиент выпускает SSL-сертификат.
• backup сохраняет базу, media-файлы и конфигурацию.
• monitoring показывает, что сайт жив, а диск, RAM и база не умирают молча.

Для Django-проекта можно выбрать VPS Hostyrex: https://hostyrex.net/en/vps.html. Если конфигурация понятна, тарифы доступны в WHMCS: https://client.hostyrex.net/store/vps.

Что люди реально ищут перед деплоем Django

Обычно пользователь не ищет “купить VPS для Django” с первого раза. Он ищет решение конкретной боли:

• django production checklist
• django deploy to vps nginx gunicorn postgres
• django static files not loading production
• django admin css not loading nginx
• django 502 bad gateway gunicorn nginx
• django migrations production best practices
• django postgres connection error production
• django debug false 500 error
• django media files production nginx
• how much RAM for Django VPS

Это важный момент. Клиенту не нужна рекламная страница “быстрый VPS”. Ему нужно понять, почему его проект падает, что выбрать, чтобы не переделывать через неделю, и какие вопросы задать провайдеру до оплаты.

Главная ошибка: переносить локальную схему в production

Самый частый сценарий: разработчик поднял VPS, скопировал проект, установил Python-зависимости, запустил python manage.py runserver 0.0.0.0:8000, открыл сайт по IP и решил, что deploy готов. Это не production.

runserver нужен для разработки. Он не должен обслуживать реальных пользователей. Если приложение работает только пока открыт SSH-сеанс, если оно падает после закрытия терминала или не стартует после reboot — это не проблема VPS. Это неправильная архитектура запуска.

В production Django должен работать через Gunicorn/Uvicorn и systemd. Nginx должен принимать внешний трафик и проксировать запросы в application server. Это не усложнение ради красоты, а базовая защита от хаоса: логи в одном месте, автозапуск после перезагрузки, нормальная обработка соединений, SSL, static-файлы и контроль процессов.

502 Bad Gateway после deploy: где искать проблему

502 Bad Gateway — одна из самых частых ошибок Django на VPS. Пользователь видит страницу Nginx и думает, что “сервер не работает”. На практике Nginx почти всегда работает. Он просто не может достучаться до Gunicorn/Uvicorn.

Типовые причины:

• Gunicorn не запущен.
• Gunicorn упал из-за ошибки в Django.
• В systemd указан неправильный путь к virtualenv.
• Неправильный WorkingDirectory.
• Не загружены переменные окружения.
• В Nginx указан не тот socket или порт.
• Нет прав на Unix socket.
• После обновления кода не установлен новый пакет из requirements.txt.
• Миграции не применились, приложение падает при запросе к базе.

Правильная диагностика начинается не с переустановки сервера, а с логов:

systemctl status gunicorn
journalctl -u gunicorn -n 100 --no-pager
nginx -t
tail -n 100 /var/log/nginx/error.log

Если в логах Gunicorn видно ModuleNotFoundError, ImproperlyConfigured, ошибку подключения к базе или отсутствие переменной окружения — VPS тут ни при чём. Нужно чинить окружение приложения.

DEBUG=False и ошибка 500: почему локально работает, а на VPS нет

Многие видят такую картину: при DEBUG=True сайт открывается, при DEBUG=False — 500 error или пропадают static-файлы. Это нормальный сигнал, что проект не подготовлен к production.

До запуска нужно проверить:

• DEBUG=False в production.
• ALLOWED_HOSTS содержит домен и/или IP сервера.
• CSRF_TRUSTED_ORIGINS настроен для HTTPS-домена, если используются формы, админка или API с CSRF.
• SECRET_KEY не хранится в Git и не совпадает с dev-ключом.
• Все production-переменные окружения реально видны systemd-сервису.
• Логи Django пишутся в файл, journald или Sentry-подобную систему, а не исчезают.

Частая ошибка: переменные окружения есть в SSH-сессии, но их нет у systemd-сервиса. Разработчик проверяет echo $DATABASE_URL, видит значение и думает, что всё настроено. Но Gunicorn запускает systemd, а systemd не обязан видеть переменные из вашей интерактивной shell-сессии.

Нормальная практика — хранить production env в отдельном файле, например:

/etc/project-name/project.env

И подключать его в systemd unit через EnvironmentFile. Тогда deploy становится повторяемым, а не зависит от того, кто и как вошёл по SSH.

PostgreSQL на том же VPS: когда нормально, а когда опасно

Для небольшого и среднего Django-проекта PostgreSQL на том же VPS — нормальный старт. Это проще, дешевле и быстрее по latency, чем выносить базу на отдельный сервер без необходимости. Но у этой схемы есть пределы.

Проблемы начинаются, когда VPS выбран “впритык”: 1 GB RAM, несколько Gunicorn workers, PostgreSQL, Redis, Celery, Nginx, сборка пакетов, deploy, backup — и всё это на одном сервере. Потом в логах появляется OOM killer, PostgreSQL перезапускается, сайт даёт 502, а владелец думает, что “хостинг нестабильный”.

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

Что важно для PostgreSQL на VPS:

• Достаточно RAM не только для Django, но и для базы.
• NVMe-диск, если есть активная запись, индексы, отчёты или импорт данных.
• Мониторинг свободного места на диске.
• Backup базы до миграций и перед крупными обновлениями.
• Ограниченный доступ: PostgreSQL не должен быть открыт на весь интернет без необходимости.
• Отдельный database user для приложения, а не работа от суперпользователя.
• Понимание количества соединений: Django workers, Celery и management-команды тоже открывают подключения.

Если база уже большая, есть тяжёлые запросы, отчёты, много фоновых задач, high-load API или постоянная запись, VPS может быть не лучшей архитектурой. В таком случае лучше рассматривать отдельный database server или dedicated server: https://hostyrex.net/en/servers.html.

Миграции в production: самая недооценённая зона риска

python manage.py migrate выглядит безопасно, пока проект маленький. Но на живой базе миграция может заблокировать таблицу, долго перестраивать индекс, упасть на несовместимых данных, удалить поле, которое ещё использует старый код, или сломать rollback.

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

Перед production-миграциями нужно иметь простой порядок:

1. Сделать backup базы.
2. Проверить миграции на staging или копии базы.
3. Посмотреть, какие миграции будут применены.
4. Понять, есть ли операции с большими таблицами.
5. Запустить миграции в контролируемое время.
6. Проверить приложение после deploy.
7. Иметь план rollback не только кода, но и данных.

Особенно опасны миграции, которые удаляют поля, переименовывают поля, делают nullable-поле обязательным, меняют тип колонки, создают тяжёлые индексы на больших таблицах или массово пересчитывают данные внутри migration-файла.

Более безопасный подход для живых проектов — делать изменения в несколько этапов. Например: сначала добавить новое nullable-поле, потом выкатить код, который умеет работать и со старой, и с новой схемой, затем заполнить данные, затем уже ужесточать ограничения. Это скучнее, но именно так снижается риск положить production.

Static files: почему Django admin открывается без CSS

Одна из самых популярных проблем: после деплоя Django admin открывается, но без стилей. Или сайт загружается, но CSS/JS дают 404. Почти всегда причина в static-файлах.

В development Django сам помогает отдавать static. В production это должен делать Nginx или другой web server. Для этого нужно:

• Настроить STATIC_URL.
• Настроить STATIC_ROOT.
• Запустить python manage.py collectstatic.
• Настроить Nginx location для static.
• Проверить права на директорию static.
• Не путать директорию исходных static-файлов и директорию, куда collectstatic их собирает.

Плохой признак: static работает только при DEBUG=True. Это значит, что production-раздача static не настроена.

Типовой блок Nginx выглядит по смыслу так:

location /static/ {
    alias /var/www/project/static/;
}

Путь должен совпадать с STATIC_ROOT. Если в Django указано одно, а в Nginx другое — админка будет без CSS.

Media files: ошибка, которая всплывает позже

Со static-файлами обычно разбираются быстро, потому что без них сразу видно сломанный интерфейс. С media-файлами хуже: ошибка может проявиться через месяц, когда пользователи уже загрузили документы, фото, аватары или вложения.

Media files — это пользовательские файлы. Их нельзя хранить как часть кода и нельзя терять при каждом deploy. Если вы делаете git pull, пересобираете проект, удаляете директорию приложения или деплоите через Docker без volume — можно случайно потерять загруженные файлы.

Что проверить:

• MEDIA_ROOT находится вне директории, которую вы удаляете при deploy.
• Nginx отдаёт /media/, но не исполняет загруженные файлы как код.
• Media files попадают в backup.
• Есть лимит размера загрузки в Nginx и Django, если пользователи загружают большие файлы.
• Есть понимание, когда media лучше вынести в object storage, а не хранить на системном диске VPS.

Если проект работает с большим количеством файлов, видео, изображений, документов или пользовательского контента, заранее продумайте storage. VPS может быть нормальным стартом, но системный диск не должен быть единственной копией важных данных.

Сколько RAM и CPU нужно Django VPS

Ошибка — считать только Django-процесс. На VPS будут жить Python, Gunicorn workers, PostgreSQL, Nginx, Redis, Celery, cron, SSH, systemd, certbot, backup-процессы и иногда сборка зависимостей. Если взять слишком маленький VPS, он может работать в первый день, но начнёт падать при deploy, backup или первом всплеске трафика.

Практический ориентир:

• 1 vCPU / 1 GB RAM — только тест, dev, маленький личный проект без серьёзной базы.
• 2 vCPU / 2 GB RAM — минимальный разумный старт для небольшого production Django + PostgreSQL.
• 2–4 vCPU / 4 GB RAM — нормальный старт для сайта/API с пользователями, админкой, Redis/Celery и регулярными deploy.
• 4+ vCPU / 8+ GB RAM — если есть активная база, фоновые задачи, импорт данных, отчёты, много API-запросов или несколько Django-проектов.

Это не жёсткое правило, а практический ориентир. Один плохо написанный SQL-запрос может положить VPS сильнее, чем тысяча простых запросов. Поэтому важны не только ресурсы, но и мониторинг, индексы, логи slow queries и контроль количества workers.

Gunicorn workers: больше не всегда лучше

Популярная ошибка — поставить много Gunicorn workers “чтобы было быстрее”. На маленьком VPS это может дать обратный эффект: каждый worker ест память, каждый может держать соединение с PostgreSQL, а при нехватке RAM система начнёт убивать процессы.

Для старта лучше выбрать умеренное количество workers и наблюдать за CPU, RAM, latency и ошибками. Если приложение упирается в базу, увеличение workers не ускорит сайт, а только создаст больше одновременных запросов к PostgreSQL.

Если есть Celery, отдельные background workers тоже нужно считать. Они не бесплатные. Они используют RAM, CPU и подключения к базе.

Firewall и безопасность: что открыть на VPS

Для обычного Django production-сервера наружу обычно нужны только:

• 22/tcp для SSH, лучше ограничить по IP или защитить ключами и fail2ban.
• 80/tcp для HTTP и выпуска SSL.
• 443/tcp для HTTPS.

PostgreSQL не должен быть открыт на весь интернет, если в этом нет явной необходимости. Redis также нельзя оставлять публичным. Панели администрирования, debug-интерфейсы, Flower, pgAdmin, Prometheus, Grafana и внутренние API не должны висеть открытыми без авторизации и ограничения доступа.

Перед запуском проекта проверьте условия использования и сетевые правила провайдера, особенно если приложение связано с массовыми регистрациями, proxy, scraping, mail-рассылками, VPN-функциями, пользовательским контентом или спорной нагрузкой: https://hostyrex.net/en/terms.html.

Backup: без него production — это азартная игра

У Django-проекта обычно есть три важные части:

• Код — обычно хранится в Git.
• База данных — PostgreSQL.
• Media files — пользовательские загрузки.

Многие делают backup только кода, потому что “он же в Git”. Это почти бесполезно для восстановления бизнеса. Самое ценное — база и пользовательские файлы.

Минимальный backup-план:

• Ежедневный backup PostgreSQL.
• Backup media-файлов.
• Хранение backup не только на том же VPS.
• Retention: несколько последних копий, а не один файл, который можно перезаписать битым дампом.
• Проверка восстановления хотя бы на тестовом сервере.
• Backup перед крупными миграциями и обновлениями зависимостей.

Если backup лежит только на том же диске, что и production, это не полноценная защита. При ошибке пользователя, компрометации, поломке файловой системы или удалении сервера можно потерять всё сразу.

Monitoring: что нужно отслеживать

Без monitoring владелец узнаёт о проблеме от клиента. Для production Django это плохой сценарий.

Минимум, который стоит отслеживать:

• Доступность сайта по HTTPS.
• HTTP-коды 500/502/504.
• Свободное место на диске.
• RAM и swap.
• CPU load.
• Статус Gunicorn/Uvicorn.
• Статус PostgreSQL.
• Срок действия SSL-сертификата.
• Ошибки Django в логах.
• Успешность backup.

Самая неприятная поломка — не та, где сайт сразу упал. Самая неприятная — когда backup перестал делаться две недели назад, диск медленно заполнился, база упала ночью, а восстановиться не из чего.

Что проверить перед заказом VPS для Django

Перед оплатой VPS лучше ответить на эти вопросы:

• Какой Python/Django/PostgreSQL стек будет использоваться?
• Нужен WSGI или ASGI?
• Будут ли WebSocket?
• Будет ли Celery, Redis, background jobs?
• Сколько пользователей ожидается в первые месяцы?
• Будет ли активная загрузка файлов?
• Насколько быстро будет расти база?
• Нужен ли отдельный staging-сервер?
• Где будут храниться backup?
• Кто отвечает за обновления безопасности?
• Нужен ли managed support или вы администрируете всё сами?
• Какие порты должны быть открыты?
• Есть ли требования к IP reputation, локации, routing или abuse policy?

Если вы не уверены по конфигурации, лучше описать проект до заказа: Django version, PostgreSQL size, ожидаемая нагрузка, наличие Celery/Redis, объём media-файлов и требования к backup. Связаться с Hostyrex можно здесь: https://hostyrex.net/en/contacts.html.

Когда VPS не подходит

VPS — хороший старт для большинства Django-проектов, но не универсальное решение.

Лучше сразу смотреть в сторону dedicated server или отдельной архитектуры, если:

• PostgreSQL уже большой и активно пишет на диск.
• Есть тяжёлые отчёты, аналитика, импорт/экспорт больших данных.
• Нужны гарантированные CPU-ресурсы под постоянную нагрузку.
• Проект хранит много пользовательских файлов.
• Нужно несколько production-сервисов на одном узле.
• Нужен Proxmox, отдельные VM, staging и production на своей инфраструктуре.
• Есть требования к отдельной сети, IP-подсети, BGP или сложному firewall.

В таких случаях стоит смотреть dedicated servers: https://hostyrex.net/en/servers.html. Если нужны IPv4-адреса, подсети, RDNS или BGP-сценарии, смотрите страницу IPv4 network: https://hostyrex.net/en/ip.html.

Короткий production checklist Django на VPS

• DEBUG=False включён в production.
• ALLOWED_HOSTS настроен.
• SECRET_KEY, database password и API keys вынесены из Git.
• PostgreSQL работает не от суперпользователя приложения.
• PostgreSQL не открыт публично без необходимости.
• Gunicorn/Uvicorn работает через systemd.
• Nginx проксирует приложение и отдаёт static/media.
• collectstatic выполнен после deploy.
• Media files хранятся отдельно от кода.
• SSL установлен и обновляется автоматически.
• Firewall открыт только для нужных портов.
• Backup базы и media настроен.
• Backup хранится вне основного VPS.
• Миграции проверяются до production.
• Логи Django, Gunicorn, Nginx и PostgreSQL доступны.
• Monitoring проверяет сайт, диск, RAM, SSL и backup.

Как Hostyrex может помочь с Django-проектом

Hostyrex предоставляет VPS для Django-приложений, API, сайтов, backend-сервисов, PostgreSQL-проектов и production-окружений на Linux. На VPS можно развернуть Nginx, Gunicorn/Uvicorn, PostgreSQL, Redis, Celery, SSL и monitoring под конкретную задачу.

Если у вас стандартный Django-проект и вы понимаете требования, можно выбрать VPS здесь: https://client.hostyrex.net/store/vps.

Если проект уже production, есть база, пользователи, миграции, media-файлы или риск простоя, лучше не заказывать сервер вслепую. Опишите задачу перед оплатой: стек, нагрузку, размер базы, файлы, требования к backup и кто будет администрировать сервер. Контакты: https://hostyrex.net/en/contacts.html. Если нужно сопровождение, смотрите managed services: https://client.hostyrex.net/store/managed-services.

FAQ

Можно ли запустить Django на VPS?

Да. VPS — нормальный вариант для Django production, если правильно настроить Nginx, Gunicorn или Uvicorn, PostgreSQL, SSL, firewall, backup и monitoring. Просто запустить manage.py runserver на публичном IP — неправильный вариант.

Почему Django на VPS показывает 502 Bad Gateway?

Обычно Nginx не может подключиться к Gunicorn/Uvicorn. Причина может быть в упавшем systemd-сервисе, неправильном socket/port, ошибке в Django, отсутствии переменных окружения, проблеме с virtualenv или миграциями. Начинать нужно с journalctl -u gunicorn и /var/log/nginx/error.log.

Почему Django admin без CSS после deploy?

Почти всегда не настроены static files. В production нужно задать STATIC_ROOT, выполнить collectstatic и настроить Nginx так, чтобы он отдавал директорию static по STATIC_URL.

Можно ли использовать SQLite для Django production?

Для маленького личного проекта — иногда можно. Для нормального production с пользователями, платежами, API, админкой, транзакциями и ростом данных лучше использовать PostgreSQL.

PostgreSQL лучше держать на том же VPS или отдельно?

Для небольшого проекта можно держать на том же VPS. Если база большая, нагрузка постоянная, есть тяжёлые запросы, отчёты, много фоновых задач или требования к отказоустойчивости, лучше рассматривать отдельный сервер для базы или dedicated architecture.

Нужно ли делать backup перед Django migrations?

Да. Перед production-миграциями нужен backup базы. Особенно если миграция меняет большие таблицы, удаляет поля, меняет типы данных, добавляет ограничения или содержит data migration.

Почему после перезагрузки VPS Django не запускается?

Скорее всего приложение запускали вручную из SSH. В production Gunicorn/Uvicorn должен быть оформлен как systemd-сервис с автозапуском после reboot.

Сколько RAM нужно для Django VPS?

Для теста хватит минимальной конфигурации. Для небольшого production Django + PostgreSQL лучше начинать минимум с 2 GB RAM, а для проекта с Redis, Celery, API и активной базой — смотреть в сторону 4 GB RAM и выше.

Нужен ли Docker для Django на VPS?

Не обязательно. Django можно нормально запускать на VPS через virtualenv, systemd, Gunicorn и Nginx. Docker полезен, если вы понимаете volumes, networks, env, logs, backup и deploy-процесс. Если Docker используется без понимания хранения базы и media-файлов, он может добавить проблем.

Что важнее для Django VPS: CPU, RAM или диск?

Зависит от проекта. Для большинства Django + PostgreSQL проектов RAM и быстрый диск часто важнее, чем большое количество CPU. Если база активно пишет, есть индексы, отчёты или импорт данных, NVMe-диск становится критичным.

Можно ли разместить несколько Django-проектов на одном VPS?

Да, если хватает RAM, CPU и диска. Но каждый проект должен иметь отдельный systemd-сервис, отдельные env-переменные, отдельный database user, отдельные логи и понятную схему backup. Если проекты production-критичные, лучше не складывать всё на один маленький VPS.

Что спросить у провайдера перед заказом VPS под Django?

Уточните CPU/RAM/NVMe, локацию, IPv4, доступ к firewall, возможность backup, ограничения по трафику, правила abuse policy, поддержку reinstall, reverse DNS при необходимости, доступность managed support и что будет при превышении ресурсов или жалобах на проект.