Open-source remote control and scripting, honestly reviewed. No marketing fluff, just what you get when you self-host it.

TL;DR

What it is: An open-source, browser-based remote control and remote scripting platform built on .NET, Blazor, and SignalR. Think TeamViewer, but the server runs on your infrastructure and you never pay a per-seat license.
Who it’s for: MSPs, IT teams, and technically-inclined founders who need to remotely manage a fleet of Windows or Linux machines — and want the controlling side to be pure browser, no client install.
Cost savings: TeamViewer’s business plans run $24–$50/month per license; AnyDesk starts around $14/month. Remotely self-hosted runs on a $6–10/month VPS with no per-seat or per-session fees.
Key strength: The scripting console. You can blast PowerShell or bash commands across dozens of machines simultaneously from a browser tab — something the commercial tools either gate behind enterprise plans or don’t offer at all.
Key weakness: GPL-3.0 license (not MIT), and the only officially supported reverse proxy is Caddy. If your stack is nginx or your org has firewall complexity, you’re on your own for support.

What is Remotely

Remotely is a self-hosted remote control and scripting platform. The GitHub repository (maintained by immense, the company behind ImmyBot) describes it plainly: “A remote control and remote scripting solution, built with .NET 8, Blazor, and SignalR Core.” That’s exactly what it is — no AI buzzwords, no market-disruption narrative [README].

The architecture is worth understanding before you commit to it. The controlling side is your browser — you navigate to the web interface you deploy, and you see and control remote machines through it. The controlled side runs a lightweight agent installed on each Windows or Linux machine. No TeamViewer-style desktop app is needed on the IT admin’s machine. This matters practically: you can support a user from any device with a browser, including a phone or a tablet you grabbed off a shelf.

Beyond screen sharing, Remotely ships a scripting console that lets you execute commands — PowerShell, bash, cmd — across multiple selected machines simultaneously. For an MSP running 50 client machines, that’s the feature that actually justifies the deployment overhead. Patching, diagnostics, cleanup scripts: all manageable from one browser tab.

The project sits at 5,033 GitHub stars with active CI on Azure Pipelines [merged profile][README]. It is licensed under GPL-3.0, which is meaningfully different from the MIT license: you can self-host freely, but if you ship Remotely as part of a commercial product or service, the GPL requires you to open-source your modifications.

Why people choose it

Third-party reviews specifically covering Remotely were not available at time of writing — the tool is niche enough that it lives primarily in MSP forums, Reddit threads on r/remotely_app (linked directly from the README), and word-of-mouth among sysadmins rather than mainstream tech press. What follows draws from the README, the feature set, and the general self-hosting context.

The core argument for Remotely is economic and architectural: commercial remote control tools price per seat, per month, and escalate fast as your device count grows. TeamViewer famously sent cease-and-desist letters to users it detected were using “personal” licenses commercially. AnyDesk has done the same. The per-session pricing model is opaque for anyone managing more than a handful of machines.

Remotely’s self-hosted model eliminates that entirely. Your server cost is fixed. Your seat count is unlimited within your own deployment. The general self-hosting argument applies directly: “With popular automation services, I’m forced to trust them with my data. Every time I set up a workflow that links… sensitive information is being passed through their servers.” [2] Remote control is exactly this — a third-party vendor has real-time screen and keyboard access to your clients’ machines. Self-hosting moves that trust boundary to infrastructure you control.

The counter-argument is real too: self-hosting means you are the uptime guarantee [3]. If your Remotely instance goes down, your remote access goes down. Unlike TeamViewer’s globally distributed infrastructure, a single VPS failure means you’re flying blind. That’s the trade-off the tool’s Reddit community discusses openly.

Features

Based on the README and the canonical feature list [README][merged profile]:

Remote control:

Browser-based viewer — no install on the controlling machine
Full keyboard and mouse control
Multi-monitor support
File transfer between local and remote machines
Chat with the remote user during sessions
Background (unattended) access — no interactive desktop session required

Remote scripting:

Execute PowerShell, bash, and cmd scripts
Multi-select machines — run a script across an entire fleet simultaneously
Script output returned to the browser console in real time
Saved script library

Platform and infrastructure:

Docker and Docker Compose deployment [README]
SQLite by default; PostgreSQL and MSSQL supported for larger deployments [merged profile]
Only officially supported reverse proxy: Caddy [README]
REST API available [merged profile]
Two-factor authentication [merged profile]

Multi-tenancy:

Organization model: users, devices, and data grouped per organization
Single admin account owns both server and organization admin
MaxOrganizationCount configurable — default is single-org but can be set to -1 for unlimited
After the first account registers, public self-registration is disabled automatically [README]

Security and networking:

HTTPS with proper forwarded headers handling (X-Forwarded-Proto, X-Forwarded-Host, X-Forwarded-For) [README]
ASP.NET Core middleware handles proxy header injection — not custom Remotely code
KnownProxies array in Server Config for non-standard firewall chains [README]
HTTP logging toggle for debugging reverse proxy issues [README]

