Omnissa Horizon, formerly VMware Horizon, landed with Omnissa after the divestiture from Broadcom, and the roadmap uncertainty that surrounded that change has prompted a wave of “what do we actually depend on” reviews. As with any VDI reassessment, the useful question is not whether an open tool matches Horizon feature for feature, it plainly does not, but whether a chunk of your users were really using Horizon as a secure front door to RDP hosts. For those users, Apache Guacamole is a credible, much lighter replacement, as long as you are clear-eyed about the three things it leaves behind.
The honest scope of the swap
Apache Guacamole is a clientless HTML5 remote-access gateway made of two parts: a web application users open in a browser, and the guacd daemon that speaks RDP, VNC, and SSH to your targets. It replaces the Horizon Connection Server and Horizon clients in their access-tier role, delivering browser access to Windows session hosts and desktops without any installed endpoint agent.
It is not, and this must lead every conversation, a VDI broker in the provisioning sense. Guacamole brokers access to desktops that already exist. It does not create them, patch them, layer applications onto them, or manage user profiles. Everything Horizon did through instant clones, App Volumes, and Dynamic Environment Manager sits entirely outside Guacamole’s remit and needs an explicit home before you decommission the broker.
Horizon components and where they go
Put each Horizon building block next to its fate so nothing is discovered late:
- Connection Server becomes Guacamole plus your reverse proxy and identity provider: a browser front door with authentication moved to the gateway.
- Horizon clients become the Guacamole web app: clientless, browser-only access.
- Instant clones have no equivalent. Non-persistent provisioning stays on the hypervisor or moves to a streaming tool.
- App Volumes has no equivalent. Application layering must be solved by baking apps into images or another approach you own.
- Dynamic Environment Manager has no equivalent. Profiles and policy move to roaming profiles, an FSLogix-style container approach, or a comparable mechanism.
- Blast Extreme maps loosely to Guacamole’s RDP-over-HTML5. Fine for general use, not a tuned high-performance display protocol.
Three of those rows read “no equivalent.” If those three describe the heart of your deployment, Guacamole alone is not your answer for those users. If they describe features you barely touched, you are an excellent candidate.
Building the gateway in front of existing hosts
The gateway itself is small and quick to stand up. Deploy guacd and the web application, place them behind your reverse proxy with TLS, and register your existing Windows session hosts and desktops as RDP connections. Because those hosts are already running, there is no image work inside the Guacamole layer, which is exactly why the build is light.
The weight moves to authentication. Configure the web app against your SAML or OIDC identity provider and enforce MFA at the gateway, so every RDP session is authenticated and subject to conditional access before guacd opens a connection. You are now presenting RDP reachability through a browser, so the gateway hosts are perimeter security infrastructure and deserve the hardening, patching, logging, and access controls you would give any internet-facing service.
Piloting per group with eyes on the display gap
Pilot by user group and instrument the display experience specifically. Take a cohort whose need is genuinely secure access to existing RDP hosts, give them the Guacamole front door, and walk the whole path: identity provider login, MFA, connection brokering, session responsiveness, clipboard, file transfer, printing, and multi-monitor behavior. Measure it against their Horizon-on-Blast baseline honestly. General office workloads typically hold up well; sustained high-motion, 3D, or precision multi-monitor work is where browser RDP shows its limits, and that cohort may simply belong on a fuller platform. Expand group by group only as each cohort’s experience is validated.
The work Guacamole will never do for you
Two streams of work must have named owners before Horizon is retired, because the gateway will not absorb them. First, image and desktop lifecycle: creating, patching, and provisioning the session hosts and desktops behind Guacamole remains your hypervisor’s job or moves to a workspace-streaming tool. Instant clones do not have a Guacamole equivalent, so non-persistent provisioning is a decision, not a default. Second, profile and application management: with App Volumes and Dynamic Environment Manager gone, you need a concrete plan for how applications reach the desktops and how user profiles roam. These are the two items teams most often underestimate, and they are precisely the parts Horizon made invisible.
Weighing the move
Omnissa Horizon to Apache Guacamole works well for users whose real requirement was secure, clientless, audited access to existing RDP hosts, with identity and MFA enforced at the gateway. For them it strips out a broker, an installed client, and a subscription in exchange for a compact open-source gateway. It works poorly for users who depended on instant clones, App Volumes, or Dynamic Environment Manager, because Guacamole replaces none of those and expecting it to will stall the project. Plan image, provisioning, and profile management as separate workstreams with real owners, pilot the demanding display workloads before you commit them, run your own numbers through the calculator above treating each figure as illustrative rather than a vendor quote, and confirm your Windows and RDS licensing against your own agreement before counting any saving.