The gap between “interesting technology” and “production-ready infrastructure” is real, and it takes deliberate engineering to close it. Kasm Workspaces 1.19 is a release that closes several of those gaps at once - moving Kubernetes support from preview to Generally Available, hardening the networking layer with a native OpenZiti egress provider, and delivering a set of platform improvements that make Kasm Workspaces meaningfully easier to operate at scale.
This is not a release full of shiny features for the demo. It is a release built for teams who are running Kasm Workspaces in production and need the platform to grow with them.
Kubernetes Is Now Generally Available
For teams that have been watching Kasm’s Kubernetes support from a distance, 1.19 is the moment to look again.
Kubernetes deployment in Kasm Workspaces is now Generally Available. That means standardized backends, production-ready Helm charts, and Helm-based RDP Gateway configuration - all shipping as a supported, first-class deployment path. If your organization already runs workloads on Kubernetes, you now have a clean, declarative way to run Kasm Workspaces alongside them.
The practical implications go beyond just “it works now.” Helm-based deployment means your Kasm Workspaces configuration lives in version control. It means your infrastructure team can review workspace platform changes the same way they review application deployments - as code, in a pull request, with a traceable history. That is a different operational posture than a wizard-driven install, and it matters for compliance-focused environments.
Zero-Trust Egress with OpenZiti
Network access control is one of the more underappreciated dimensions of a workspace platform. You can isolate the session itself beautifully and still create exposure through permissive egress.
Kasm Workspaces 1.19 adds a native OpenZiti egress provider, giving administrators the ability to route workspace traffic through a software-defined zero-trust network fabric rather than relying on traditional VPN or firewall rules. OpenZiti connections are mutually authenticated, encrypted by default, and scoped to specific services - not the broad network access that VPNs typically grant.
For security teams that have been working toward a zero-trust architecture, this is a meaningful integration. It brings the egress layer into the same policy-driven model that governs the session itself.
Self-Service Diagnostics: Less Time Fighting the Platform
One of the quieter but consistently impactful investments in any platform is making it easier to understand what is happening when something goes wrong.
Version 1.19 introduces a self-service diagnostics and metrics system covering metrics collection and export, system health checks, and a support bundle generator. Administrators can now pull structured diagnostic data without needing to escalate to a support ticket or dig through logs manually. For teams running Kasm Workspaces as part of a larger observability stack, the metrics export feeds directly into existing monitoring pipelines.
This is the kind of work that does not generate excitement in a feature announcement but meaningfully reduces operational friction over time.
Configuration as Code, Done Properly
Kasm Workspaces 1.19 delivers a substantial refresh to configuration import and export. The improvements include table-level selection so you can export exactly what you need, UUID tokenization to make configs portable across environments, a sanitize option to strip environment-specific values, additive imports that merge rather than overwrite, and preset export modes for common scenarios.
Taken together, these changes make it practical to treat Kasm Workspaces configuration as a versioned artifact - something you can promote from development to staging to production, review in a diff tool, and roll back if needed. That is what “config as code” actually means in practice, and most platforms do not get there cleanly.
GPU Workloads and AI/ML Use Cases: MiG Support
Organizations running AI and ML workloads have increasingly needed a way to share expensive GPU resources across multiple container sessions without the overhead of full GPU passthrough. NVIDIA Multi-Instance GPU (MiG) partitioning solves that problem at the hardware level, but the platform delivering those sessions needs to understand MiG topology to take advantage of it.
Kasm Workspaces 1.19 adds native NVIDIA MiG support, so administrators can assign MiG slices to container sessions. This makes GPU-accelerated workspaces practical for larger teams where a single high-end card needs to serve multiple concurrent users - a common scenario in data science and ML engineering environments.
vSphere: Faster Provisioning with Instant Clones and CloudInit
For environments running Kasm Workspaces on VMware vSphere, 1.19 delivers two complementary improvements: Instant Clone support and CloudInit startup scripts.
Instant Clones reduce the time it takes to provision a new VM session by forking from a running parent VM rather than starting from a snapshot. CloudInit startup scripts let administrators run configuration logic at session start without baking everything into the base image. Together, these changes tighten the provisioning loop - meaning users spend less time waiting and infrastructure teams have more flexibility in how they manage session images.
Linux VMs via RDP, Windows Autoscale Fixes, and More
Version 1.19 also includes Phase 1 of Linux VM support via RDP, expanding the range of session types Kasm Workspaces can deliver beyond containers and Windows machines. Windows autoscale deployments now correctly use the Kasm Server Name as the hostname, resolving a long-standing friction point for teams managing larger Windows fleets.
On the infrastructure side: PostgreSQL has been updated from version 14 to a newer release, SQLAlchemy has been updated to 2.0, and Guacamole has been updated to version 1.6. Debian 13 (Trixie) is now a supported install and upgrade target.
The public exec_kasm API is available for teams that need programmatic control over session execution. Server Auto-Expiration lets administrators define a lifecycle for servers so they do not accumulate indefinitely. Rolling builds are now the default, improving release stability. The install script now supports copying existing SSL certificates at install time - a small thing that eliminates a common deployment friction point.
An Honest Assessment
1.19 is a release that rewards teams who are already invested in the platform. The Kubernetes GA milestone, the OpenZiti integration, and the configuration import/export overhaul are all changes that compound over time - they make the platform more operable, more auditable, and more adaptable to the infrastructure practices that serious engineering organizations already follow.
For teams evaluating Kasm Workspaces for the first time, 1.19 is also a meaningful moment. The Kubernetes deployment path being Generally Available means you are not adopting an experimental feature - you are adopting a supported, Helm-driven deployment model that integrates with the toolchain you already use.
Get Started
Upgrade instructions, Helm chart documentation, and the full 1.19 changelog are available at kasm.com/downloads.
If you are new to Kasm Workspaces, the documentation at kasmweb.com/docs is the right starting point.
About Kasm Workspaces
Kasm Technologies delivers a modern platform for secure, containerized desktop and application access. Kasm Workspaces streams browsers, desktops, and applications directly to users through ephemeral, policy-controlled sessions - eliminating the cost, rigidity, and risk of traditional VDI. Built by a team with deep roots in federal cybersecurity and offensive/defensive operations, Kasm is used by organizations ranging from government agencies to Fortune 500 companies to deliver secure, scalable developer and end-user environments.
Learn more at kasm.com.