What’s not there:

No native mobile app for the controlled side (browser viewer works on mobile, but the agent is desktop-only)
No built-in screen recording or session audit logs (at least not documented in the README)
No SaaS hosted version — this is purely self-hosted

Pricing: SaaS vs self-hosted math

There is no Remotely cloud tier. The pricing math is simpler than most tools in this category.

Remotely self-hosted:

Software license: $0 (GPL-3.0) [README]
VPS to run it: $6–12/month (Hetzner, Contabo, DigitalOcean — 2GB RAM minimum recommended)
Domain + Caddy: included in typical VPS setup
Your time to deploy: 30–90 minutes for a technical user

TeamViewer for comparison:

Business: ~$24/month per license (1 user, 1 session at a time)
Premium: ~$50/month for up to 15 managed devices per license
Corporate: custom pricing
“Free for personal use” — but their bot detection is aggressive and has flagged legitimate personal users as commercial

AnyDesk for comparison:

Solo: ~$14.90/month (1 licensed device)
Standard: ~$20.90/month (20 managed devices)
Advanced: ~$57.90/month (100 managed devices)

Concrete scenario: An MSP managing 50 client machines. On AnyDesk Advanced that’s $57.90/month. On TeamViewer Corporate, pricing is opaque but routinely lands at $100–$200/month for similar scale. On Remotely self-hosted on a $8 Hetzner VPS: $8/month, unlimited devices.

Over a year: TeamViewer ≈ $1,200–$2,400. AnyDesk ≈ $695. Remotely ≈ $96 plus setup time.

The caveat is the same as every self-hosted tool: you’re the ops team. Uptime, backups, updates — that’s your problem [3].

Deployment reality check

The Quickstart in the README is three commands [README]:

mkdir -p /var/www/remotely
wget -q https://raw.githubusercontent.com/immense/Remotely/master/docker-compose/docker-compose.yml
docker-compose up -d

That gets you a running instance. What the three-line summary omits:

Caddy is not optional if you want to expose this to the internet. The README explicitly states it’s the only supported reverse proxy. ASP.NET Core’s SignalR has specific WebSocket requirements that Caddy satisfies by default. If you try to run it behind nginx — common in existing stacks — you need to configure WebSocket proxying correctly, and the Remotely maintainers direct you to community support, not official docs, for that path [README].

Forwarded headers must be right. If you’re putting this behind any firewall or intermediate proxy, you must pass X-Forwarded-Proto, X-Forwarded-Host, and X-Forwarded-For correctly, and any intermediate IP must be in the KnownProxies list. The Docker Compose setup adds the Docker gateway (172.28.0.1) automatically, but a custom network topology means manual config [README].

First registration matters. The first account you create becomes both server admin and organization admin. After that, the Register button disappears. If you want multiple organizations — multi-tenant for an MSP — you need to configure MaxOrganizationCount before other clients try to self-register. Easy to miss [README].

Build environment (if you compile from source): Visual Studio 2022 on Windows 11 with three workloads: ASP.NET, .NET desktop development, .NET Core cross-platform. The Docker path avoids this entirely for most deployments [README].

Realistic time estimates:

Technical user, Docker path, Caddy, fresh VPS: 45–90 minutes
Non-technical user with a guide: half a day, including domain DNS propagation
Existing nginx stack that needs Caddy alongside it: add an hour of port conflict debugging

The YouTube tutorial linked in the README (credited to @bmcgonag) is the community’s preferred onboarding path. That’s a good signal — there’s community infrastructure around this tool even if the official docs are thin.

Pros and cons

Pros

No per-seat pricing. Unlimited devices on your own server for the cost of a VPS. The economics are unambiguous against any commercial remote access tool at scale [README].
Browser-based viewer. The IT admin needs zero software installed. This is genuinely useful in practice — support from any machine, including borrowed laptops or tablets.
Multi-machine scripting console. Select 20 machines, run a PowerShell script, get output in real time. Commercial tools either don’t offer this or charge enterprise rates for it.
No vendor lock-in. GPL-3.0 means your data and your config stay yours. The vendor cannot remotely disable your instance, raise prices, or decide your use case is “commercial” [README].
SQLite by default, scales to PostgreSQL/MSSQL. Right-sized defaults without forcing you to run a separate DB for a small deployment [merged profile].
Active CI pipeline. Azure Pipelines with automated tests — this is not abandoned software [README].
Multi-tenant organization model. Useful for MSPs who need logical separation between clients.

Cons

