// the find
immense/Remotely
A remote control and remote scripting solution, built with .NET 8, Blazor, and SignalR.
Remotely is a self-hosted remote control and scripting platform — think open-source TeamViewer you run yourself. It's built on .NET 8, Blazor server, and SignalR, with native screen-capture clients for Windows and Linux. The target audience is IT shops and homelabbers who want remote access without trusting a vendor's cloud.
1. The architecture is genuinely well-separated: the SignalR hub, the desktop capture clients, and the web UI are distinct projects with proper interface boundaries, making it possible to swap platform implementations without touching core logic. 2. Multi-database support (SQLite, SQL Server, PostgreSQL) via a single DBProvider config switch is done cleanly — appropriate for a self-hosted tool where deployment environments vary wildly. 3. The alerts API adds lightweight RMM functionality (disk space checks, custom webhooks) without bloating the main feature set — it knows what it is and what it isn't. 4. Platform-specific P/Invoke is organized into dedicated projects (Desktop.Native/Windows, Desktop.Native/Linux) rather than scattered throughout the codebase, which is the right call for this kind of low-level screen capture work.
1. The reverse proxy story is a real operational problem: only Caddy is officially supported, and if your infrastructure runs Nginx or sits behind a corporate firewall, you're on your own. For an enterprise IT tool, this is a significant friction point. 2. Branding requires building from source with the server URL baked in — there's no runtime configuration for it — so any white-labeling workflow means maintaining a fork. 3. SQLite is the default database, which will bite anyone running more than a handful of devices under concurrent load; the docs don't warn about this threshold clearly enough. 4. There are two overlapping desktop abstraction layers (Desktop.Core and Desktop.Shared) with duplicated files like ScreenCaster.cs, Viewer.cs, and IdleTimer.cs — signs of a refactor that was never finished, which makes it harder to navigate and contributes to the risk that a bug fix in one place doesn't get ported to the other.