I have several dockers where I have specified that the docker get its own IP address. Is there any reason not to do this for every docker? Why futz around with port numbers where you are using stuff like 8888 and 8080, etc for web ports when you can just use the default port 80 on every docker with its own IP?

You can, but the consensus within the community is that it's bad practice.

9 minutes ago, MowMdown said:

but the consensus within the community is that it's bad practice.

That's the first I'm hearing of it. I'd like to know why? Most of my containers have their own IP on the br0 network, for security reasons, and no need to change ports. I don't enable host access to custom networks, so even if my container somehow has malicious code and tries to break out of the container, it can't reach the host.

its not bad practice, but it is more of an advanced setup with some caveats which new users struggle with...so users are generally steered away from it.

Aaah, he meant it that way.. Then I understand, I thought maybe I missed a memo or something.

There are some routers out in the wilderness that struggle with multiple V4 addresses coming from the same MAC.

So its better to play it safe and use only ONE address but multiple ports.

If you have port conflicts you may use a reverse proxy to allow different names to the services. The internal (unique) port number is then hidden behind the proxy and does not matter.

And it is even easier to remember "pihole.my-domain.tld" instead of an extra IP address.

6 minutes ago, MAM59 said:

There are some routers out in the wilderness that struggle with multiple V4 addresses coming from the same MAC.

Macvlan solves that, and the macvlan issues that were on the previous versions have been resolved. So if you need it, you can use macvlan. I've never had an issue with it.

9 minutes ago, MAM59 said:

If you have port conflicts you may use a reverse proxy to allow different names to the services. The internal (unique) port number is then hidden behind the proxy and does not matter.

You can't deploy a container if you have port conflicts; it won't let you. Even if you have a reverse proxy, you can't deploy a new container with port conflicts.

2 minutes ago, strike said:

Macvlan solves that, and the macvlan issues that were on the previous versions have been resolved. So if you need it, you can use macvlan. I've never had an issue with it.

Yeah I know, but why set something at risk? there is no benefit to gain from multiple docker-ips.

2 minutes ago, strike said:

You can't deploy a container if you have port conflicts; it won't let you. Even if you have a reverse proxy, you can't deploy a new container with port conflicts.

Yeah, my bad english... What I mean is that you can edit the port in the docker's setting to avoid conflicts between dockers.

So you can assign 8081 instead of 8080 and so on.

1 minute ago, MAM59 said:

there is no benefit to gain from multiple docker-ips.

There are a few, that's why I use it. Not for the IP's themselfs, but for other reasons. The only thing I use the IP for is ordering all my containers by them, so it's really easy for me to deploy a new container with a new IP. I just take the next IP in the list. My DHCP server is configured so I have plenty of IP's to choose from as they are outside the DHCP range.

12 minutes ago, MAM59 said:

Yeah, my bad english... What I mean is that you can edit the port in the docker's setting to avoid conflicts between dockers.

So you can assign 8081 instead of 8080 and so on.

Ok, yeah, I don't need to worry about that. That's one of the reasons I use a dedicated IP.

Maybe it's simpler for others and newcomers to go with the "default" setup, but funny enough, I think it makes it more complicated. But that may be because I'm so used to "my way" of doing things..

5 hours ago, strike said:

Aaah, he meant it that way.. Then I understand, I thought maybe I missed a memo or something.

For me personally, everything has individual IPs per container using custom networks via my configured vlans (out of the box unraid configs).

I couldn't imagine going back to the nightmare of managing port mapping conflicts, host shim network hacks, and lack of container name resolution... not to mention the overhead of an extra NAT layer.

any version will work. It just depends on personal taste and your will to stress your extended memory.

It maybe fine to spill a lot of IP addresses if your lan is small, but I already ran out of addresses in the normal /24 range and had to extend the range. With a few hundred hosts to remember you do not als want to remember "where is this function now?".

I prefer KISS (keep it simple (and) stupid)

1 hour ago, tjb_altf4 said:

I couldn't imagine going back to the nightmare of managing port mapping conflicts, host shim network hacks, and lack of container name resolution... not to mention the overhead of an extra NAT layer.

True that!

58 minutes ago, MAM59 said:

It just depends on personal taste

Yeah, I guess it does.

12 hours ago, MAM59 said:

Yeah I know, but why set something at risk? there is no benefit to gain from multiple docker-ips.

Yeah, my bad english... What I mean is that you can edit the port in the docker's setting to avoid conflicts between dockers.

So you can assign 8081 instead of 8080 and so on.

