I can't quite determine if you're asking because your app already does this (which would be ideal), or because you might need this, before your app can do more of what you would like it to accomplish :\

I would want either one.

I already stream media continuously for LAN background music, not only self-hosted but from bare metal using VLC in Windows or Linux. Opening a single port on the router (like 8080, as seen in the nice docs you do have) for simple straightforward port forwarding when I want it to be accessible from the web. Not WebRTC, still just ordinary HTTP which plays in client browsers that support the codec. For a while now. The clients behave and access the stream from any browser no different than what you've shown when you use port forwarding. I add latency so it buffers OK and barely glitches for clients.

Once VLC is installed, when it launches it uses a static config file containing your global & user settings.

The entire procedure consists of the following:

1. Take a blank SSD and install Windows or Linux.

2. Plug in the USB drive containing the media content and preferred playlist.

3. Install the currently-proven version of VLC desktop, the Android version does not stream.

4. Copy my own specific config file and "launch string" to the proper folders. From floppy if necessary, I'm using some pretty old computers sometimes ;) It's just a couple kilobytes of text anyway.

5. Double-click on the launch string then sit back and listen to the music from any browser on the LAN.

6. (Optional) Log into the router and click the checkbox to enable the port forwarding when you want the stream to be accessible from the web.

Maybe you should massage your system and docs so you can end up with a 1, 2, 3 . . . 6-step demo as simplified as this or more so.

If something can not easily run locally on just plain bare metal, it never built much confidence that it's going to work in VMs or fancier approaches than that. If something is only proven to work in VMs or containers I'm even more skeptical of trying bare metal. I need the installation and streaming part to be a familiar clickety-click routine for non-college musicians, so the whole "OS/software" thing needs to be (or act like) a completely finished product. So the artists can concentrate on their media USBs and have hours of fun with that complexity alone, which is plenty.

How about something analogous to substituting the name of your app where it says "VLC" above?

Plus looks like you elegantly don't require port forwarding, so the optional step 6 web access would probably be a checkbox in your own app.

Done.

If you had it like this I would have bench tested it already.

Even when I wrote my own code I'm fine with spending 10x as much time testing. Still validate for a year before deployment, even if it's only music and not an exacting industrial effort.

OTOH with ridiculously scattered docs for VLC, many from message boards and versions from previous decades not exactly consistent with the latest, it was still possible to quickly determine a direct path to a simple 6-step process, if I could ever figure out the details. Mainly because this is one of the things that VLC was designed to do from the ground up. Just click--install and click--run once you've got everything else set up. Sure it took dozens of hours of experimentation & discovery to get everything right before it was this easy for what I wanted. But I could see every step to do and gradually kept making milestones. Plus fortunately, experimentation & discovery-R-us ;)

I think you are at a similar point where the app works and the capabilities are so numerous you would have to now focus on a narrow path to a single useful goal to come up with the simplest, most reliable demo.

I just do not have what I would need to outline my particular path with your app yet. And I do have some real-world experience for decades, and remain highly motivated.

Heck, why should I need to experiment so much now, you're the engineer and you're right here. Who better to pioneer a "foolproof" path?

Do it and I would try to be testing WebRTC within hours, and probably a number of others would try it with success if it looked so easy too :)

If you don't offer DNS/LetsEncrypt yet, that could always be added later, and when you were done with that it could just be another checkbox(s) on your dashboard, which naturally edits the config file.