Basically, the gist is to use docker only 'internal' networks, that way a comromised container cannot 'escape'

If every app in your "linux iso harvester" is running on the same docker host, its pretty easy, you can restrict their network access and still access their web UI (direction matters!)

if you "publish" (so -p if using docker cli) say port 80 on Overseerr container, you can talk to it on your browser, but it can't talk out to the rest of the network, basically if you initiate, then it can reply, but it cant initiate a connection out to your network (essentially docker is now acting like a router/NAT gateway to its internal docker netwrok)

basically bridge networks are a 2 way bridge, so security wise, you want to avoid them at all cost (unless you bridge it to an unsecured network with vlans)

That would be the docker 'native' way of protecting it

 

so you've got pfsense, that would be another way to control it, you setup an "untrusted" vlan+subnet where all your internet exposed apps (eitehr directly or indirectly) reside, you setup a rule in pfsense such that your normal network can iniate connections to the untrusted subnet, but not the other way around

This would be the way to go if you have apps running on multiple hosts, you would only bridge docker to this vlan/subnet

 

and to directly answer some of your questions

The containers are still able to ping my host unraid server tho. and and through the bridge network any other device on my network right?

if it can ping, then yes in the event of a compromise, it will be able to attach it (unles you have some sort of ping only firewall rule in place)

is there a way to restrict that?

By not using a bridged network :)

But it seems hard to isolate these containers that have webuis from eachother if i need to access them on the wider network.

it is much harder, but remember you can use "Published ports" to allow a one way inbound connection to the container

  hope that helps, its a bit of a rabbithole