But the nice thing about giving each device its own IP address is that you can just use port 80 for the web UI and don't have to futz around with port numbers when typing in URLs.

9 hours ago, tjb_altf4 said:

For me personally, everything has individual IPs per container using custom networks via my configured vlans (out of the box unraid configs).

I couldn't imagine going back to the nightmare of managing port mapping conflicts, host shim network hacks, and lack of container name resolution... not to mention the overhead of an extra NAT layer.

Can you go into more detail on how you setup the configured vlans? Thanks.

49 minutes ago, wayner said:

port 80 for the web UI and don't have to futz around with port numbers when typing in URLs.

I never futz around with port numbers, I use NPM as a reverse proxy and access those services by name. Only NPM "knows" the real port number, to the outside it is always port 80 or 443.

Why should I fill my precious brain with some numbers???

6 hours ago, wayner said:

Can you go into more detail on how you setup the configured vlans? Thanks.

Once your network (outside of Unraid) is setup for vlans, you can add them to the network settings in Unraid per NIC, then you add them to network setting on the Docker service settings page.

The network config will change depending on your network equipment, which needs to be vlan capable, but for the Unraid side its as below.
Taking an example vlan of my "servers" on Network settings page, which creates the br1.20 (interface-or-bridge-name dot vlan-id) :
note that I've masked some elements of my network config


Docker service settings page (service needs to be stopped to change), vlan configured in settings


this is how a container is configured in template, if you don't specify fixed address it uses your configured DHCP pool from Dockers page (docker doesn't use router DHCP)


and subsequent container instance:

On 12/31/2025 at 10:08 PM, strike said:

Aaah, he meant it that way.. Then I understand, I thought maybe I missed a memo or something.

Yes by "bad practice" I meant strongly discouraged. It's known to be problematic for users and that whole macvlan issue that came about just left a bad impression.

Port conflicts are easy enough to avoid either by changing ports or using docker network create <network_name> and assigning containers that need to share a connetion to the custom docker network if you need to re-use multiples of the same container (like a db container)

It's rare that you cant avoid a port collision this way. In fact the only port you're going to have trouble with is port 53.

1 hour ago, MowMdown said:

In fact the only port you're going to have trouble with is port 53

not really anymore. (but little known to the public and not often used too)

Althow 53 is still standard for DNS, modern resolvers can be configured to use any port with the ..#port syntax

for

"

port=value

This keyword changes the default TCP/UDP name server port

to value from its default, port 53. The abbreviation for

this keyword is po.

"

root@F:~# nslookup

> set port=5353

> server 192.168.0.3

Default server: 192.168.0.3

Address: 192.168.0.3#5353

>

37 minutes ago, MAM59 said:

not really anymore. (but little known to the public and not often used too)

Althow 53 is still standard for DNS, modern resolvers can be configured to use any port with the ..#port syntax

for

"

port=value

This keyword changes the default TCP/UDP name server port

to value from its default, port 53. The abbreviation for

this keyword is po.

"

root@F:~# nslookup

> set port=5353

> server 192.168.0.3

Default server: 192.168.0.3

Address: 192.168.0.3#5353

>

I was just thinking about how unraid uses port 53 as part of the VM Manager/QEMU process which means that if you wanted to run something like pihole on port 53 on unraid you'd have to likely put pihole on br0 to be able to accept dns on that port.

9 hours ago, MowMdown said:

I was just thinking about how unraid uses port 53 as part of the VM Manager/QEMU process which means that if you wanted to run something like pihole on port 53 on unraid

Running pihole ON UNRAID is possible, running it FOR UNRAID is always a bad idea because it will not be available at boot time when it is already needed.

So it makes no difference if you run in on a seperate IP or on a bridge, it simply will not work.

UNRAIDs DNS settings must always point "elsewhere" outside the box. Also, UNRAID does not need any adfilter, it will hardly be used for browsing around because you cannot store any URLs/users/passwords. After every reboot they will be gone, this does not really attrack people :-)

9 hours ago, MAM59 said:

Running pihole ON UNRAID is possible, running it FOR UNRAID is always a bad idea because it will not be available at boot time when it is already needed.

So it makes no difference if you run in on a seperate IP or on a bridge, it simply will not work.

UNRAIDs DNS settings must always point "elsewhere" outside the box. Also, UNRAID does not need any adfilter, it will hardly be used for browsing around because you cannot store any URLs/users/passwords. After every reboot they will be gone, this does not really attrack people :-)

I only meant running ON unraid.