In the container help pages and in various posts/videos, VETH is always shown in a new "containers"/"dockers"/etc bridge. e.g. some variant of... Maybe someone knows the logic/rational... I've always just used them in either a vlan-filtering=yes bridge, or as a "standalone"/non-bridged interface & never seen a problem.

But keep seeing the same VETH+bridge pattern, even in newer container examples/video... that has me thinking I'm missing something. But if you followed Mikrotik docs for all the example containers, you end up a half-dozen different bridge interfaces which seems silly/unnecessary for some network service...

Since I'm NOT following the docs, I worry maybe there are some corner cases that require a bridge for VETH that I just been lucky not to see?

Did you forget this corner case?

LOL. Sure, but that involves a VETH in bridge! It really the standalone case that puzzles me - not a single example in docs/YT/etc do this.

I would also like an official answer to this one, I often run standalone containers, is there a underlaying technical reason the veth needs to be in a bridge?

The plot thickens here...

In v7.12beta3, I noticed they added MACVLAN as interface. Now I got even more questions — since I have no idea why that be needed on RouterOS's containers...

e.g. it VETH is already an ethernet-like interface, so it can be used like an ethernet everywhere & the "docker host" is already a router, with all the standalone/bridging/tagging/untagging things you'd want to do with VETH alone.

I suspect MT is using "MACVLAN" in the Linux sense, not in the Docker sense. If I'm right, the purpose of the new feature is to provide VLAN tag prefiltering of the traffic coming into that port for attachment to another service that can't do it on its own. Now, that might be a container, or it might be something else; I imagine you could say "VLAN 50 goes out untagged to {my favorite L2 VPN tech}" with this so that the remote end of that L2 VPN conn doesn't have to care about VLAN 50.