Pangolin 1.19: Browser Remote Access — SSH, RDP, VNC & More | Pangolin<br>Pangolin 1.19: Browser Remote Access — SSH, RDP, VNC & More<br>June 11, 2026release<br>changelog<br>ssh<br>rdp<br>vnc

Discover PangolinBook a demo

Pangolin 1.19 is here. This release brings browser-based remote access to SSH, RDP, and VNC, makes Pangolin SSH dramatically easier to set up, adds automatic updates for site connectors, and ships a handful of organizational improvements that make large deployments easier to manage. Let's walk through it.

Release highlights

SSH, RDP, and VNC in the Browser

You no longer need a separate SSH client, remote desktop app, or VNC viewer to reach your infrastructure. Pangolin now supports web-based remote access over SSH, RDP, and VNC as first-class public resource protocols. Assign a domain, point it at a site connector, and users get a full interactive session in any modern browser after completing Pangolin authentication.

For SSH in the browser, that means a real web-based terminal with password, key, or Pangolin identity authentication, depending on how you configure the resource. For RDP in the browser, users get a full Windows remote desktop with clipboard support and file transfers. No Remote Desktop client to install. For browser-based VNC, a remote display rendered right in the tab. No Pangolin client or VPN is required on the user's machine.

This uses the same site-resource model as your HTTP resources. You don't need to run a Pangolin site connector on the target machine. Install Newt on a host that can reach your network, select which sites can route to the resource, and point it at any SSH server, Windows box, or VNC display on that network, just like you've always done with HTTPS.

Each protocol gets its own public FQDN, and you manage your SSH, RDP, and VNC remote access resources alongside your other public resources in one place. Identity-aware access rules, SSO, and geo-blocking apply the same way they do for HTTP.

This makes Pangolin an Apache Guacamole alternative for browser-based remote access over SSH, RDP, and VNC with site tunneling built in and stronger authentication support through SSO, identity providers, and granular access rules.

Read more about SSH, RDP, and VNC in the docs.

Improved Pangolin SSH

When we shipped native SSH in Pangolin 1.16, the focus was certificate-based authentication, just-in-time user provisioning, and tight integration with OpenSSH. It worked well, but getting there meant configuring an auth daemon, editing sshd_config, trusting a certificate authority, and in many cases standing up a bastion pattern for multi-server environments. Powerful, yes, but a fair bit of host setup before your first connection.

Pangolin SSH mode changes that entirely. Instead of routing commands over the network to an OpenSSH server, Pangolin SSH executes sessions directly on the host through the site connector. There's no SSH server to install, no auth daemon to configure, and no sshd_config to touch. Select Pangolin SSH in the dashboard, make sure Newt runs as root on the machine you want to access, and you're done.

This is now the default when you create an SSH resource. Manual authentication works out of the box with existing host credentials. If you want Pangolin identities provisioned automatically, switch to automated provisioning, still without touching OpenSSH.

Pangolin SSH works on both public and private SSH resources. On a public resource, users get a browser-based terminal at the resource FQDN. On a private resource, connect with the Pangolin client and SSH over the private tunnel:

$ pangolin ssh prod-app.internal<br>Copy code

The CLI also now supports SCP for copying files over the same private tunnel:

$ pangolin scp ./config.yml prod-app.internal:/etc/app/<br>Copy code

Same mode, same setup—whether users reach the session through a browser or the CLI.

Standard SSH Server mode is still there when you need it, like reaching a legacy OpenSSH host on the network or running the bastion-and-auth-daemon setup from 1.16. But for the common case, SSH into the machine running your site connector, Pangolin SSH is the path of least resistance.

Read more about SSH access in the docs.

Automatic Site Updates

Keeping site connectors up to date across a fleet is tedious. You ship a new Pangolin release, then you SSH into each edge device, pull the latest binary, restart Newt, and hope you didn't miss one.

Automatic updates handle that for you. When enabled, Newt periodically checks for a newer version, downloads it, and restarts itself. The site reconnects on the new version without manual intervention. Pangolin waits 24 hours after a release is published before sites pull it, giving early issues time to surface before your whole fleet updates.

You can enable automatic updates at the organization level for all sites, or toggle it per site. Turn it on globally and disable it on specific sites that need to stay pinned. Turn it off globally and enable it only where you want...