This was fun to figure out the ARM template syntax. The main cool thing (and main attraction) about Azure, was the ability to use

Microsoft.Insights/components, Microsoft.Insights/actionGroups, Microsoft.Insights/metricAlerts

to actually send an email with the login link once deployment completes. I've added BrowserBox to many other cloud platforms' (Vultr, AWS, Linode) 1-click-deploy methods, but Azure is the only one (that I know) that can send this email.

Basically we use a bash script on the VM extension to run the install, and then use the Metrics API to write a metric datapoint, which triggers the email for the alert defined elsewhere in the ARM template.

I love the convenience of this! Install can take a while (particularly with the secure document viewer for PDFs, DOCX, etc because of all the fonts that need to be installed), and getting an email with the link that you can click on is just so easy.

If anyone's wondering the license, it's completely free and unencumbered to just use for personal/noncommercial/research use in anyway even modified, and also available under AGPL-3.0 if you want to modify source and use commercially for free under AGPL-3.0. If you'd rather just modify into a proprietary code base and integrate into a commercial system without releasing your own code under AGPL-3.0-or-later then we do offer a range of commercial licenses with a simple per-seat pricing module that discounts at high volume significantly. We also offer support, maintenance, customization, training and consulting.

This links to the Azure ARM quickstart for the main open-source version of BrowserBox. Just click the "Deploy to Azure" or "Deploy to AzureGov" links to give it a spin on your own account. I've made the setup as easy as possible.

We currently don't collect any telemetry at all (not even installs, but it can be inferred from various sources like GitHub clones, Docker pulls, etc ~ it's around 60 per day currently). We don't guarantee what's collected or not by Chrome headless, any dependent packages (we try to be pretty lean but it does run use npm so there's always risk, we use socket.dev to monitor any risks and aim to fix any vulnerable deps as soon as we see them), or the cloud platform or ISP you run on tho. We support tor both as a hidden service and a way to connect to the net, but it's tor-slow especially the latter. To run any of the tor switches you'll need to manually install.

Overall the main OSS version should work fairly solidly across browsers and devices (let me know at issues@dosyago.com if it doesn't!), but the important thing to remember is that everything can be customized, from the look, and chrome UI, to how it's embedded (in an iframe widget on your app, for instance, to default full-page), all the way down to the minutae of how the viewport is streamed over WebRTC and the audio chunks are streamed over websocket. If you want to dig into a fairly high performance, secure and reliable real-time app with real-world use cases, that out of the box supports many OSes (macOS, Ubuntu, Fedora, RHEL, CentOS, Debian, Kali, etc etc...even Windows but we insist you use the PSGallery installer if you are running on Windows: https://www.powershellgallery.com/packages/BrowserBox-Instal...), then definitely dig into the code!

It's open source on GitHub currently: https://github.com/BrowserBox/BrowserBox

Oh, and one final thing -- pick a low ping Azure region for your deployment! Ping is very important to give a great experience. The lower your ping, the less dependent everything is on your link bandwidth.

Let me know how it goes! :)