I think you need to consider what Docker is really for. It's use cases are largely consistent local environments for developers to avoid the "it worked on my laptop" problem and a mechanism for running server applications in a relatively hermetic and repeatable manner for enterprises running web services. It can be used as a way to distribute software to consumers for them to run on their own computers, but that isn't really what it was meant for. It's a fair way to deal with server-side software that can be optionally self-hosted but is still a real server with arbitrarily many clients making requests across a network, but I would argue it isn't for software that is absolutely meant to and has to be run on the client and has no true server component. It sounds here like you artificially separated into client and server to potentially run this as a centralized service and then thought the better of it. If there is no reason to have a separate client and server, then don't. If every single user is going to run both their own client and their own server, then you don't have a distributed application. You have a single piece of software that is running as two for no good reason. I would suggest re-working to have a single executable and distribute it using the native packaging formats for your target platforms. That means dmg or pkg for Mac, msi for Windows, deb and rpm for the most popular Linuxes, etc. An Electron app is fine. I'm not saying you need to learn the native platform APIs and GUI frameworks for each major OS, but at least use the native packaging formats. If your users are going to be using Windows and Mac especially, which would seemingly be the case for musicians, giving them software that only runs on Linux and requires them to spin up a virtual machine to run Docker Desktop is particularly shitty.