mRemoteNG: a Windows connection manager that became the place your passwords live

Nine protocols behind one tabbed list

The README's positioning is an open source, multi-protocol, tabbed remote connections manager for viewing all connections in a single interface. The protocol list is what makes it more than a saved RDP file manager.

Supported are RDP, VNC, SSH, Telnet, HTTP and HTTPS, rlogin, raw socket connections, PowerShell remoting, and AnyDesk. That set covers the common cases of administering a mixed estate: Windows hosts over RDP, Linux hosts over SSH, appliances with a web interface, devices that only speak a raw TCP protocol, and a remote support tool bolted on at the end.

What the README does not do is enumerate what each protocol can do. There is no matrix saying which ones support port forwarding, which ones can chain through a jump host, which ones are usable from the command line rather than only through the interface. The README points to the documentation at mremoteng.readthedocs.io for a detailed feature list and general usage support, which is where that mapping lives.

The connection data is the valuable part. Once your connections are in the application rather than scattered across Remote Desktop, PuTTY, and a browser's bookmark bar, you gain search, grouping, and a single place to see what you have. The topics attached to the repository include rdp, ssh, remote-desktop, remote-access, and windows, which is an accurate summary of the scope.

The project describes itself as the next generation of mRemote, and it carries a GPL-2.0 licence with the license text at `COPYING.TXT` in the repository root.

Three release channels and what each one is for

The README carries a build table with three channels, and the distinction matters because they are not just labels on the same binary.

Stable is the v1.76.20 line, preview is v1.77.1, and nightly tracks the develop branch with a dated build such as 20250916-v1.78.2-NB-(3177). The numbering inside the nightly tag carries both a build date and a build number, which is how you tell two nightlies apart when you need to report a regression.

The nightly releases themselves explain the two download flavours. A framework-dependent build is roughly 15 to 25 MB and needs the .NET 10 Desktop Runtime installed on the machine. A self-contained build is roughly 80 to 150 MB, bundles the runtime, needs no installation, and can be unpacked and run from a USB drive. Both are published for x64 and ARM64.

The February 2026 release notes record when the self-contained option arrived. That manual build for early testing is listed as migrating to .NET 10 as an LTS release, adding the self-contained portable build so nothing needs to be installed, and adding an experimental sessions menu that works per tab.

The nightly channel is also where security fixes land first. The 2026-09-11 build 3694 and the 2026-09-15 build 3702 carry the same batch of remediations, which is worth reading before you upgrade rather than after.

The security fixes that define the recent releases

This is the part of the release history that deserves the most attention from anyone who stores credentials in the application, and it is unusually explicit.

The 2026-09-15 nightly, build 3702, lists a SQL injection fix by switching to parameterized queries, a command injection fix around `Process.Start`, an XML External Entity vulnerability in XML deserialization, and a path traversal vulnerability in file operations. It also fixes HTTP/HTTPS protocol support for multiple concurrent connections, a missing Username field for those same protocols, a cross-thread crash when closing the splash screen on a startup error, and a password dialog that appeared behind the splash screen at startup.

Read that list carefully and the shape of the application becomes clear. It deserializes XML, it starts processes, it runs queries, and it opens files. Those four capabilities are the four vulnerabilities, one for each. A connection manager that stores a host, a username, and a password is handling untrusted-looking input at multiple boundaries, and the fixes are the kind that only get found by people looking.

The practical consequence is concrete: if your copy predates these fixes, it should be replaced rather than merely updated, because the stored credentials in that copy were reachable through at least one of those paths. Both the September nightlies carry the batch, and the last push to the default branch was on 2026-09-19.

The README also asks for donations rather than corporate sponsorship, naming VPS hosting for testing, AI tools, and domain fees among the ongoing costs, and describing the project as non-commercial.

Windows only, and what that costs you

The supported operating systems list is unambiguous: Windows 11, Windows 10, Windows 8.1, Windows Server 2022, Windows Server 2019, Windows Server 2016, and Windows Server 2012 R2. There is no macOS or Linux entry, and that is not an oversight in the documentation. It follows from the protocols.

RDP is the centre of gravity here, and the Remote Desktop client on Windows is a native component. The minimum requirements list Microsoft Terminal Service Client 6.0 or later, specifically for RDP with `mstscax.dll` and `msrdp.ocx` registered. AnyDesk is supported as well, which is one route to non-Windows targets from a Windows workstation, but the host application itself is a Windows desktop application.

