KasmVNC: a browser-first VNC server that breaks from the RFB spec

The problem KasmVNC solves, and the spec it gives up

Traditional VNC servers speak RFB, and RFB clients are separate desktop applications. KasmVNC takes a different route: the user opens a modern browser, and the server itself handles the web session. The README is explicit that KasmVNC "has broken from the RFB specification which defines VNC, in order to support modern technologies and increase security," and that it "does not support legacy VNC viewer applications." That sentence is the whole product decision. You gain a browser client, TLS by default in the shipped configuration, and a YAML config format that a configuration management system can template. You lose every existing VNC viewer in your fleet, including whatever is baked into your support tooling. The target user is an engineer or platform operator who is already comfortable running a Linux desktop headlessly and wants to reach it over HTTPS rather than a raw VNC port. Kasm Technologies built KasmVNC as the streaming layer for Kasm Workspaces, and the company has open-sourced container images for full desktops and apps, so the same server also appears as a component inside a larger containerized streaming platform. If you only need a plain RFB endpoint for an existing viewer, this is the wrong project.

Architecture: a web server in front of an X session

The repository layout shows the shape of the thing. There is a common/ directory, a unix/ directory, a win/ directory, third_party/, and packaging trees for debian/, fedora/, oracle/, alpine/ and opensuse/. The server is C++, and the configuration surface is a single YAML file at /etc/kasmvnc/kasmvnc.yaml for the whole machine, with per-user overrides at ~/.vnc/kasmvnc.yaml. The defaults in that file tell you where the work happens. Under network, protocol is http, interface is 0.0.0.0, websocket_port is auto, and ssl.require_ssl is true with snakeoil certificate paths. Under encoding, max_frame_rate is 60, and there are three distinct paths: rect_encoding_mode with quality bounds, video_encoding_mode with a time_threshold and area_threshold that decide when the server switches to video encoding, and video_streaming_mode with a codec, quality and gop. That is a server that inspects the framebuffer, decides whether a region looks like video, and changes encoding strategy accordingly. Sessions are addressed by display number, which is why the systemd unit is kasmvncserver@:1 and why vncserver -kill :2 takes a display ID. The runtime_configuration block is the part worth reading twice: allow_client_to_override_kasm_server_settings defaults to true, so the browser client can change encoding settings unless an operator turns that off, and allow_override_list names exactly which settings survive that override, including pointer.enabled and the data_loss_prevention clipboard keys.

Installing KasmVNC on Debian, Ubuntu or Kali

The README does not publish a repository, so installation starts by downloading a package from the release assets on GitHub. Pick the package that matches your distribution, install it with apt, then add your user to the ssl-cert group. The README warns that you must disconnect and reconnect to the server after installation for the group membership to apply.

wget <package_url>
sudo apt-get install ./kasmvncserver_*.deb
sudo adduser $USER ssl-cert

On Oracle 8 the README uses dnf instead, enabling the ol8_codeready_builder repository and installing oracle-epel-release-el8 before the local install, then adding the user to kasmvnc-cert rather than ssl-cert. Both paths end with the same reconnect requirement, and the README does not describe an in-place upgrade procedure for either.

First session and the YAML you will actually edit

Running vncserver with no arguments starts a session and guides you through creating a user and choosing a default desktop environment. You can skip the prompt by naming a desktop, and you can add additional users with vncpasswd, giving read and write permission with -w -r. Logs land in ~/.vnc/ and vncserver -list shows the display IDs of running sessions.

