Add support for ipv6 addresses in dokploy

[agentHits]

What problem will this feature address?

Will solve the problem with connecting vps over ipv6 protocol, right now I can't connect my vps over ipv6 to dokploy

Describe the solution you'd like

Add support for ipv6 addresses so I can add nodes to dokploy using ipv6 - right now I only have ipv4 permission, my servers don't have ipv4, I have ipv6 access (and I want to connect dokploy to my vps using ipv6).

Describe alternatives you've considered

I wasn't looking for alternatives

Additional context

Will you send a PR to implement it?

No

[divaltor]

Related issue #2349 and PR Dokploy/website#59

[agentHits]

Installing Server Dependencies: ✅
SSH connection error: connect ENETUNREACH 2a03:6f00:a::c9e0:22 - Local (:::0) client-socket
Error: SSH connection error: connect ENETUNREACH 2a03:6f00:a::c9e0:22 - Local (:::0) ❌

I am completely unable to connect dokploy via ipv6 directly, although from console I connect locally (using proxy with ipv6 connection support) as my ISP doesn't support ipv6 connection by default, but via terminal client + socks5 proxy I can easily access my vps via ipv6.

Please fix Dokploy to work over ipv6 connection

[kedare]

This is not related to #2349, looks like a configuration issue on your side, I have proper reachability between my servers over IPv6 only, an can establish also SSH and web access via IPv6 only

[cgaspart]

Hello, same issue here.

[imdaveho]

@agentHits @cgaspart -- I had this issue, but was able to resolve a portion of this issue by ensuring that the dokploy server and remote deployment servers have enabled ipv6 and ip6tables in /etc/docker/daemon.json

Edit - my resolution is different from what you're looking at which I also hit which is setting up a remote deployment server with an IPv6 address. The daemon.json thing is just to address a more local issue which is simply routing between servers and containers to other ip6 address on an internal subnet, but not necessarily publicly.

@Siumauricio - related to the topic of ipv6 support, but did you know that postgres-js has an outstanding issue since 2023 regarding parsing IPv6 addresses incorrectly: porsager/postgres#663.

This is related to #919 and #92

1. Due to only using connection strings for postgres, we hit this issue with postgres-js. Whereas building the connection using host, user, database, etc. variables separately as an object seems to work OK since it avoids the flawed string parsing logic.

2. Splitting these variables makes multi-database and remote database support much more flexible since it wouldn't be tied to default assumptions. For instance, only having REDIS HOST defaults too much. What if someone wanted to protect their db with password, or define a different db index to use in a shared setting?

3. I think some SSL traffic encyption methods for postgres, at least, would benefit from the flexibility of more envvars rather than a single connection string.

4. I think this decouples you from a specific database driver/orm library since it seems that building the connection from objects are simply more reliable.

I'm thinking of making a PR, but might be low hanging fruit to folks how have more knowledge of the inner workings. I'll see what I can manage to do, but wanted to bring this to a few ppl's attention given some overlap between a few outstanding issues.