GPL-3.0, not MIT. If you want to embed Remotely in a commercial product or resell a managed version to clients, the GPL requires you to open-source your modifications. MIT alternatives (like parts of the RustDesk ecosystem) don’t have this constraint.
Caddy-only official reverse proxy support. Most production environments already have nginx or Traefik. The maintainers explicitly won’t help you if your setup differs from the reference configuration [README]. This is a real friction point for anyone with an existing stack.
No hosted tier. There is no “Remotely Cloud” to start with before self-hosting. You either run it yourself or you don’t use it.
Thin official documentation. The primary user-facing docs are the README, the Docker Compose file, and the community subreddit. For a tool at 5,000+ stars, the documentation surface is limited compared to something like MeshCentral or RustDesk.
No session recording or audit logs documented. For compliance-sensitive environments — healthcare, finance — the absence of documented session auditing is a gap. Data not available in the reviewed sources.
Windows-first build instructions. Development setup is documented for Windows 11 + Visual Studio. Linux-based development paths exist but are not the documented path.

Who should use this / who shouldn’t

Use Remotely if:

You’re an MSP or IT team managing 20+ machines and the per-seat cost of TeamViewer or AnyDesk is adding up.
You want browser-based access to remote machines without installing software on your own device.
Remote scripting across a fleet is a core part of your workflow — not just occasional remote sessions.
You’re comfortable with Docker and Caddy, or willing to follow a community tutorial.
GPL-3.0 licensing is fine for your use case (internal use, not embedded in a commercial product).

Skip it (use RustDesk instead) if:

You want a simpler deployment with broader reverse-proxy compatibility.
You need mobile apps on the controlled side.
You want a more lenient license (RustDesk has a dual AGPL/commercial structure with a relay server option).
Your non-technical users will be setting this up themselves — RustDesk’s UX is more consumer-facing.

Skip it (use MeshCentral instead) if:

You need detailed session recording and audit trails — MeshCentral documents these explicitly.
You want a broader protocol stack (RDP, VNC, SSH) in one tool rather than agent-only access.
You prefer Node.js-based infrastructure over .NET.

Stay on TeamViewer/AnyDesk if:

Your compliance team won’t approve self-hosted infrastructure.
Uptime guarantees matter more than cost — you need someone else to be on-call when the relay goes down [3].
Your device count is small enough that the per-seat cost is noise.

Skip it (for non-technical founders) if:

You don’t have someone who can manage a Linux VPS and debug WebSocket proxy headers.
You need occasional one-off remote support, not fleet management — a free TeamViewer personal session is a better fit.

Alternatives worth considering

RustDesk — The most direct open-source competitor. Rust-based, MIT/AGPL licensed, 50,000+ GitHub stars, mobile apps on both ends, self-hosted relay server. Easier consumer UX, less MSP-focused. If you want something your clients can install themselves, RustDesk wins.
MeshCentral — Intel-backed (now community-maintained), Node.js, comprehensive protocol support (RDP, VNC, SSH, MQTT), detailed session recording and audit logs, multi-tenant. More complex to deploy, more feature-complete for compliance-sensitive environments.
Apache Guacamole — Browser-based gateway for existing RDP, VNC, and SSH connections rather than a proprietary agent. Fits environments where machines already have RDP enabled.
TeamViewer — The commercial incumbent. Easiest onboarding, best reliability, global support, punishing per-seat pricing at scale. The tool you’re probably trying to escape.
AnyDesk — Cheaper than TeamViewer, similar model. Fine for small teams, expensive at fleet scale.
Teleport — If your use case is actually SSH and infrastructure access rather than GUI remote control, Teleport is more purpose-built. Overkill for most founders, right for DevOps teams.

The realistic self-hosted shortlist for MSP use is Remotely vs MeshCentral vs RustDesk. Remotely wins on scripting console depth. MeshCentral wins on audit/compliance. RustDesk wins on ease and ecosystem.

Bottom line

Remotely is a focused tool for a specific audience: technical teams who manage fleets of Windows or Linux machines and want the economics of self-hosting without the UX friction of setting up VNC or RDP per machine. The browser-based viewer and multi-machine scripting console are its strongest arguments. The GPL license, Caddy-only official support, and thin documentation are its real constraints — not dealbreakers for the right operator, but friction that’s worth knowing about before you commit.

For a solo founder occasionally remoting into one or two machines, it’s more than you need. For an MSP paying $50–$150/month in TeamViewer licenses across a client base, the math to a $8 VPS running Remotely is obvious. The afternoon of setup pays for itself in month one.

If the setup is the blocker, that’s exactly what upready.dev deploys for clients. One-time fee, done, you own the infrastructure.

Sources

@bmcgonag, YouTube — Community tutorial for Remotely deployment. Linked from the official README.
Corbin Davenport, How-To Geek — “Here’s Why Self-Hosting a Server Isn’t a Good Idea” (Nov 21, 2022). https://www.howtogeek.com/833269/heres-why-self-hosting-a-server-isnt-a-good-idea/
Jason Fitzpatrick, How-To Geek — “Here’s Why Self-Hosting a Server Is Worth the Effort” (Nov 21, 2022). https://www.howtogeek.com/846979/heres-why-self-hosting-a-server-is-worth-the-effort/

Primary sources: