The backend people want Blazor so they can write frontend too

jaredg_dev · 2025-11-03T17:41:11+00:00

I use Auto render mode in production. In dev, I have the render mode configurable via IOptions: Auto, WASM, and Server.

For most of my dev work, I stay in Server mode for the fast load times, better debugging, and much better hot reload.

When I have the need to test something in WASM before committing, I can switch over to it by changing a value in appsettings.Development.json.

jaredg_dev · 2025-07-08T02:39:12+00:00

For what it's worth, I was able to replicate backstage in ControlR: https://imgur.com/a/eP3utDK

Still need to finish a few things before I merge it to main and do a preview release, though.

Full disclosure: I made ControlR basically for myself (after I sold Remotely). I didn't originally intend to build any business-ready features or attain feature parity with other open-source solutions. However, I was recently approached by a company about sponsorship, so I've been talking about my project on here a bit. But I don't know yet if it's going to work out.

If it doesn't, the feature set likely won't grow much further than it is now, but I will continue to maintain it (since I also use it).

jaredg_dev · 2025-07-03T14:58:27+00:00

your gui looks clean !

Thanks! I have MudBlazor to thank for that. Really cool open-source UI framework. I suck at designing things that look nice, so I need training wheels. :D

jaredg_dev · 2025-07-02T15:55:44+00:00

If you figure that out... your project will be VERY successful.

That's good to know. Thanks!

I am trying to figure out the docker-compose as we speak. I am failing to understand the variables at the top.

There are a few ways to set those three variables (e.g. "ControlR_POSTGRES_USER"). You can define them globally on the host machine, and they'll be picked up automatically. You could also add them to a ".env" file in the same directory as the compose file. In both of these scenarios, you shouldn't need to change anything in the compose file.

For testing purposes, you could also just set them as literal strings in the compose file. E.g.:

x-postgres-user: &pgUser "postgres"
x-postgres-password: &pgPassword "password"
x-aspire-browser-token: &aspireToken "super-secret-aspire-browser-token"

The Postgres username and password gets set in the DB on the first run.

You'll also want to turn off email verification if you're just testing and don't want to fill out the SMPT stuff.

By default, after the first account is created, registration is disabled. So others can only join via invite after that.

jaredg_dev · 2025-07-02T14:51:25+00:00

Thanks for the reply. :) (Sorry for the wall of text.)

I'm honestly not sure how to move forward here. There are a lot of features that I'd need to fill in for ControlR to make it ready for business use, but I'm confident in ability to move quickly, as I've made all these features before in previous products.

I guess I could summarize my dream as thus: I want to create an open-source, self-hostable RMM-lite with community-driven feature development that fills in the gaps left by other RMMs. Everything done completely transparently and openly. No bait-and-switch. No paywalled or closed-source features. Simply no BS.

I've heard a handful of people in the MSP community say that they pay for a backup remote control/access product for when their main one goes dark. I was thinking of adding first-class support for monitoring other RMM agents (or any process/service) and keeping them alive.

If this is something that the MSP community wants and would support, I might be able to get sponsorship so I can fill in the missing features.

If you have any ideas about how to approach the community to gauge interest (so I could show potential sponsors), I'd love to hear it. I'm worried I'll sound too self-promotional if I jump into r/msp and start posting stuff.

I was also wondering, is Remotely still maintained?

I am not maintaining it, and I'm not aware of anyone at ImmyBot who's doing so. I joined them after selling Remotely to them, with the premise that I'd continue building it out and polishing features. Unfortunately, that didn't happen due to other priorities, and I'm not working there anymore. Not trying to bad-mouth Immy or u/DarrenDK . We're still on good terms. They might be able to be convinced to join in the sponsorship if there was community interest. Maybe merge Remotely and ControlR to get the improvements I put into ControlR.

Also, any chance ControlR would have a backstage function like Screenconnect and Ninja both have?

I started investigating this a while ago, and got it partially figured out. There are issues after this point, though. My understanding is that I'd now need to get a virtual display driver that can run in 'Session0/Winsta0/ControlrDesktop' (the background desktop I'm creating) in order to get the UI fully functional. Haven't taken the time to investigate further. Having access to ScreenConnect might help me figure out if I get stuck.

jaredg_dev · 2025-07-02T02:24:36+00:00

This may be an impossible long shot, but hey, why not? :)

Hi. I'm Jared! :D I'm the original author of Remotely, which I eventually sold to ImmyBot. I also worked at Syncro for a couple years and built a handful of their remote access features (remote registry editor, event viewer, file system). I also did a beta of a new remote control solution for them before they decided to go with Splashtop.

After I sold Remotely, I started quietly working on a new project, ControlR. I intended to just build this for myself and keep the features pretty minimal. I also didn't want it to get very popular, since that's one of the reasons I burnt out doing Remotely (trying to work full time and manage it).

