Алексей

Если используете Докер и прямо хотите докеризировать с мастабированием, то используйте сеть докера для связи между контейнерами для начала.
У вас должно быть 1 контейнер с nginx наружу (80 порт и/или 443), 1 контейнер для сборки приложения VueJS, 1 контейнер для работы с PHP-проектом и дальше что там у вас, по контейнеру для СУБД (1 Redis, 1 RabbitMQ, 1 MySQL). Каждому контейнеру дайте нормальное уникальное имя, чтобы можно было их подключать друг к другу по dns-имени. Наружу порт только для nginx давайте, он будет за все отвечать.
1. Контейнер с nginx отдает статику, собранную из приложения VueJS. Собственно все как обычно - собрали dist, из него и отдаете. В идеале собирать в отдельном контейнере c NodeJS, а полученные данные из dist копировать в какой-нибудь volume наверное и подключить его к контейнеру с Nginx. Это можно делать на уровне файлов docker-compose и автоматизировать при сборке проекта. Этот же volume можно подключить и к контейнеру с backend-api, тогда оно сможет работать с файлами, которые загрузили.
2. Из первого контейнера с nginx по upstream отдавать backend-api, который будет обращаться к еще одному контейнеру, где крутится PHP и собственно ваш symphony проект. Наружу этот контейнер не пускайте, подключайте к первому контейнеру через имя. Таким образом вы сможете запустить несколько контейнеров с api, указав все их dns-имена в разделе нужного upstream. Уже получаете горизонтальную масштабируемость, эти контейнеры потом можно запускать вообще на разных серверах, соединив их, например при помощи Docker Swarm или в Kubernetes. Опять же все можно оформить на уровне файлов конфигурации Docker Compose, там не сложно, достаточно почитать документацию.
3. Все контейнеры с СУБД запускайте тоже в отдельных контейнерах, где нужно - создавайте volume для хранения БД. Их тоже наружу не пускайте, биндите на уровне Docker с контейнером (ами) с backend-api. Вообще если предполагается серьезная нагрузка, то СУБД вообще рекомендуют запускать не в контейнерах, но тогда чуть сложнее автоматизировать привязку и масштабирование будет. Для начала можно и в контейнерах, когда она придет, эта нагрузка то... Тем более контенеры с СУБД тоже можно в нескольких экземплярах запускать, между ними репликацию сделать или вообще шардинг. Все это можно наверное во всех описанных БД сделать, но с шардингом помучаться конечно придется. Репликация проще всего. А уже к ним подключаться из backend-api по dns-именам, как настроите.

Как то так.

1. Вам следует уточнить у вашего провайдера, открывается ли он порты для динамического IP. То есть дает он белый IP или нет. К примеру, МГТС не позволяет снаружи по IP доступ получить к роутеру. Хоть как ты настраивай. Есть те, которые не блочат вообще или блочат распространенные порты типа 25. Есть те, которые такую услуг предоставляют отдельно, обычно совмещая с услугой "Постоянный выделеный IP"
2. Если статический постоянный IP не дается, пробуйте последовательно различные сервисы DDNS. Возможно у вас на роутере даже есть встроенная подключалка, ту и используйте. Такие как NoIP, DynDNS и другие можно настроить в большинстве домашних роутера. В этом случае вместо IP будете использовать некое dns-имя.
3. Пробрасывайте порты нужные внутрь сети с роутера. Проще всего зафискировать постоянный внутренний IP девайсу, по MAC-адресу например. И тогда Port Forward или Port Trigger на роутере настраивается несколькими кликами мышки.

Скажем так, это не является обязательным, но приветствуется.
Вы бесплатно получаете вполне неплохой инструмент, почему бы хотя бы указанием движка не отблагодарить? Впрочем на бесплатном плане Unity Personal там и так вначале показывается их логотип, поэтому необязательно еще и в титрах. Разве что вы уж очень им благодарны :)
Есть движки, где это даже забесплатно не требуется и никак не ограничивается разработчиками.

1. Визуальное программирование в Unity есть. Причем не только в таком виде, как Bolt (это подобие Blueprints и его прямо вот на днях сделали бесплатным), но можно еще приобрести Playmaker или разнообразные конструкторы игр в AssetStore. Видел там несколько скромных, но вполне годных, из которых несложную игру в виде прототипа собрать можно вообще без программирования. Но, есть НО - все эти средства визуального программирования ПОКА что не являются частью самой Unity. Нет такой полноценной интеграции как в случае Blueprints в UE 4. Поэтому рано или поздно программировать придется, скорее всего.
2. Если ваш ПК не тянет Unreal Engine - не парьтесь. Просто возьмите и начните делать прототип на Unity. Если в процессе разработки поймете, что Unity вас чем то не устраивает - как раз к тому времени и комп проапгрейдите и попробуете Unreal Engine или вообще другой движок, например Godot или Unigine (кто знает кто знает).
3. Вопросы оптимизации решать придется и там и там. В некоторых моментах Unity выигрывает у Unreal, в некоторых наоборот. Сильно зависит от самой игры конечно.
ЗЫ: у меня сложилось стойкое мнение, которые регулярно подтверждается другими авторами статей, докладов и видеороликов с Youtube (да, не истина в последней инстанции, но все же) - на Unity легко начать, проще чем на UE сделать нетребовательную игру без большого бюджета, но при этом сделать что-то "вау" будет на Unity гораздо сложнее, чем на UE. Это работает и в обратную сторону - сделать что-то простое на UE может быть гораздо сложнее, чем на Unity.

По умолчанию Docker for Windows использует Hyper-V. Если вы уже пользуетесь вагрантом, то он наверное там работает через VirtualBox ?
Если да - то при активации Hyper-V скорее всего VirtualBox может начать глючить (если вообще не перестанет работать). Может и не начнет. Я кстати не уверен, что в LTSB можно активировать Hyper-V без проблем...
При желании Docker можно заставить работать без Hyper-V, то есть на VirtualBox. Наверное можно через Docker Toolbox, он для этого и позиционируется, но у меня ни разу не получилось (особо не пытался, если честно).
В обоих случаях Docker в Windows на самом деле запускает виртуальную машину с линуксом, где и происходит потом вся эта докер-"магия". Так что да, подсистема Linux не нужна.

Поднимайте что-то на базе любого движка Вики (MediaWiki, DokuWiki или другое что-то) и храните все там. Удобно.

Visual Studio Community Edition, NetBeans, Eclipse...

Существуют. В Википедии почитайте, есть целая статья про Локализацию программного обеспечения. Иногда называют l10n.
Чаще всего встречал локализацию через файлы .po - достаточно универсальный вариант и для него есть и онлайн и оффлайн редакторы.