Is IPv6 support not enabled?

[kquinsland]

It appears to be hard-coded here but I wanted to ask if there was some env-var somewhere that I was not seeing or a way to change this?

[SchrodingersGat]

That is not "hard coded" - you can pass in any address to listen on. So, you could pass in an IPv6 address if you like, and the Gunicorn server will listen on that address

[kquinsland]

That is not "hard coded" - you can pass in any address to listen on. So, you could pass in an IPv6 address if you like, and the Gunicorn server will listen on that address

Yes, I know what the code is allowing for. My question is weather or not there's an idiomatic way to do this without writing my own entry point wrapper or otherwise building out my own container image.

It appears possible to do this in "dev" mode but the the bind address and port are hard coded in in production mode.

Furthemore, the INVENTREE_WEB_ADDR and INVENTREE_WEB_PORT variables do not show up where the rest of the env-vars are documented which is why I am asking my question using the phrasing i did.

It sounds like the answer is "no, there is no affordance to the user for this but the cheapest way to get there is to use the off-the-shelf-container with a custom command that mimics the stock CMD:

❯ podman history --no-trunc --format '{{.CreatedBy}}' inventree:latest | grep CMD
CMD ["sh" "-c" "exec gunicorn -c ./gunicorn.conf.py InvenTree.wsgi -b 0.0.0.0:8000 --chdir ${INVENTREE_BACKEND_DIR}/InvenTree"]

[SchrodingersGat]

@kquinsland we could adapt the standard docker image such that the entrypoint listens on both IPv4 and IPv6 addresses.

I think that changing -b 0.0.0.0:8000 to -b '[::]:8000' should be sufficient here.

Perhaps you could test this out (by running your image with a custom entrypoint command). If it works we can look at adjusting our default image to support both address types

[kquinsland]

I think that changing -b 0.0.0.0:8000 to -b '[::]:8000' should be sufficient here.

That would work as expected on ~98% of systems, I think.
It is possible to configure a socket for IPV6_V6ONLY only which would mean that the [::] does not also allow traffic from v4 space. I have seen this only a handful of times in the past decade but it's always a pain to track down why.

Perhaps you could test this out (by running your image with a custom entrypoint command). If it works we can look at adjusting our default image to support both address types

Have been all day since getting it up and running in my cluster :).

Caddy log full of:

fd02::4ce:8fa8:7b8e:3012 - - [23/Nov/2025:21:07:58 -0800] "GET /api/notifications/?read=false&limit=1 HTTP/1.1" 200 52 "https://inventree.test.clusters.lab/web/part/category/index/parts" "Mozilla/5.0 (X11; Linux x86_64; rv:145.0) Gecko/20100101 Firefox/145.0"   

I PR'd a simple change to allow this to be configurable if you know where to look (or maybe add a Web Server Settings section?). Kept the default of 0.0.0.0 to err on the side of caution w/r/t that once-every-few-years IPV6_V6ONLY chance.

#10900