1Remote: A Windows Session Launcher for RDP, SSH, VNC and SFTP

The problem: remote sessions scattered across clients

If you administer Windows servers, a typical desktop ends up with the built-in Remote Desktop client for RDP, PuTTY or Windows Terminal for SSH, a VNC viewer, an FTP client, and a couple of vendor tools for appliances that only speak Telnet. Each of those keeps its own address book in its own format. The README frames 1Remote as "a modern personal remote session manager and launcher" and "a single place to manage all your remote sessions supporting number of different protocols".

The audience is narrow and specific: a single person, on Windows, who connects to many machines over several protocols and wants one searchable list instead of five. The word "personal" in the README matters. Nothing in the repository describes shared configuration, team roles, or a central server holding the connection inventory. This is a desktop tool, not a bastion host.

How the launcher and protocol runners fit together

The architecture visible in the repository is a WPF desktop application. The solution file 1Remote.sln sits at the top level next to Ui/, Shawn.Utils/, Tests/, lib/, Dragablz/ and VncSharpCore/. Dragablz is a tabbing library, and VncSharpCore is a VNC client library, which tells you that VNC is handled inside the application rather than shelled out to a separate viewer.

The feature list distinguishes between protocols that are built in and protocols where 1Remote acts as a front end. RDP, SSH, VNC and Telnet are listed as supported directly, and RemoteApp is described as working over RDP. Separately, the README describes "customizable runners" in SFTP, FTP and VNC, where "you can replace the internal runner with your favourite tools". That is the core design idea: the session record (address, credentials reference, tags, icon, colour, connection script) is the durable object, and the runner is the swappable part that turns that record into a live window.

The launcher is bound to Alt + M. The README shows it opening an RDP connection and resizing it. Tags, icons, colours and connection scripts are listed as per-connection configuration, which is what makes a list of a hundred hosts navigable rather than alphabetical noise.

Installing 1Remote and opening a first session

The README points to a download page and a quick start page rather than giving inline install commands, and it states the project is portable: "just unpack and run". There is no package manager step documented. The repository does contain an Installer/ directory and an Invoke-Build.ps1 script, but those are for building the project from source, not for end users.

The practical first run is: get the archive from the download page, unpack it anywhere writable, and start the executable. Because the README says portable, expect the configuration to live alongside the unpacked files, so unpacking into Program Files or another protected directory is likely to cause problems.

Once it is running, add a connection from the main window. The fields you will touch first are the protocol, the address, and the display name; tags, icon, colour and connection script are secondary. After saving, the connection appears in the list and can be launched from there.

Alt + M        open the launcher

With the launcher open, type part of the connection name and pick the entry. The README shows the launcher opening an RDP session and then resizing it, so the window it produces is a normal resizable session window, not a fixed-size canvas.

If you are migrating from mRemoteNG, the README links a dedicated import page. That is the path to take rather than re-entering hosts by hand, and it is worth testing on a small export first, because the README does not describe how import conflicts or duplicate names are resolved.

Windows only, and the runner model cuts both ways

The topics list on the repository includes windows and windows-app, the UI is WPF, and the README's multi-monitor claim is explicitly a Windows-to-Windows test: "Test on Win10 + 4k monitor *2 RDP TO Win2016". There is no macOS or Linux build described. If you work across operating systems, 1Remote covers only the Windows machine you run it on.

The runner model is a genuine trade-off rather than a pure feature. Replacing the internal SFTP or VNC runner with your own tool means the session list stays authoritative while the actual protocol work happens somewhere 1Remote does not control. That is flexible, and it also means the quality of a given protocol experience depends on whichever external tool you configured. The built-in paths and the delegated paths do not behave the same way, and the README does not claim they do.

A second limitation is scope. This is a session launcher, not a session recorder. Nothing in the repository describes session logging, keystroke audit, or a shared inventory that a team can review. If your requirement is "prove who connected to which server and when", 1Remote is the wrong tool, regardless of how well it launches RDP.

1Remote compared with mRemoteNG and RDCMan

mRemoteNG is the closest comparison, and the README treats it as a migration source rather than a rival: there is a documented import path from mRemoteNG. Both tools put multiple protocols behind one connection list, and both are Windows desktop applications. The practical difference is packaging and the runner concept. 1Remote states it is portable, so the whole tool and its configuration can live in a folder you carry; mRemoteNG's install and configuration model is not described in the README, so that comparison should be checked against its own documentation rather than assumed.

RDCMan is a different shape of tool. It is an RDP connection manager, so the multi-protocol list is where 1Remote goes further, and RDP-specific management depth is where RDCMan concentrates. Choosing between them is mostly a question of whether you actually need SSH and VNC in the same list as your RDP hosts.

RustDesk appears in related searches but solves a different problem: it is remote access software where the remote side runs an agent, rather than a client that launches sessions to machines you already reach. If you need unattended access to a machine behind NAT, a session launcher is not the answer.

Maintenance, licence and upgrade cost

The repository is not archived, and the last push was on 2026-09-22. Release 1.3.0 is dated 2026-09-21, following a 1.3 prerelease in April 2026 and 1.2.1 in August 2025. That is a steady but not rapid cadence: roughly one significant release per year, with prereleases in between. Plan upgrades around that rhythm rather than expecting continuous drops.

The project is licensed GPL-3.0. For an individual using the downloaded portable build, that is unremarkable. It matters if you intend to link 1Remote into your own product or ship a modified build: GPL-3.0 carries source distribution obligations for derivative works, and whether your specific use counts as a derivative is a question for a lawyer, not for this article. The repository also contains .gitmodules and vendored directories (Dragablz, VncSharpCore, Shawn.Utils), so a source build pulls in submodules and needs MSBuild resolved, which is what Resolve-MSBuild.ps1 and prm.build.ps1 are for.

The upgrade cost for an end user is low if portability holds: unpack the new version and point it at your existing configuration. The README does not document a rollback procedure or a configuration schema version, so keep a copy of your configuration folder before replacing a working build.

Editorial conclusion

Adopt 1Remote if you are on Windows, you already juggle several remote protocols, and you want a portable folder you can drop on a USB stick or a jump host instead of installing a client per protocol. Do not adopt it if your daily machine is macOS or Linux, if you need a shared multi-user session inventory with an audit trail, or if you want an SSH client you can script from a terminal. Before committing, verify three things on your own hardware: that the Alt + M launcher does not collide with a shortcut you already use, that the RDP multi-monitor and HiDPI behaviour matches your display setup, and that the import path from mRemoteNG produces the connections you expect.

Frequently asked questions

Official sources

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