Ahh! D'oh; I should've figured they were saved in the render file... Good stuff, removing them then saving has stopped the zombies reappearing - my LP collection is safe. Thanks!

3 sounds good news ))). Re, 7 - yep, as least I mean this weirdness in the control panel; when I hit Connect, I see three copies of my server (I confess to finding the 'nodes requiring IP address' a bit confusing as well, but that's by the by): If I hit OK, then one of them will in fact connect, leaving two greyed-out 'zombies' in the machine list: To be honest, I assumed (without much evidence) the zombies were probably there from some of my abortive attempts to get things working (it took me a few iterations of Blender versions/plugin/container etc. to get everything working - that's why I wrote the guide), and that maybe some of my 'broken' versions were still registered wherever the matchmaking happens. Everything else with that connected/synced node works fine, though, so this is more a cosmetic than functional issue now.

Thanks again for the update, I made most of the edits this morning - I'll update to 2.83 once I've done the upgrade myself this weekend (alas, the day job gets in the way) but in the meantime added a note that the newer version is available. I should say thanks again for the image, and indeed to all the CR folks. Without this I pretty much wouldn't be able to use Blender for anything useful at all (my desktop machine is a lowly MacMini with integrated graphics) - so I really do appreciate.

Cool, thanks for the feedback! I will make edits in the morning :-). A few responses: 1. Argh, but good of course... Will try and upgrade in due course :). In the meantime, I'm glad I wrote to use the :bl.2.82_cu_10 tag and not :nvidia ;-). 2. Noted. Actually, if anyone followed my instructions from part one they don't need either, so it's a bit belt-and-braces anyway. I'll amend when I update it. 3. Unfortunately, while this is true, the errors that had me tearing my hair out weren't in the container logs (i.e. weren't coming from the startup script.) After stratup, it's pretty much silent, hence having to dig into the container image to find the actual logs in /root/cr/logging. It would be nice if the runtime logs were also output to stdout for container logging. 4. To be honest, I'm just glad someone else has experienced this bug - it was driving me to question my sanity. 5. Uhuh, noted - I'll update the post to explain this as well. 6. Personal habit/policy - anything long-lived on this machine should be managed by Kubernetes (indeed, if I ever get round to a Part 3 it'll be the helm chart I write to do this). Running directly with "docker run" comes under the heading of quick hack (in the nicest sense of the word - I mean that includes most of my CI build jobs), so I like to clean up after as much as possible :-). 7. Good to know - although is there some CR server component in the matchmaking (as it were?) (And if not, then any ideas why I have two zombie instances for the same server in my connection list..?) I should say when I was writing the post, the CR site was down, meaning I was having to go entirely on my notes and couldn't actually double-check anything - so that comment was born out of tangible frustration :-D. I'll update to include that (and remove the -rm accordingly...) Thanks very much - will post an updated version tomorrow, much appreciated.

Hi, thanks for the positive feedback; and many many thanks @zocker1600 for the Docker image :). And sure, happy to offer anything I can do to help. Cheers!