Исходя из вашего вопроса - "деплой" это разворот сервера с нуля до рабочего состояния.

Все зависит от количества деплоев:
1. Если вам достаточно задеплоить 1 сервак и забыть про него - проще поднять руками.
2. Если вы постоянно разворачиваете > 2 серваков - однозначно надо использовать автоматизированные инструменты.

Рассмотрим несколько популярных инструментов:
1. Ansible - на мой взгляд самый удобный инструмент для быстрой и удобноый работы с парком серверов, устанавливает весь софт и настройки на вашей VPS.
2. Docker - позволяет создать на вашей VPS еще одну виртуальную машину с заранее прописанными настройками и софтом, также его иногда используют для параллельного запуска нескольких БД / веб - серверов и т.д.
3. Также есть Puppet, Chef, Salt - ими не пользовался.

Рассмотрим другое толкование слова "деплой" - заливка изменений проекта на сервер, который находится в рабочем состоянии (т.е. имеется уже рабочий проект)

Тут все зависит от размеров проекта:
1. Если проект маленький / средний fabric вполне справляется с такими задачами, как подтянуть изменения из репозитория / собрать статику / перезагрузить nginx и т.д., но использовать его для разворота сервера - это тяжелая работа, которую проще делать с помощью других инструментов (описано выше). Сам я тоже использую fabric для обновления прода.
2. Если проект большой и приближается к хайлоаду - то надо использовать Continuous Integration, это позволит вам сделать автоматизированную выкладку кода на боевой сервер - к примеру, пушите коммиты в репозиторий на github, срабатывает хук, начинает работать Jenkins, идет прогон тестов, при успехе тестов обновляется прод.

Инструментов для CI много:
1. Jenkins - простой и бесплатный, с кучей расширений и прочих плюшек.
2. Travis-CI - бесплатный для опен сорс, платный для приватных проектов (69$ минимальный план).
3. Buildbot, tox - не использовал.

P.S. Я думаю, что понятие "деплой" - это выкладка изменений на боевой сервер. То, что делаете вы - создаете новый сервер, разворачиваете окружение - ближе к развороту сервера. Если так делается каждый раз, когда льются изменения на боевой сервак - надо менять workflow.

Тут нет оптимального варианта - надо смотреть на бэкэнд и фронтенд совокупно.
Далее, считаем что фронтенд SPA, бэкэнд чистое API.

Если выбор за Cookies:

1. На сервере необходимо реализовать защиту от CSRF
   
2. На фронте также надо будет реализовать обвязку под передачу CSRF-токена
   
3. Вся авторизация будет обрабатываться бэкэндом - т.е. он ставит куку через Set-Cookie с httpOnly и secure и сам же читает из куки для аутентификации / авторизации
   
4. Фронтенд не имеет доступа к кукам - не думает об авторизации и об XSS
   
5. Обычно, XSS используют чтобы украсть авторизационный токен через JS - если авторизационная кука httpOnly - нет доступа к кукам через JS, нет проблем
   

Если выбор за localStorage:

1. Не надо делать CSRF защиту на сервере - нет кук, нет проблем
   
2. Экранировать потенциально опасные данные бэкэндом на входе - обеспечит дополнительную защиту от XSS при рендере данных
   
3. Надо делать защиту от XSS на фронте, т.е. экранирование данных при рендере - чтобы потенциально вредоносный JS код превращался в строку, а не вставлялся в DOM
   
4. На фронте надо сделать обвязку под сохранение / передачу / валидацию токена
   
5. Всегда остается человеческий фактор - забыли сделать экранирование при рендере на фронте, JS код имеет доступ к токену и он утек
   

Могу посоветовать использовать фреймворки, как на бэкэ, так и на фронте - они обычно имеют уже реализованную защиту от основных типов атак. Мы на проекте юзаем localStorage и React, ну и верим в лучшее :)

Конечно, нет - это абсолютно разные базы, у которых разное применение.
ClickHouse - OLAP (подходит для аналитики на больших массивах неизменяемых данных)
MySQL - OLTP (подходит для нормализованных таблиц с изменяемыми данными)
Вот версус.