It works great.
I might misunderstand, but to me it looks like the solution in this post might be better than my setup because if that single node is down I won't be able to reach the fenced router.
Even in this case, you still need to have a node somewhere to run the container and store the WireGuard keys, to be able to link the tailnet and the WireGuard endpoint. So that single point of failure still unfortunately remains.
The benefit of having it all configured in a single container means it's pretty easy to spin up anywhere (where the fenced router is accessible), all you need is the tunnel config file.
I also wanted to make sure it works for both IPv4 and IPv6 connections, because many ISPs in my area are starting to only give public IPv6 addresses. That way as long as the WireGuard router has IPv6 and the node running the container has IPv4/IPv6 dual stack, one can still access the Wireguard from an IPv4 only device.
It will also by default route traffic to the already advertised other subnets in the tailnet, but taking that into use requires a bit of manual configuration on the other end of the WireGuard tunnel. Each subnet needs to be routed through the WireGuard tunnel first to make it work.
Managing the advertised subnets manually is a bit of a pain, while the downsides of accidentally advertising a subnet are negligible, since you still have full control over them in the Tailscale console.