Git clone uses external URL instead of internal URL when OAuth2 provider has internal URL configured, causing Authelia redirect error

[impcyber]

To Reproduce

1. Set up a Forgejo instance behind Authelia (or any OAuth2/OIDC proxy) with:

   • External URL: https://git.example.com (protected by Authelia)
   • Internal URL: http://forgejo:3000 (direct container-to-container communication)

2. In Dokploy, add Forgejo as a Git provider via OAuth2:

   • External URL: https://git.example.com
   • Internal URL: http://forgejo:3000

3. Create a project and application, selecting the connected Forgejo repository as the source.

4. Trigger a deployment.

5. Check the deployment logs.

Current vs. Expected behavior

Current behavior:
The deployment fails with the following error in logs:

fatal: unable to update url base from redirection:
asked for: https://oauth2:<token>@git.example.com/projects/infra.git/info/refs?service=git-upload-pack
redirect: https://auth.example.com/?rd=https%3A%2F%2Fgit.example.com%2Fprojects%2Finfra.git%2Finfo%2Frefs%3Fservice%3Dgit-upload-pack&rm=GET

Expected behavior:
Since internalUrl (http://forgejo:3000) is configured for this provider, the git clone operation should use the internal URL instead of the external URL, bypassing Authelia and preventing the redirect error.

Provide environment information

OS: Debian 13
Arch: arm64
Dokploy version: 0.28.8
VPS Provider: Timeweb
What applications/services are you tying to deploy?
 Vaultwarden

Which area(s) are affected? (Select all that apply)

Docker Compose

Are you deploying the applications where Dokploy is installed or on a remote server?

Same server where Dokploy is installed

Additional context

The issue occurs because the git clone operation currently uses the external URL even when internalUrl is configured.

This was previously addressed in #3914 for API calls (e.g., testing connection, fetching repositories, branches). However, the PR notes explicitly mention that git clone helpers were intentionally left using the external URL:

The git clone helper functions (cloneGiteaRepository, getGitlabRepoClone/getGitlabCloneUrl) still use the external URL. This is likely intentional since git clone commands can be dispatched to remote worker machines where the internal URL would not be reachable, but it does create an asymmetry.

In my setup:

Dokploy, Forgejo, and Authelia are all running on the same Docker host in the same network.

http://forgejo:3000 is accessible from the Dokploy container.

The external URL https://git.example.com is protected by Authelia, which returns a redirect when accessed without a session, breaking the clone operation.

A possible solution would be to extend the internal URL prioritization to git clone operations when the clone is performed on the same host (or when the internal URL is reachable). Alternatively, adding a configuration option to force internal URL for clone operations would resolve this use case.

Will you send a PR to fix it?

No

[dosubot]

Hi @impcyber! I'm Dosu and I’m helping the dokploy team.

Your analysis is spot on. This is a confirmed gap in PR #3914 - git clone operations were intentionally excluded from the internal URL fix, creating the asymmetry you've identified.

Root cause: The cloneGiteaRepository function passes giteaProvider.giteaUrl (external) to buildGiteaCloneUrl, while all API functions now use (giteaInternalUrl || giteaUrl).

The fix would be minimal - updating cloneGiteaRepository to follow the same pattern:

const cloneUrl = buildGiteaCloneUrl(
    giteaProvider.giteaInternalUrl || giteaProvider.giteaUrl,  // Use internal URL when available
    giteaProvider.accessToken!,
    giteaOwner!,
    giteaRepository!,
);

This is consistent with how PR #3914 handled API calls and would resolve your Authelia redirect issue when running everything on the same Docker network.

Related issues: #3900, #1591, and #3848 document similar internal URL handling gaps across Gitea and GitLab providers.

Workaround: Currently there's no configuration option for this. The cleanest workaround would be configuring Authelia bypass rules for the git clone paths, though that adds complexity.

To reply, just mention @dosu.

---

^{How did I do? Good | Irrelevant | Incorrect | Verbose | Hallucination | Report 🐛 | Other}

   

[impcyber]

@dosu here is PR #4067

[dosubot]

Thanks for submitting PR #4067! The fix looks correct - changing buildGiteaCloneUrl to use giteaProvider.giteaInternalUrl || giteaProvider.giteaUrl on line 173 follows the exact pattern established by PR #3914 for API calls.

This will allow git clone operations to use the internal URL (http://forgejo:3000) when configured, bypassing Authelia and resolving the redirect error you reported.

To reply, just mention @dosu.

---

^{How did I do? Good | Irrelevant | Incorrect | Verbose | Hallucination | Report 🐛 | Other}