vncserver -select-de mate
vncpasswd -u my_username -w -r
tail -f ~/.vnc/*.log
vncserver -list

The systemd unit is optional and is enabled per display number, which is also how you run more than one instance on a host.

systemctl --user enable kasmvncserver@:1
systemctl --user start kasmvncserver@:1

The README notes that a reboot is needed for systemd to pick up the user's ssl-cert or kasmvnc-cert group, which is the same group-membership constraint seen at install time.

Where the defaults will surprise you

Three defaults deserve attention before anything goes near a network. First, the shipped SSL certificate is the snakeoil pair at /etc/ssl/certs/ssl-cert-snakeoil.pem and /etc/ssl/private/ssl-cert-snakeoil.key. require_ssl is true, so the connection is encrypted, but browsers will reject that certificate until you replace the paths with your own. Second, allow_client_to_override_kasm_server_settings is true by default, which means the browser can change encoding behaviour on the server. The README notes that many encoding settings can be overridden by the client unless you set that key to false. If you care about predictable bandwidth or CPU use, that is the switch to flip. Third, the data_loss_prevention block ships with clipboard transfer enabled in both directions and size set to unlimited, and keyboard rate_limit set to unlimited. The visible_region block, which can conceal part of the screen from the user and optionally block clicks and releases inside it, is present but entirely commented out. A deployment that assumes clipboard restriction is on by default is wrong. The security block does enable brute force protection with a blacklist_threshold of 5 and a blacklist_timeout of 10, but the README does not state the units of that timeout, so treat the value as a starting point to confirm against the configuration reference rather than a settled number.

The limitation that decides most evaluations

The README states plainly that KasmVNC does not support legacy VNC viewer applications. Any workflow built on a standard VNC client breaks, and no configuration key in the defaults restores it, because the break is at the protocol level. The second constraint is packaging. Installation instructions in the README cover Debian, Ubuntu and Kali through .deb, and Oracle 8 through .rpm with the ol8_codeready_builder repository and oracle-epel-release-el8 enabled. The repository contains directories for alpine, fedora, opensuse and win, and BUILDING.md exists for compiling from source, but the README's install steps do not cover those platforms, and the README itself says not to use the master branch README unless you are compiling from the tip of master. Documentation for a given release lives at the versioned docs site, not in the repository. If your target is Windows or macOS, the README gives you no supported install path; the win/ directory existing in the tree is not the same as a documented Windows server.

KasmVNC against TigerVNC and against Apache Guacamole

The README names TigerVNC, RealVNC and TurboVNC as the variants KasmVNC differs from, and the difference is architectural rather than a matter of tuning. Those servers stay inside RFB and expect a native viewer. KasmVNC terminates the web session itself, which is why it can ship browser-side controls and a YAML schema that includes clipboard policy and a concealable screen region. A different comparison is Apache Guacamole, which people also search for alongside KasmVNC. Guacamole is a gateway that speaks several remote protocols and renders them in a browser, so the remote machine keeps running its own VNC or RDP server. KasmVNC replaces the server on the remote machine instead. If you already run RDP or standard VNC on the hosts and want one browser entry point in front of them, a gateway model fits better. If you control the host and want the browser session, TLS and the encoding policy to be properties of that host, KasmVNC's model is the closer fit. The README does not include a Guacamole configuration example, so that distinction is the only one it supports.

Maintenance, licensing and what upgrades cost you

The repository is not archived, and the last push was on 2026-09-15. The most recent release listed is v1.5.0 on 2026-07-29, following v1.4.0 on 2025-10-22 and v1.3.4 on 2025-04-29. That cadence matters for planning: roughly three months between the two newest releases, and roughly six between the two before that, so you should not assume a fixed schedule. Upgrade cost is mostly configuration drift. The README's default YAML is a full listing of every setting, and the project maintains a separate configuration reference page, which implies keys can be added or change meaning between releases. Because server-level settings live at /etc/kasmvnc/kasmvnc.yaml and users override them at ~/.vnc/kasmvnc.yaml, a package upgrade can leave stale user files shadowing new defaults, and the README describes no migration or validation step for that. The licence is GPL-2.0, and LICENSE.TXT sits at the repository root. GPL-2.0 is a copyleft licence, so if you embed KasmVNC in a product you distribute, the obligations attach to that distribution. This is not legal advice; read LICENSE.TXT and ACKNOWLEDGEMENTS.md, which lists third-party components, before you ship anything derived from it.

Editorial conclusion

Adopt KasmVNC if your users reach a Linux desktop through a browser and you want TLS, per-user YAML overrides and data loss prevention settings in one server. Do not adopt it if your fleet depends on standard VNC viewer applications, since the README states legacy viewers are not supported, or if the machine you target is not one of the packaged distributions. Before rolling it out, verify that the .deb or .rpm for your distribution exists under the release assets, that you can add your user to the ssl-cert group on Debian or Ubuntu (or kasmvnc-cert on Oracle 8), and that a reconnect actually applies the group membership, because the README says the change only takes effect after you disconnect and reconnect.

Frequently asked questions

Official sources

1. Issues
2. kasmtech/KasmVNC on GitHub
3. License: GPL-2.0
4. README
5. Releases