HTTP-only GitLab CE: CI submodule checkout blocked by GCM

GitLab CI/CD
,
1

Problem to solve

Our self-managed GitLab CE instance runs on a private LAN. All projects, including submodules, are hosted on the same GitLab. CI/CD jobs fail when fetching submodules over HTTP because credentials are blocked and prompts are disabled. Requiring HTTPS even for same-host, private submodules effectively breaks CI for us unless we re-architect everything to HTTPS or SSH.

I am looking for guidance or a supported configuration that allows CI to fetch same-host submodules over HTTP using CI_JOB_TOKEN, or an official way to relax the restriction for internal-only traffic. Alternatively, clear documentation stating that HTTPS (or SSH) is a hard requirement for submodules in CI would help us plan.

Describe your question in as much detail as possible

What I see:

  • Submodule checkout during CI fails with messages like:

    fatal: Unencrypted HTTP is not recommended for GitLab. Ensure the repository remote URL is using HTTPS or see https://aka.ms/gcm/unsaferemotes about how to allow unsafe remotes.
fatal: could not read Username for 'http://<gitlab-host>': terminal prompts disabled

  • This happens even though the submodule lives on the same GitLab and same network.

What I expect:

  • Since both the superproject and submodules are on the same self-hosted GitLab in a private network, CI should be able to authenticate submodule fetches automatically (e.g., via CI_JOB_TOKEN), regardless of HTTP vs HTTPS, or there should be a supported opt-in to permit HTTP for same-host submodules in CI.

Impact:

  • Our pipelines cannot run (on never versions of runners) unless we migrate all submodule URLs to HTTPS or SSH. For historical and operational reasons, our internal repos have used HTTP. Enforcing HTTPS immediately across many internal repos and tools is non-trivial.

Questions:

  1. Is there a supported way for CI to fetch same-host submodules over HTTP with CI_JOB_TOKEN, without interactive prompts and without weakening global security for all users?

  2. If HTTPS is mandatory for submodules in CI, can the documentation explicitly say so for self-managed environments, and suggest migration steps?

  3. Are relative submodule URLs intended to solve this (keeping developer choice while CI resolves to HTTPS automatically), or is that only supported with HTTPS enabled on the server?

Steps to reproduce

  1. Self-managed GitLab CE on a private network. Only HTTP is enabled.

  2. Superproject contains submodules with HTTP URLs pointing to the same GitLab.
    Example .gitmodules:

    [submodule "external/LibA"]
  path = external/LibA
  url  = http://gitlab.local/group/LibA.git

CI job with GIT_SUBMODULE_STRATEGY: recursive runs on a shell runner (Windows or Linux).

Troubleshooting tried:

  • Using CI hooks to rewrite URLs to HTTPS. Works only if HTTPS is enabled on the server.

  • Disabling credential helper and embedding tokens in URLs. This is brittle and discouraged.

  • Switching submodules to SSH. Works, but requires runner keys, deploy keys, and developer reconfiguration.

  • Using relative URLs. Works when the server has HTTPS and the runner is configured to force HTTPS, but that still implies enabling HTTPS.

Server is self-managed GitLab CE behind a private LAN IP. No public access. HTTPS not enabled.

Applies to:

  • Self-managed: YES
  • SaaS: NO
  • Dedicated: NO
  • Self-hosted Runners: YES

Versions

  • GitLab 18.3.2 - run in container
  • GitLab Runner, if self-hosted (Web /admin/runners or CLI gitlab-runner --version):
    Version: 18.3.1
    Git revision: 5a021a1c
    Git branch: 18-3-stable
    GO version: go1.24.4 X:cacheprog
    Built: 2025-09-04T15:24:16Z
    OS/Arch: windows/amd64