Сергей П

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

Вот есть детальная каноничная окументация как такое делать
https://learndjango.com/tutorials/django-slug-tutorial
Если вам нужно удовлетворить какие-то свои изощренные хотелки, то, предполагается, что у вас уже достаточно опыта, чтобы обосновать таковые как с точки зрения производительности, так и с точки зрения архитектуры.
Я не понимаю вот этого "не хочу". Детализируйте причину этого? У вас джанго лишь для рендера статического контента и вам не нужна индексация? Вы как-то глубоко переделали индексы и БД, чтобы отдельное поле было не нужно или выглядело слишком сложным?

Мне кажется, что пока нет достаточно опыта и понимания, нужно делать классически и по документации. А когда появится глубокое понимание, то отпадут либо лишние сомнительные хотелки, либо вопросы как их удовлетворить.

Как обычно, как любой другой сервер.
Проектируете API, реализуете необходимые модели данных, создаёте хендлеры для API, настраиваете CI/CD и разворачиваете на сервере в интернете, например VDS. Помимо прочего ставите Nginx, который будет заворачивать трафик в SSL и раздавать статику. Сертификат можно получить бесплатно через Let's Encrypt. Нужно лишь настроить специальный скрипт (certbot), который раз в месяц будет этот сертификат автоматически продлять.
Кто там к вам на API будет ходить: браузер или мобильное приложение - это не важно.

Вы немного неправильно называете инстанс. Модель - это класс, вы его создаете сами.
Инстанс - это экземпляр класса. создаётся. как это ни удивительно, инстанцированием класса и последующим сохранением в БД с помощью метода save()

А в чем проблема? Просто при каждой авторизации инвалидируйте все предыдущие сессии.

github не нужен чтобы воспользоваться гитом. GIT вполне работает через ssh
https://githowto.com/ru
github - это всего лишь централлизованный сервис для хранения, публикации репозиториев и социальщины вокруг них. Все операции с репозиторием происходят с помощью программы git.
GIT - это распределенная система контроля версий. Каждый клон репозитория в ней равноправен по отношению к остальным.
Клонировать, отправлять и принимать изменения можно из любого в любой клон.
можно даже локально в одной файловой системе в соседних каталогах сделать клоны репозитория и переносить между ними коммиты.

django подойдёт.
С ним в комплекте вы получите админку, регистрацию, авторизацию.
Нетрудно найти готовые хорошие модули для джанго с чатом на веб-сокетах.
Есть готовые джанговские модули OAuth и всякие интеграции в соцсеточки.

Давайте различать. Шифрование пароля - это не то же самое, что шифрование других данных. Пароль следует не шифровать, а хешировать. Это такое шифрование, которое нельзя расшифровать обратно. То есть имея хеш нельзя получить пароль, а имея пароль можно получить точно такой же хеш. Существуют для этого специальные хеш функции. Но хешировать пароли мало, их нужно сперва солить. Соль - это произвольный текст, присоединённый к паролю перед хешированием и размещаемый рядом с хешем в открытом виде. Нужна соль для того, чтобы нельзя было подбирать простые пароли по значению их хешей.
Проверка пароля будет такой:
1. Запрашиваем у пользователя логин и пароль.
2. Достаём из БД по логину хеш солёного пароля.
3. С этой солью хешируем введённый пользователем при авторизации пароль и сличаем хеши. Совпали -- значит пускаем.

Шифрование других данных, очевидно, нужно уже обратимое, чтобы можно было расшифровать. И теперь есть два варианта: серверное и клиентское шифрование.

Серверное не имеет смысла, поскольку скомпрометированный сервер означает утечку всего необходимого для расшифровки данных. Не скомпрометированный сервер означает, что данные и так вроде бы в безопасности. Значит шифровать не нужно (ну кроме некоторых специальных случаев).

Клиентское шифрование - это когда сервер не имеет возможности расшифровать данные. Они шифруются на клиенте перед отправкой ключом, который не покидает пользовательского компьютера. Потом клиент снова запросит шифрованные данные с сервера и расшифрует его тоже сам. Это иногда имеет смысл. Например если вы храните keychain с паролями на сервере, но не хотите их утечки в случае взлома сервера.

Есть ещё p2p шифрование, где с помощью специального алгоритма пользователи обмениваются ключами через сервер так, чтобы эти ключи не мог узнать ни сервер, ни кто иной. Далее от пользователя к пользователю ходит через сервер шифрованная информация, которую кроме оконечных пользователей никто не может расшифровать. Это так называемое оконечное шифрование.

В итоге хранить шифрованные данные на сервере не нужно, поскольку всё что нужно для расшифровки тоже на этом сервере. Если кто-то туда влез, то он и ключи шифрования свистнет и данные перехватит после расшифровки или перед расшифровкой. Нет смысла прятать сиськи. если жопа голая.

О, чуть не забыл. Есть опасность утечки незашифрованных данных из датацентров при наличии физического доступа к жестким дискам. Чтобы обезопасить себя в этом смысле, можно применить прозрачное шифрование файловой системы. Работающая операционная система будет знать ключ для расшифровки данных, но отсоединённый диск становится без ключа бесполезным. Однако это малоэффективно, если украдут весь сервер вместе с дисками. Зато эффективно против восстановления жуликами данных, если диск сгорел, а его сисадмин выбросил не просверлив.

Ещё один аспект - это канал передачи. Нет смысла опасаться перехвата незашифрованных данных в канале передачи даже на последней миле провайдера клиента. Об этом заботится SSL когда правильно настроен HTTPS и сертификаты не скомпрометированы, а пользователь не подмахнул левый сертификат.

Если вы задаёте вопрос о необходимости шифрования, значит вам ничего сверх вышесказанного шифровать не нужно. Это усложнит систему, сделает её менее надёжной, более (как ни парадоксально) уязвимой и отнимет ресурсы процессора, памяти, не даст использовать или усложнит кэширование и прочие оптимизации.

Я бы одним SQL-запросом это сделал.

DELETE FROM my_history_table t 
WHERE t.id <= (
    SELECT t2.id
    FROM my_history_table t2 
    ORDER BY datetime_open DESC
    SKIP 20
    LIMIT 1
)

Диалект SQL подправить по вкусу.

Максимально обезопасить можно применив https+криптоключ сессии.
Клиент авторизуется на сервер по паролю пользователя. В ответ сервер присылает сессионный ключ, который клиент будет добавлять в ajax-запросы.
Чтобы не хранить текущий сессионный ключ клиента на сервере, можно просто шифровать время, IP и login клиента, идентификатор чата. По приходу сообщения расшифровываем эти данные и проверяем можно ли такому отдавать контент. Обновленный коиптоключ сессии можно присылать с каждым ответом от сервера. При просрачивании заставляем переавторизоваться или, скажем, явно запросить новый коиптоключ.