Enable IPv6 support for web UI

[tlstpierre]

Is this a feature relevant to companion itself, and not a module?

• I believe this to be a feature for companion, not a module

Is there an existing issue for this?

• I have searched the existing issues

Describe the feature

Companion should either by default, or with a simple option, bind listening sockets to IPv6 as well as IPv4. This is easily accomplished by using "::" instead of "0.0.0.0" anywhere a bind IP address is used. Currently companion cannot be accessed over IPv6 even when the host is IPv6 enabled.

Usecases

Because IPv4 is obsolete!

No really, but here's some more concrete use cases:

• Allowing Companion to function on an IPv6 only host (this is actually a thing, and this is how I found this issue).
• Allowing Companion to be directly reachable from remote sites without inbound NAT rules, or on Internet connections that no longer provide public IPv4 addresses. This is the case in many networks in many parts of the world. Even when private IPv4 addresses are configured on the network for device control, the lack of a public IPv4 address prevents remote access. Listening on IPv6 would allow remote access (suitably firewalled) across the Internet.
• Allowing Satellite on an IPv6 only host to access a dual-stack Companion instance. We don't need to turn off IPv4, we just need to allow incoming IPv6 connections.
• IPv6 is the default protocol on many operating systems, so if a hostname is used to connect to the Companion instance on dual-stack host, the connection will fail because the IPv6 address is being used, but Companion is only listening on IPv4.

This is a fairly simple change and would be equivalent to setting --admin-address :: on the CLI at run-time. I have tested this behaviour on Linux and it solved the IPv6 issues and did not negatively affect IPv4 (IPv4 clients were still able to connect).

Branch feature/ipv6 was created to explore this. I may be able to make the changes myself with a little guidance.

[timstpierre-tc]

Thanks for putting this on the list!

Something that this might need also, is a change to the regex patterns that allow IP addresses to be entered in the UI. These should be modified to allow IPv6 notation also, anywhere an IP address is specified.

[Julusian]

Something that this might need also, is a change to the regex patterns that allow IP addresses to be entered in the UI. These should be modified to allow IPv6 notation also, anywhere an IP address is specified.

I would be open to adding a new IPv6 regex, and potentially a combined IPvBoth regex, but I am not sure if the existing one should be changed.
Many modules will be assuming that they will get an ipv4 address, and so will error/crash or worse if they are given an invalid address.
For example, the generic-tcp-udp module and even the UDPHelper class we provide for modules to use, binds to udp4, on the provided address.

Some more work probably needs to be put into what we can do to encourage modules to support ipv6, which is a similar track to previous discussions about encouraging them to access hostnames as well as ip addresses. I don't remember much progress being made on the hostname track though

[endreszabo]

Had the same issue with my IPv6-mostly setup. As a temporary q&d workaround, one can add the IPv6 wildcard address to the launch.sh this way:

#!/bin/bash

if [ -d /usr/local/src/companion ]; then
    cd /usr/local/src/companion

    if [ -f "UPDATE_IN_PROGRESS" ]; then
        echo "Companion can not be started, an update operation was interrupted."
        exit 5
    fi

    # run it!
-    /opt/fnm/aliases/default/bin/node headless_ip.js 0.0.0.0
+    /opt/fnm/aliases/default/bin/node headless_ip.js ::
else
    # run it!
    cd /opt/companion

    # node binary path could be different since v3.5
    NODE_EXE=/opt/companion/node-runtime/bin/node
    if ! [ -d /opt/companion/node-runtime ]; then
        NODE_EXE=/opt/companion/node-runtimes/main/bin/node
    fi

-    $NODE_EXE /opt/companion/main.js --extra-module-path /opt/companion-module-dev
+    $NODE_EXE /opt/companion/main.js --extra-module-path /opt/companion-module-dev --admin-address ::
fi

Of course, the same could be carried out with Docker entrypoint as well.

[timstpierre-tc]

I'm doing something very similar on my headless Raspberry Pi installation. In my case, it is an IPv6-only host, but it solves the issue nicely, and so far, most modules that take hostnames seem to work fine. I think we should just merge these changes into the base code. I

…

On Fri, 7 Nov 2025 at 06:44, Endre Szabo ***@***.***> wrote: *endreszabo* left a comment (bitfocus/companion#2711) <#2711 (comment)> Had the same issue with my IPv6-mostly setup. As a temporary q&d workaround, one can add the IPv6 wildcard address to the launch.sh this way: #!/bin/bash if [ -d /usr/local/src/companion ]; then cd /usr/local/src/companion if [ -f "UPDATE_IN_PROGRESS" ]; then echo "Companion can not be started, an update operation was interrupted." exit 5 fi # run it!- /opt/fnm/aliases/default/bin/node headless_ip.js 0.0.0.0+ /opt/fnm/aliases/default/bin/node headless_ip.js :: else # run it! cd /opt/companion # node binary path could be different since v3.5 NODE_EXE=/opt/companion/node-runtime/bin/node if ! [ -d /opt/companion/node-runtime ]; then NODE_EXE=/opt/companion/node-runtimes/main/bin/node fi - $NODE_EXE /opt/companion/main.js --extra-module-path /opt/companion-module-dev+ $NODE_EXE /opt/companion/main.js --extra-module-path /opt/companion-module-dev --admin-address :: fi Of course, the same could be carried out with Docker entrypoint as well. — Reply to this email directly, view it on GitHub <#2711 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/A2NYZ6NNMXYQEHBFY4TA3YD33SA3NAVCNFSM6AAAAACLN5NMIKVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZTKMBSGA4TANRUGM> . You are receiving this because you commented.Message ID: ***@***.***>

[endreszabo]

Well, good for you, here I've got an annoyingly lot of embedded IPv4-only devices Companion needs to reach. Maybe access could work via NAT64, but that extra hop to the NAT64 gateway would be another SPoF anyway.