Gitea git provider fails after the authorize application stage [Self hosted] on Private Network

[unleashit]

To Reproduce

Note that I'm using self hosted Gitea on the same server as Dokploy.

1. Start a new Gitea provider under Git Providers
2. In Gitea add a new application with the callback hook and save.
3. Enter the url, client id and secret In Dokploy then click "configure Gitea app"
4. Browser tab opens up with the Authorize screen:

5. Click "Authorize Application:"
6. Get Internal server error
7. See in Gitea that the authorization came through but a problem happened after calling the web hook
8. Try to connect again or test connection from Dokploy, same thing

Current vs. Expected behavior

Can't complete the process to connect with Gitea. Provider saves, but cannot be accessed when creating services.

Provide environment information

Ubuntu 24.04 amd64
Dokploy version 0.21.0
VPS yes
Applications: setting up a Gitea git provider

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

Docker

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

Same server where Dokploy is installed

Additional context

Getting this error in Dokploy logs:

TypeError: fetch failed
at async c (.next/server/pages/api/providers/gitea/callback.js:1:1436)
at async n (.next/server/pages/api/providers/gitea/callback.js:1:2190) {
[cause]: Error: connect ECONNREFUSED 127.0.0.1:9999
at <unknown> (Error: connect ECONNREFUSED 127.0.0.1:9999) {
errno: -111,
code: 'ECONNREFUSED',
syscall: 'connect',
address: '127.0.0.1',
port: 9999
}

Currently, I don't have port 9999 exposed to the internet on this server so I'm using an SSH local port forward

As a hostname for Gitea I tried both localhost and 127.0.0.1 and neither work. I also tried unselecting (after selecting didn't work) "confidential client" in Gitea.

Will you send a PR to fix it?

No

[jrparks]

Hello,

Your SSH local port forward (ssh -L 9999:localhost:3000 user@server) is only available on your local machine (the one running the SSH command).

If Dokploy is running on the server, it has no awareness of your local machine's forwarded port.

When Next.js (inside Dokploy) tries to reach 127.0.0.1:9999, it looks inside its own container, not on your local machine.

Solutions Option 1: Use the Remote Server’s IP in Dokploy Instead of pointing to 127.0.0.1:9999, use your server’s real IP where Gitea is running.

Option 2: Run the SSH Tunnel Inside Dokploy If you must use SSH tunneling, you’d have to set up the SSH tunnel inside your Dokploy container, which is inconvenient. This would require modifying your Dokploy deployment to establish the tunnel before starting the Next.js server.

Option 3: Expose Gitea Properly A more stable approach is to allow your Dokploy container to reach Gitea directly by:

Binding Gitea to 0.0.0.0 in app.ini so it's accessible remotely.

Adding firewall rules to allow access only from your Dokploy container.

Debugging Steps Run curl http://127.0.0.1:9999 inside your Dokploy container (dokploy ssh if available). If it fails, Dokploy cannot see the tunnel. Check if you have a firewall blocking you as well.

If you want to test the public IP approach, try curl http://your-server-ip:3000 inside Dokploy. If that works, switch your config to use that.

Let me know how it goes!

[unleashit]

Hey, thanks for trying to help. A couple of things I could have probably been more clear on:

• I'm tunneling port 9999 to my local machine for the purposes of managing Gitea's GUI, but Gitea is exposed to the host which Dokploy is running on. Possible I'm wrong but I don't think the fact that I'm tunneling in just to make changes in Gitea changes things in this case. Dokploy doesn't need to know about that or the tunnel, it just needs to make a request to Gitea which is running at localhost:9999.
• Dokploy itself is exposed to the internet as https

I actually ended up trying your option 1, where I temp exposed 9999 and used the IP... but that didn't work either. I saw some stuff about the credentials not matching, which I triple checked (and redid the whole process multiple times).

Run curl http://127.0.0.1:9999/ inside your Dokploy container (dokploy ssh if available).

Already did this and it works fine.

A more stable approach is to allow your Dokploy container to reach Gitea directly by: Binding Gitea to 0.0.0.0 in app.ini so it's accessible remotely.

My preference is not to expose Gitea to the internet. TBH I don't need to access the Gitea GUI much, and the tunneling has been working fine, but I may end up switching to tail/head scale.

It's certainly not impossible that I have some sort of configuration issue on my end, but I don't see how Dokploy can't contact the Gitea instance. Although this being Oauth, maybe there are more complex security measures involved?

[jrparks]

Personally I like having my Dokploy install running in my internal network and remote servers setup where the apps get installed to that are internet facing. Regardless what does it say when you try using the curl command with the host IP and proper port? If it resolves then you are in business. It would be easier to help diagnose if I saw some error info posted.

[unleashit]

Hmm, just realized you're right in that localhost isn't going to work. I'm getting back to docker after a couple of years... For that you'd use host.docker.internal or http://gitea-app:9999. That should work for the request, but it can't work for redirecting the browser to the auth path. So theoretically at least, it could could be possible if there were separate fields for the fetch request to confirm auth and the redirect for the user to authorize in the browser...

Yeah, that's a good idea really. I thought of doing that, but I don't have much of an internal network at this point lol. Definitely a cool feature of Dokploy.

Regardless what does it say when you try using the curl command with the host IP and proper port? If it resolves then you are in business. It would be easier to help diagnose if I saw some error info posted.

It's late, but tomorrow I'll follow up with the actual error. I was able to connect with Gitea view the ip:port.

[jrparks]

Sounds good. One other thing, make sure you have updated your Gitea version. That is also important as older versions may not be compatible. My local version is 1.23.5

[unleashit]

Did it. I managed to make it work by first connecting as http://localhost:9999, letting it launch a browser tab with the Authorization screen, but going back to Dokploy and changing the gitea url to http://gitea:3000, saving, and then going back to the tab and authorizing.

Aside from that, I was doing a couple of things wrong: 1. gitea wasn't in dokploy-network so I had to add it for dokploy to find it (I forgot that I deployed it separate from dokploy) and 2. I needed the gitea internal port 3000 and not the exposed to the host 9999.

Having said that, while its possible to achieve I think it could be made more easier with the suggestion I made earlier: provide a new field for Gitea Url that is only used on the first step to redirect the browser. I see that the other providers don't do this either, so it might be more of an issue for @Siumauricio to decide if he wants to support. While it's possible to get a local (and not internet exposed) provider working... it takes some hacking around to get it done.

I'm still not sure why it didn't work when I tried IP:port the other day and haven't tested again since I got it to work locally. I can try it again if you like, or we can wait and see if anyone else ends up having the problem.

[unleashit]

Spoke too soon. When I tested at first, I didn't go as far as deploying. It does connect within the service, list out the repos, and shows the right branches. Everything seems good, but then in the logs when deploying:

Initializing deployment
Cloning Repo <redacted> to /etc/dokploy/compose/calibre-web-calibre-web-xxxxxx/code...
Cloning into '/etc/dokploy/compose/calibre-web-calibre-web-xxxxxx/code'...
fatal: unable to access 'https://gitea:3000/unleashit/<redacted>.git/': gnutls_handshake() failed: An unexpected TLS packet was received.
ERROR Clonning: Error: Cloning into '/etc/dokploy/compose/calibre-web-calibre-web-xxxxx/code'...
fatal: unable to access 'https://gitea:3000/unleashit/<redacted>/': gnutls_handshake() failed: An unexpected TLS packet was received.

It looks like https might be hard coded somewhere. The gitea url set in the provider settings uses http.

[unleashit]

Not sure if this can safely be protocol optional, but I found this in the source code:

	const baseUrl = gitea?.giteaUrl.replace(/^https?:\/\//, "");
	const repoClone = `${giteaOwner}/${giteaRepository}.git`;
	const cloneUrl = `https://oauth2:${gitea?.accessToken}@${baseUrl}/${repoClone}`;

` https://github.com/Dokploy/dokploy/blob/canary/packages/server/src/utils/providers/gitea.ts#L150C1-L152C82

That would explain why it won't work for an http git provider.

[jrparks]

I would hate to see someone use it internet facing without a cert as everything is exposed. I think the better approach is to use a reverse proxy and enable ssl and you can pass through to your backend over http. In Dokploy, Traefik is the reverse proxy, you can do that in the domain section of you service, you will need a domain and then can enable lets encrypt. Alternatively I could add in better error checking and a warning if the user is using an insecure protocol and simply allow it. Lets see what some others say before I make a change. In the mean time you have a path forward.

[unleashit]

I agree that caution is very important, as a large majority of the time you do want https. And this only affects self hosted. That said, not giving the user the choice I believe is a mistake. It's legitimate to use http when nothing is exposed to the internet. These days, more and more people are doing this via VPNs like Tailscale, Cloudflare tunnels, etc.

That said, I think if there are changes, some type of warning to the user should be added with insecure URLs. Also, the setup would need a separate field (perhaps an advanced configuration), where the user can enter docker and not docker urls. Also, IMHO, if changing Gitea it would make sense to do at least the Gitlab provider as well... and I've noticed there are a couple of other things like the "view repository" button that would need to be fixed.

I was able to make it work for me and I almost started a PR, but then realized its somewhat involved and might end up getting rejected.

[jrparks]

Its interesting because I saw a review on Dokploy and they roasted the project because it wasn't secure out of the box, I think that was on Hostinger. Anyways open a PR and I will do a fix on it. Just be very detailed in what you are thinking. I agree we should probably do the same to gitlab as well then. We can make some sort of visible warning on the provider so they no it's not secure. Provide more details on the view repository issue as well.

[unleashit]

What were their gripes? One thing I noticed in the install script there's a chmod 777 /etc/dokploy. But then after finishing, the perms seem fine. I wish it would take env vars for the default admin user like some projects, as that would avoid having an initial (most likely) insecure create admin account page.

If you can think of reason why what I'm suggesting is insecure for users who do the right prep, please say. In my scenario, the http://localhost:port gets called to authorize. This port is not exposed to the internet and transmitted remotely via a secure SSH tunnel. Then when a project is configured or deployed, the server would be calling something like http://gitea:port locally only on the host. Of course all of this does depend on the user knowing what they're doing.

I'd be happy to do that, unless you want to wait and see if we can get @Siumauricio's opinion?

[Siumauricio]

I know it is a very specific case but it probably has to be taken into consideration, if you consider that the fix can be simple, I'm happy to check a PR

[unleashit]

That's great. I have a few things going on right now, but I'll start a PR hopefully within the next week or so. This is definitely an important fix for me to be able to continue with Dokploy, although I'm sure some others will also run into it if left as-is.

One caveat about this, is the new UI for the field in the the provider settings won't be useful for cloud version. But if that's ok, I think we can label is so no one's confused.

[unleashit]

Just added a PR #1718. @jrparks I ended up just doing it, hope you don't mind. Certainly if you want to take a look and give any/all opinions that'd be helpful! As I noted over there, I still need to test it with Dokploy running as a container.

[vitonsky]

I have this problem too.

@Siumauricio @unleashit what the root cause you figured out in #1718 ?

Do you have any ideas about fix?

[Siumauricio]

I know dokploy doesn't deal well with this kind of internal private git provider issues, I currently don't have time for this kind of issues, initially I didn't design it to be used for internal git providers,

however if you are interested in fixing this behaviour I can accept a PR to fix this problem.

@jrparks @vitonsky @unleashit

[brneor]

I have the same (or very similar) issue but with my GitLab instance. Both GitLab and Dokploy are running on servers on the same internal network. I get to the authorization page but when I'm redirected I see an "Internal Server Error".

In Dokploy container logs I see this as soon as I click "Authorize"

TypeError: fetch failed
    at async p (.next/server/pages/api/providers/gitlab/callback.js:1:2519) {
  [cause]: [Error: unable to verify the first certificate] {
    code: 'UNABLE_TO_VERIFY_LEAF_SIGNATURE'
  }
}
 ⨯ TypeError: fetch failed
    at async p (.next/server/pages/api/providers/gitlab/callback.js:1:2519) {
  [cause]: [Error: unable to verify the first certificate] {
    code: 'UNABLE_TO_VERIFY_LEAF_SIGNATURE'
  }
}

and I don't know what this means.