What is Apache Guacamole?

Apache Guacamole is a clientless remote desktop gateway that provides access to remote systems over RDP, VNC, SSH and Telnet straight in the browser: via HTML5, with no installed client, no plugin and no agent on the end device. A modern browser is all you need. Guacamole is free software under the Apache License 2.0 and is maintained by the Apache Software Foundation. That lets you self-host it and run it as a sovereign, multi-tenant access portal for distributed plants, servers and IoT devices, without machines or servers ever having to be directly reachable from the internet.

How Apache Guacamole works

Guacamole cleanly separates the web interface from protocol handling. Two components work together:

• guacd (the daemon): the heart of the system. guacd is a native proxy service that loads the actual remote desktop protocols (RDP, VNC, SSH, Telnet, Kubernetes) as plugins and opens a connection to the target system on the user's behalf. It translates those protocols into the lightweight Guacamole protocol.
• guacamole-client (the web app): a Java web application that runs in a servlet container such as Apache Tomcat and provides the web interface and authentication. It does not implement a single remote protocol itself, but forwards the Guacamole protocol between the browser and guacd.

In the browser, a client written in JavaScript runs using only HTML5 and open standards. It connects back to the web app over HTTP(S) and exchanges the Guacamole protocol. guacd and its protocol plugins share a common library, libguac, which abstracts the communication. For the user this means the keyboard, mouse and screen of the remote system appear in a browser tab, and nothing else is required on the end device.

Architecture at a glance

A production Guacamole setup consists of a few clearly separated layers:

• A reverse proxy with TLS (for example nginx or Traefik) terminates HTTPS and is the only point reachable from outside.
• The guacamole-client in Tomcat serves the interface and authentication.
• guacd opens the actual protocol connections into the internal network.
• A database (MariaDB/MySQL or PostgreSQL) stores users, connection definitions, permissions and connection history.
• The target systems (servers, HMIs, controllers) sit in the internal network and are not reachable from the internet themselves.

The key security benefit of this architecture: the target system only talks to guacd on the same network. Only the gateway is visible from outside. RDP, VNC or SSH ports never need to be opened to the internet.

Current version

The current stable version is Apache Guacamole 1.6.0, released on 22 June 2025 (source: Apache Guacamole release archive). Version 1.6.0 added improved rendering performance, better Docker support, configurable case sensitivity for usernames and support for Duo v4, among other things. The server (guacamole-server) and client (guacamole-client) components are released together under the same version number.

Security: authentication, MFA and no exposed target system

Guacamole connects flexibly to existing identities through extensions:

• Authentication: local database, LDAP/Active Directory.
• Multi-factor (MFA): TOTP (for example Google Authenticator, Aegis) and Duo.
• Single sign-on (SSO): SAML 2.0, OpenID Connect (OIDC), CAS and RADIUS.

On top of that come the architectural safeguards mentioned above: operation behind a reverse proxy and TLS, no directly exposed target systems and a complete connection history. Sessions can optionally be recorded. If you want to secure remote access cleanly along least-privilege lines, you combine Guacamole with role-based access and tamper-evident auditing, as we describe in RBAC and audit for remote access. For regulated environments this is the basis of NIS2-compliant remote access.

Typical use cases

• Industrial HMI access: reach machine and plant operator interfaces over VNC or RDP directly in the browser, with no software on the service device. More on this in VNC in the browser.
• Jump host / bastion: Guacamole as a central, logged entry point into protected networks, instead of scattered VPN access.
• Remote support and external contractors: time-limited, logged access for suppliers and machine builders, with no permanent VPN clients.
• Kubernetes: direct access to the console inside a container via the Kubernetes client.

In our ABCO Water Systems case study we show how browser-based remote access runs in production for distributed water treatment plants in Australia, including HMI access and secure site connectivity over WireGuard.

Open source: the Apache 2.0 license

Guacamole is released under the Apache License 2.0 and is therefore permanently free to use, with no per-user or per-device fees. As an Apache Software Foundation project, the source code is open, auditable and free of vendor lock-in. This is the core of sovereign remote maintenance: you run the gateway on your own or rented infrastructure and keep full control over access and data.

Apache Guacamole vs TeamViewer and AnyDesk

TeamViewer and AnyDesk are quick to set up, but route connections through the vendor cloud and tie you to their pricing and locations. As soon as data sovereignty, multi-tenancy or compliance requirements come into play, a self-hosted gateway like Guacamole is the more sustainable choice.

Running Apache Guacamole sovereignly

Guacamole is a strong building block, but a production operator portal needs more: hardened configuration, SSO integration, RBAC, auditing, secure site connectivity and reliable operations including CVE monitoring. That is exactly what we build and operate as a remote management platform, proven in production at ABCO Water Systems and nextGYM.

This article is general information and not legal advice. For a concrete assessment of NIS2 or IEC 62443 requirements, please seek qualified counsel.