O Di

Поднимите ставку, он согласится, у вас козырь "самописный фреймворк". Наймите помощника, платите ему часть денег, разгружайте себя. Введите абонентку, раз в месяц опред. сумма денег от клиента будет поступать, (исправление ошибок, онлайн поддержка функционала и тд). Дання сумма позволит нанимать помощников с окладом, а это гарантия что они не кинут.

Можно подойти к проблеме просто: делать свою работу в посильном темпе. Неизбежно начнут накапливаться нерешенные задачи в очереди, клиент неизбежно заинтересуется, почему так много "висяков" в багтрекере. А вы ему в ответ собранную за последние неделю-месяц-год статистику: раньше обращений было столько-то, я успевал, а теперь их в N раз больше, а у меня все еще только две руки. И уже можно обоснованно и аргументированно поднимать вопрос о расширении команды и тому подобных вещах.

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

Создаешь новый инстанс, отключает диск на старом маунтишь к новому на старом диске в конфиге ссх разрешаешь ключи и потом обратно возвращаешь диск на старый сервер

По попе:

position relative
  width 100%
  height auto
  min-height 100%

Что делает этот код? Для чего все эти свойства?
Для чего вы и так блочным элементам даёте 100% ширину? Так как в данном коде width: 100% ну вообще не нужно!

По делу:
Учите наследование! % всегда берутся от родительского элемента. И если размер у родителя не указан, то и проценты не сработают!

У body родитель html, а у html окно браузера. Что бы растянуть body на 100%, нужно сначала html дать 100%, а потом body, а потом вашему #intro. Вот тогда #intro растянется на 100%.

html,
body,
#intro {
height: 100%;
}

Проще способ выглядит так:

#intro {
height: 100vh;
}

Ответ зависит главным образом от операционной системы.
Если она качественно поддерживает настройку ppi в широких пределах - конечно надо брать 4K.
И конечно, никто в здравом уме не будет использовать 4K-монитор при логическом разрешении, равном нативному физическому.
На текущий момент (насколько я знаю, но могу ошибаться) таких подходящих осей две - макось и win10.
Если используется что-то другое и не планируется в ближайшее время апгрейд - лучше сэкономить и купить 1440.

1) nginx-proxy
2) копируйте исходники в образ (в dockerfile), собирайте либо локально либо на CI-сервере эти образы и пушьте их в docker/distribution (либо платный docker-hub либо разверните свой, это с докером делается за минут 10).
3) Прямо в контейнере с PHP. Либо заведите отдельный контейнер для php-cli и зачедите отдельный контейнер для исходников, и через volumes_from расшарьте между ними. Вариант с cron на хосте тоже достоен существования, но это не ок в большинстве случаев.
4) обновлять базовый образ. А там уж как организуетесь.
5) Можно, смотрим пункт 2.
6) Вообще тут можно схитрить. Вы можете же хранить зависимости прямо в репозитории, в смысле коммитить вендоры. Но вы этого не делаете. На момент когда запускается docker build ваших образов, все зависимости уже должны поставиться. И для каждого из перечисленных вами средств разработки уже есть свой контейнер, готовый. Берем и юзаем.
7) как мы выяснили в пункте 6 - композера на проде быть не должно. вообще как, вы оттещенный образ со стэйджинга должны просто "мувать" на продакшен. В этом плане риски при релизе минимальны.
8) тут опять же по разному. Мне удобнее прямо из контейнера коннектиться например в sentry или graylog и скидывать туда логи. Ну или мы должны пихать логи в stdout/stderr контейнера и далее агрегировать их снаружи, тут так же есть куча вариантов.
9) все это отдельные контейнеры, все это вместе связывается башем и docker-compose. Все это разварачивается либо через docker-machine и CI либо просто через CI. Docker-machine будет "удобным" только с версии 0.7 или 0.8.

Гем whenever Вам поможет.