external_url на то и называется external, чтобы сказать GitLab'у каким он будет выглядеть во внешнем мире уже за пределами внутренних сетей и прокси-серверов. Смысл в том, что на прокси-сервер должен приходить HTTPS, расшифровываться там (терминация TLS), и уже на GitLab попадать в виде HTTP. Но при этом конечный пользователь всегда работает с HTTPS.
*Type в Go вполне себе идиоматично для выражения опциональности (честные enum'ы, а с ними и Optional, не завезли), что хорошо ложится на undefined случай.sql.NullInt вполне себе идиоматично и правильно для работы с NULL в БД, что хорошо ложится на null случай.
Scan на sql.NullInt значения. Для того их и ввели, чтобы работать с NULL'ями в БД. А будет оно nil или нет - решаете Вы, скармливая его в Scan, или нет. Это получится именно то, что Вы хотели - если у Вас nil, то Вы не работаете с полем в запросе, если у Вас sql.NullInt.Valid == false, то драйвер БД будет работать со значением как NULL в БД, во всех остальных случая идёт работа с самим значением.undefined не является валидным JSON типом. То есть Вам нужно здесь либо менять формат сериализации и отказываясь от undefined (например, просто не включая подобные поля в JSON), либо писать кастомный анмаршалинг руками.
*sql.NullInt?
fastcgi_param SCRIPT_FILENAME $document_root$fastcgi_script_name;
Писать костыли с подобными динамическими апдейтами конфига со стороны Ops, вместо того, чтобы привести в порядок сам код со стороны Dev - это попытка забивать гвозди, извините, дилдаком. У Вас потом столько гемора будет, начиная с того, что решение не будет работать бесшовно, и пока конфиг одуплится - часть запросов уже будет поломана, и заканчивая невозможностью выкрутить opcache на максимальные настройки кеширования (если конфиг в PHP файлах, к примеру). Задачу лучше решать на том уровне, где она должна быть нормально решена.