Евгений Хлебников

гитлаб указан в тегах верно?
поместите эти параметры в CICD переменные (поддерживаются в том числе файлы, а так же маскировка секретов), лимитировав их использование конкретным ENV-ом
https://docs.gitlab.com/ci/environments/
ну и укажите в деплой шагах ENV-ы (можно брать из имени бранча динамически)
хранить в репе все таки не стоит

к серваку не будет доступа по ssh в рабочем режиме

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

Опять же вызывает вопросы "закрытость" контура: закрыт он от доступа извне или доступ наружу изнутри контура тоже отсутствует? Как тогда предполагается доставлять изменения?

Как правило я локальные репы переношу проще:
1. создаем пустую репу на гитхостинге
2. клонируемся с пустой репы
3. копируем из локальной репы в заклонированную с хостинга все файлы
4. адд, коммит, пуш
забываем про старое место хранения локальной репы и продолжаем жить в новой, связанной с хостингом