The runtime requirements are .NET Desktop Runtime 10.0 and the Microsoft Visual C++ Redistributable 2015 to 2026, published for x64, ARM64, and x86. The self-contained build removes the first of those requirements, which is the reason it exists.

There is also a source package, which contains the source code and requires compiling in Visual Studio yourself. The README notes that on Windows 11 and later, winget can install mRemoteNG, which removes the manual download step but not the platform requirement.

Building plugins from a separate solution

Plugins are built from their own solution rather than from the main one, and loaded from the application's plugin folder at runtime. The build command is a single line:

dotnet build mRemoteNG.Plugins.sln -c Release -p:Platform=x64

After building, the generated DLLs go into the application's plugin folder, and there is one exception. The shared contracts assembly stays in the app's `Assemblies` folder rather than the `Plugins` folder, because it is the interface the plugins and the host agree on:

Copy-Item .\mRemoteNG.PluginContracts\bin\x64\Release\net10.0-windows10.0.26100.0\mRp.Contracts.dll .\mRemoteNG\bin\x64\Release\Assemblies\
Copy-Item .\mRemoteNG.Plugins.PortScan\bin\x64\Release\net10.0-windows10.0.26100.0\mRp.PortScan.dll .\mRemoteNG\bin\x64\Release\Plugins\

Two practical notes come straight from the README. The paths are the x64 output, and for an ARM64 build you replace `x64` with `arm64` throughout. And the build target framework in the paths is `net10.0-windows10.0.26100.0`, so a Windows SDK matching that version has to be present.

The plugins that ship in the repository are PortScan, SshTransfer, AWS, and MultiAddress, each its own project directory alongside the shared `mRemoteNG.PluginContracts/`. The full workflow is documented separately in `README.plugins.md`.

PortScan and SshTransfer are the two with an obvious operational purpose, a port scanner for inventory work and SSH file transfer for moving things without a second tool. Worth noting that a port scanner in a credential store is a meaningful capability to hand to a plugin, which is why the contracts project exists as a separate assembly rather than a folder inside the plugin.

What the repository layout tells you about the project

The tree is large enough to be worth mapping, because for a desktop application of this kind the folder names are the clearest description of the architecture.

`mRemoteNG/` is the application itself, with `mRemoteNGInstaller/` for packaging and `mRemoteNGDocumentation/` for the Read the Docs source. There are three test projects: `mRemoteNGTests/`, `mRemoteNGSpecs/`, and `ObjectListView/`, the last being the WinForms control library for the connection list. `ExternalConnectors/` holds the per-protocol integrations, and `Tools/` holds utilities.

The plugin family is visible as separate directories: `mRemoteNG.PluginContracts/`, `mRemoteNG.Plugins.AWS/`, `mRemoteNG.Plugins.MultiAddress/`, `mRemoteNG.Plugins.PortScan/`, and `mRemoteNG.Plugins.SshTransfer/`, with `mRemoteNG.Plugins.sln` grouping them.

Several top-level files are documentation that has outgrown the wiki, and they tell you where the maintainer's attention has been. `IMPLEMENTATION_NOTES.md`, `OptionsManagementDevGuide.md`, `PANEL_BINDING_FEATURE.md`, `VISUAL_EXAMPLES.md`, and `DEPLOYMENT_OPTIONS.md` are all design or build notes at the repository root. `renovate.json` handles dependency updates automatically, and `.readthedocs.yaml` builds the docs site.

One root entry deserves attention because it is unusual: a committed `PuTTYNG.exe`. PuTTY NG, the PuTTY fork that mRemoteNG has long bundled, is now built from within this repository rather than shipped as a separate binary. That is a meaningful change for anyone auditing the supply chain, because it moves a component from a third-party artifact into code you can read in the tree.

Editorial conclusion

mRemoteNG is a good fit when one person administers many hosts and wants them in one searchable list rather than in a folder of saved sessions. The two things to weigh are the Windows-only requirement, since the supported operating systems list is entirely Windows, and the fact that the application stores credentials for everything it manages. On the second point, the September 2026 nightly build is the release to take, because it carries fixes for SQL injection through parameterized queries, command injection via `Process.Start`, an XML External Entity vulnerability, and a path traversal in file operations. Install the self-contained build if you would rather not manage a .NET runtime, build plugins from the separate solution if you need the port scanner or SSH transfer, and treat the nightly channel as the place security fixes land first.

Frequently asked questions

Official sources

1. License: GPL-2.0
2. mRemoteNG/mRemoteNG on GitHub
3. Project website
4. README
5. Releases