Small feedback after my first self-hosted production deployment

[garfield50]

Hi everyone,

First of all, I'd like to say thank you for the work you're doing on Breeze RMM.

I've just completed my first self-hosted deployment and I honestly think the project is very promising. As an MSP, I've been using Tactical RMM for quite some time, and after only a few days of testing Breeze, I'm already seriously considering moving my production environment to it in the future.

That's probably the best compliment I can give. 😊

My technician workstation is running Windows 11 Pro (French) and I access Breeze using Microsoft Edge.

While testing, I came across a few small things that I wanted to share. None of them are blockers—they're just little details that I thought might help improve the overall experience.

1. French (AZERTY) keyboard layout in the Remote Viewer

The Remote Viewer behaves as if the keyboard layout is QWERTY, even though:

my workstation is Windows 11 Pro (French / AZERTY)
the remote computer is also Windows 11 (French / AZERTY)

For example:

Typing:

azerty

results in:

qwerty

I looked through the Viewer settings but couldn't find an option to select the keyboard layout or force a French (AZERTY) keyboard.

Maybe I simply missed it, but if not, having either automatic detection or a manual keyboard selection would be really helpful.

2. Better information during Remote Access troubleshooting

When I was configuring Remote Access, the Viewer sometimes remained on:

Reconnecting...

Eventually I found that my issue was related to the TURN/WebRTC configuration.

What made troubleshooting difficult was that I wasn't sure what part of the connection was actually failing.

If the Viewer could expose a little more information (ICE state, TURN usage, connection method, etc.), it would probably make troubleshooting much easier for users deploying Breeze for the first time.

3. Reverse proxy deployment

My setup is:

pfSense
Nginx Proxy Manager
Breeze (with the internal Caddy)

I found the documentation to be very good overall.

Since this architecture is probably quite common for self-hosted MSPs, I think a dedicated guide for this type of deployment could be very useful.

Something bringing together reverse proxy configuration, TURN, required ports and a few common troubleshooting tips would probably save newcomers a lot of time.

4. First production setup

The installation process went well overall.

One small thing I noticed is that, during my first deployment, I only discovered a few missing production settings after trying to start the containers.

This wasn't a big problem—I simply corrected them one by one—but I wondered if, in the future, some kind of configuration validation or setup checklist before the first start could make the onboarding experience even smoother for new users.

Just a thought based on my own experience.

5. Europe/Paris timezone

When creating a new Organization, I couldn't find the Europe/Paris timezone.

Maybe I overlooked it, but if it isn't currently available, it would be nice to have the standard IANA timezone available for French users.

Final thoughts

These are honestly just small observations after my first deployment.

Overall, I'm genuinely impressed with Breeze RMM.

The project already feels very polished, and it's exciting to see how quickly it's evolving.

I'm really looking forward to following its development, and if everything continues in the same direction, I can absolutely see myself replacing Tactical RMM with Breeze in my production environment.

Thank you again for all the work you're putting into this project. It's refreshing to see such an ambitious open-source RMM solution, and I can't wait to see what's coming next!

[ToddHebebrand]

Thank you for this — first-deployment reports from working MSPs are the most valuable feedback we get, and coming from a Tactical production user makes it doubly useful. Point by point:

1. AZERTY in the Remote Viewer — confirmed real, root-caused, and answered in detail on your #2590: the viewer sends physical key positions (always QWERTY-labeled) and the agent injects them from hardcoded QWERTY tables, so layouts are never consulted on either end. A manual session-level layout selector is the accepted fix; #2590 is the tracker.

2. Connection diagnostics during "Reconnecting…" — fair gap. The information exists internally (ICE candidate types, whether TURN was relayed, which leg failed) and surfacing it in the viewer would have saved you the TURN debugging you did blind. Noted as a real enhancement for the viewer.

3. Reverse-proxy deployment guide (pfSense + NPM + internal Caddy) — agreed this architecture is common enough to deserve a dedicated page covering the proxy config, TURN, required ports, and the usual failure modes. Docs task noted.

4. Config validation before first start — partially exists and heading your way: the API already refuses to boot in production when certain required settings are missing, and that validator has been growing with each release. A comprehensive pre-flight (validate the whole .env before containers start, with actionable messages) is the right end state.

5. Europe/Paris timezone — you didn't overlook it; it's a bug. The site/org creation dropdown is a hardcoded 10-entry list that skips Europe/Paris, while the partner-level settings use a different list that includes it. Filed as #2856 with the fix scoped (use the full IANA set). Thanks for the precise report.

And genuinely — thanks for the kind words. The Tactical-to-Breeze migration path is exactly the user we build for, so if you keep notes during your production evaluation, keep them coming.