@DaAnalyst Not sure we recommend anywhere in the docs to have only Chrome containerized separately. In our own projects we never had it setup this way, instead we always had it bundled alongside an Elixir app in a single container. I’m aware the docs says something about running your PDF printing service separate from your “main app”, but that’s a different thing. Furthermore, unfortunately in newer Chrome versions the --remote-debugging-address option doesn’t allow binding to 0.0.0.0 anymore so you’d need to proxy traffic into the container before passing it to chrome, as suggested in this issue. So, to your “has there been progress” question: There has not and won’t be because we don’t really want to support it, and overall the “remote chrome” story won’t get any better.
To be completely honest, it also isn’t clear to me how this additional isolation of Chrome is helping security, in comparison to simply isolating the PDF printing service of your app. The attack vector would be that some user input in your templates compromises Chrome (= allows to escape its sandbox) and gives the attacker access to the container environment, but what additional impact does this have if you run a minimal Elixir app alongside Chrome there? Personally leaning strongly towards the simplicity of a “local chrome” setup over this vague security benefit.