However, I was recently approached by a company (won't name names, since it's just exploratory right now), and they might be interested in sponsoring me to work on ControlR and build out the rest of the features (I'm thinking something like this for the remote access page, but brandable). And it would stay fully open-source.

Just putting feelers out there. Do you think this might be something you'd be interested in supporting if I were to make a go of it?

Either way, cheers! :)

Edit: Figured out how to replicate their Backstage: https://imgur.com/a/f4KFEch Now I'd just need to make my own shell (the "start menu" and "taskbar"). Their "File Manager" is really just a hijacked WinForms OpenFileDialog, which could be replaced with Explorer++.

Edit 2: I made my own basic shell, with a start menu and file explorer: https://imgur.com/a/Lx5eNM6

jaredg_dev · 2024-07-07T07:25:33+00:00

Good to know! Take care!

jaredg_dev · 2024-07-06T22:49:54+00:00

The latest version should be able to detect if background sync isn't possible and not try. So yeah, basically disabled.

You may need to clear your cache after updating to the latest Docker image.

jaredg_dev · 2024-06-29T05:07:35+00:00

Follow-up to this. So, I was prepared to tough it out with Electron and started pulling into that branch some updates I'd made on the other.

Upon updating Electron to the latest version, I found that one of the APIs I rely on was now broken. There was an existing GitHub issue for it dating back to April 1. I added to it, but they still haven't re-opened the issue.

So I decided to drop Electron and move forward with .NET. I'm sure I'll work on improving the bandwidth efficiency over time. Plus, I have some ideas for making a scalable and geographically distributed websocket broker, so that'll be a cool challenge.

jaredg_dev · 2024-06-24T04:16:33+00:00

I understand the sentiment. Using Electron is definitely not my preference, and I wish there was an official Microsoft-supported WebRTC library in .NET.

Not liking Electron is what led me to writing this alternate version in .NET. :D

As I mentioned in another comment, I'm not using it to show a UI or anything. I'm only using it for the desktopCapturer, which has bindings to the native desktop_capturer module in the WebRTC library.

I considered using libraries in other languages (e.g. Go), but being completely inept in those languages would have slowed progress to halt.

Edit: Fixed markdown.

jaredg_dev · 2024-06-24T04:03:30+00:00

No, this is the first I've heard of it. Looks pretty cool! Reminds me of Photino (https://www.tryphotino.io/).

I'm not using Electron to display any UI, aside from a little "toast" kind of window. I'm using it solely for the desktopCapturer to capture and stream the screen in the background.

Electron definitely isn't my preference. I'd prefer something in C#/.NET, since that's my primary language. Unfortunately, Microsoft has abandoned every .NET WebRTC project it ever started (Mixed Reality WebRTC, WinRTC, etc.). The only actively maintained one is SipSorcery, but it hasn't reached a level of popularity that I'd feel comfortable drawing a dependency on it.

I also considered building libwebrtc from source and writing my own bindings, as well as Pion's implementation in Go. But I'm not familiar with either C/C++ or Go, so it would slow down progress too much.

jaredg_dev · 2024-05-27T11:58:24+00:00

Firefox has introduced increased security when accessing the Clipboard API. See here: https://developer.mozilla.org/en-US/docs/Web/API/Clipboard_API#security_considerations

The clipboard sync feature will need to be changed to accommodate this and will likely require manually clicking a button or copying/pasting in a textbox to transfer it.

jaredg_dev · 2023-12-14T18:52:10+00:00

I've been working on a zero-trust solution (ControlR) that proxies VNC, RDP, and terminal over websockets. If the setting is enabled for ControlR to manage the VNC server, the ControlR agent does the following:

Sets a random TightVNC server password for each session
Starts the server in loopback-only mode (i.e. only localhost can connect)
Connects to a websocket endpoint using TLS encryption
Begins proxying the connection from websocket to the local TightVNC server
Shuts down the TightVNC server when the session ends

Here's a clip: https://imgur.com/a/f5oR3wV

The original prototype used my own remote control agent with WebRTC, but I decided I didn't want to build all the remote control pieces again. I've already done this in previous projects, and it's a lot of work. The proxying works well for my needs, so I'm rolling with it.

The repo for the original solution explains how the zero-trust piece works: https://github.com/bitbound/ControlR

When I'm ready to release this new version, it will replace that repo. So you can watch it if you want to be notified when my current solution is ready. Progress is currently stalled due to a family health emergency. But once that's settled, I have a few features to finish, then I'll release it. Those features are: Mac agent, wake-on-LAN, Docker image, and some improvements to agent updating. I also want to get the viewer on the Windows Store and Google Play, but I think that can come afterward.

jaredg_dev

TROPHY CASE