Introduction

What if you could stand up a fully isolated, browser-delivered AI development lab — running frontier models, quantized CPU inference, and collaborative workspaces — in less than an hour, on infrastructure that costs a fraction of traditional cloud VMs?

That’s exactly what this guide walks you through. We’re going to use Oracle Cloud Infrastructure (OCI), Ampere compute, and Kasm Workspaces (deployed straight from the OCI Marketplace) to build a production-grade AI lab that you can access from any browser, on any device, anywhere in the world.

By the end, you’ll have:

• ✅ Kasm Workspaces running on an Ampere instance (OCI)
• ✅ Workspace registries added for Calliope.AI and Scully’s Workspace Registry
• ✅ Frontier model workspaces ready to launch
• ✅ Quantized CPU model inference via Ollama + Hugging Face + the Ampere Model Zoo — no GPU required

Let’s build it.

Why Ampere + Kasm?

Before we dive in, here’s the short version of why this stack is worth your time:

Kasm Workspaces delivers fully isolated, ephemeral containerized desktops and applications through your browser. No VPN. No client software. No data left on your endpoint. Every session spins up clean and destroys itself on logout — which makes it ideal for AI development where you want controlled, reproducible environments.

Ampere on OCI gives you access to some of the best price-to-performance compute in public cloud. The A1 through A4 shapes offer up to 160 OCPUs and 1TB of RAM — purpose-built for cloud-native, multi-threaded workloads. For CPU-based LLM inference with quantized models (which is 90%+ of real-world AI workloads), Ampere’s architecture is genuinely excellent: INT8 and FP16 optimized, efficient per-core pricing, and no noisy-neighbor issues.

Combined: you get 4–8x container density vs. traditional VMs, 70–80% lower infrastructure cost vs. legacy VDI, and an AI lab that’s secure by design.

Navigate to the OCI Marketplace and Find Kasm

1.1 — Log into your OCI Console

Head to cloud.oracle.com and sign in. If you don’t have an account, Oracle’s Always Free tier includes 4 OCPUs + 24GB RAM on Ampere A1 — more than enough to start.

1.2 — Open the OCI Marketplace

From the main OCI Console navigation:

• Click the ☰ hamburger menu (top-left)
• Navigate to Marketplace → All Applications

Or use the search bar at the top of the Console and type Marketplace.

1.3 — Search for Kasm

In the Marketplace search bar, type:

Kasm

You’ll see several Kasm listings appear. Look for the Kasm Workspaces ARM listing — this is the one optimized for Ampere compute.

💡 Pro tip: Filter by ARM-compatible or Arm64 in the category/filter panel on the left to narrow results quickly.

1.4 — Select the Kasm ARM Instance

Click on the Kasm Workspaces (ARM) listing. Review the overview page — you’ll see the supported shapes, licensing model (Kasm has a free tier and paid tiers), and the “Launch Instance” button.

When you’re ready, click Launch Instance.

Step 2: Configure Your Instance — Shape, Placement & Details

This is where you define what your Kasm server actually looks like. Take your time here — the choices you make affect performance and cost.

2.1 — Name Your Instance

Give your instance a meaningful name:

kasm-ai-lab-01

2.2 — Choose Your Availability Domain and Fault Domain

Under Placement, select:

• Availability Domain — OCI regions have multiple ADs. For a single-node lab, AD-1 is fine. If you’re in a region with limited Ampere capacity, try AD-2 or AD-3.
• Fault Domain — Leave as default unless you have specific HA requirements.

💡 Ampere A1 shapes are in high demand in some regions. If you get a capacity error on one AD, try another — availability varies by region and time of day.

2.3 — Choose Your Ampere Shape

Under Shape, click Change Shape. You’ll see the Flexible Shapes section. Select:

Always Free eligibility: VM.Standard.A1.Flex with up to 4 OCPUs and 24 GB RAM qualifies for OCI's Always Free tier — enough to stand up Kasm and test a small quantized model. No credit card charges for staying within those limits.

OCPU ≠ vCPU: On A2 and A4, one OCPU equals 2 physical cores of the AmpereOne/AmpereOne M processor. When you configure 8 OCPUs on an A2 instance, you’re getting 16 physical ARM64 cores — keep this in mind when sizing for model inference throughput.

Recommended starting points by use case:

• Just exploring / free tier: VM.Standard.A1.Flex — 4 OCPUs / 24 GB
• Personal AI lab with Ollama: VM.Standard.A2.Flex — 8 OCPUs / 64 GB
• Multi-user lab or larger models (13B–34B): VM.Standard.A2.Flex — 16 OCPUs / 128 GB
• Production / latest silicon: VM.Standard.A4.Flex — check regional availability first

OCI’s Ampere instances use per-OCPU pricing — you pay for exactly what you configure, and you can resize the OCPU and RAM counts independently without redeployment.

Step 3: Build Out the Network and Sandbox

Don’t skip past this section in the wizard — networking is configured here, before you set your boot volume and SSH key, and getting it right now saves you from having to dig into security rules after the fact.

3.1 — VCN (Virtual Cloud Network) Setup

The OCI Marketplace launcher will offer to create a new VCN automatically — you can accept that for a quick start. If you’re deploying into an existing VCN, make sure it has:

• A public subnet with an Internet Gateway attached
• A route table with a default route to the Internet Gateway (0.0.0.0/0)
• A DHCP Options set pointing to OCI’s DNS resolvers

3.2 — Security List / Network Security Group Rules

Open the Security List attached to your subnet and add the following Ingress Rules:

🔒 Security note: For a personal lab, consider restricting port 443 to your IP range rather than the open internet (0.0.0.0/0). For team access, you’ll want to keep it open or place OCI’s Load Balancer in front.

3.3 — Now Configure Boot Volume

With networking sorted, scroll down to the Boot Volume section:

• Set boot volume size to at least 100 GB — Kasm pulls container images and you’ll want the headroom
• Enable In-Transit Encryption if you have compliance requirements
• Keep VPU (Volume Performance Units) at Balanced unless you need higher IOPS for heavy model workloads

3.4 — SSH Key Pair

Upload or paste in your public SSH key. You’ll need this for initial shell access and any post-deployment configuration. Store the private key securely — this is your admin lifeline if you ever need to get into the instance directly.

💡 If you don’t have a key pair yet, the OCI Console can generate one for you and download the private key. Keep that .pem file somewhere safe.

3.5 — Review and Launch

Click Create. OCI will provision the instance in 3–5 minutes. Watch the state move from Provisioning → Running — once it’s green you’re ready.

3.6 — Firewall Check on the Instance

OCI security lists handle cloud-level traffic, but the OS has its own firewall as a second layer. SSH into your instance once it’s running and verify:

sudo firewall-cmd --list-all
# or if using iptables:
sudo iptables -L -n

Kasm’s Marketplace image typically handles this automatically, but it’s worth a 30-second confirmation.

3.7 — First Login to the Kasm Console

Open your browser and navigate to:

https://<YOUR-OCI-INSTANCE-PUBLIC-IP>

You’ll land on the Kasm login page. Default credentials are set during Marketplace deployment — check your OCI instance Console Connection or the Marketplace deployment output for the initial admin password.

3.8 — Harden the Sandbox

Before adding any workspaces, do a quick hardening pass:

• Change the default admin password immediately
• Set up a second admin account as backup
• Under Settings → Authentication, enable MFA if this instance is internet-exposed
• Review Kasm’s built-in DLP controls — clipboard restrictions, watermarking, and download blocking are available out of the box and worth enabling for any AI workspaces that will touch sensitive data

Step 4: Add Workspace Registries and Build Your AI Lab

This is where it gets exciting. Kasm’s Workspace Registry system lets you pull in curated catalogs of containerized environments — including AI/ML workspaces, secure browsers, development tools, and more — with a single URL.

We’re going to add two key registries:

• Calliope.AI Workspace Registry — AI-focused workspaces, frontier model interfaces, and intelligent tooling( Also supports Ollama)
• Scully’s Workspace Registry — Community-curated workspaces including development environments, AI tools, and utilities

4.1 — Navigate to Workspace Registries

In the Kasm Admin Console:

• Go to Workspaces → Workspace Registry
• Click Add Registry

4.2 — Add the Calliope.AI Registry

https://calliopeai.github.io/calliope-kasm/

Calliope AI Registry and click Add.

4.3 — Add Scully’s Workspace Registry (OpenClaw Workspace + Unreal)

https://sullyschoice.github.io/kasm-registry/

Scully's Registry and click Add.

4.4 — Browse and Install Workspaces

Once both registries are added, click View Workspaces on each registry. You’ll see a catalog of available environments. Install the ones relevant to your AI lab:

Calliope Workspaces or Kasm workspaces Ubuntu DND support

• Frontier model interfaces (Claude, ChatGPT, Gemini browser-isolated workspaces)
• Jupyter/VS Code environments pre-configured for AI development
• Ollama workspace for local quantized inference
• Open-WebUI or equivalent chat UI workspaces

Click Install on each workspace you want available to your users.

Click Install on each workspace you want available to your users.

4.5 — Configure Workspace Permissions (Critical for Path B)

⚠️ Don’t skip this step if you’re going the Ollama or Docker route. Kasm workspaces run as unprivileged users by default — which is exactly what you want for browser isolation and frontier model access. But if you’re planning to install Ollama, run Docker containers inside your workspace, or pull and serve quantized models, you need to explicitly grant elevated permissions before the workspace will cooperate.

In the Kasm Admin Console, go to Workspaces and click the Edit (pencil) icon on any workspace you intend to use for AI inference.

Enable Sudo / Root Access:

Scroll to the Advanced tab inside the workspace editor. Under Docker Run Config Override, make sure the following is set:

{
  "user": "root"
}

Or alternatively, under the Permissions section, toggle Allow Sudo to ON. This grants the workspace user sudo access inside the container session — required for Ollama's install script and any package installs (apt, pip, curl-based installers).

🔒 Security note: Only enable sudo/root on workspaces explicitly designated for AI development. Keep your browser-isolation and frontier model workspaces locked down with default unprivileged settings. Scope the elevated access — don’t apply it globally.

Enable Docker-in-Docker (for easier model deployment):

For workspaces where you want to run Docker containers inside the Kasm session — for example, pulling Open-WebUI, running a llama.cpp server container, or spinning up a full inference stack — you need to enable privileged mode and bind the Docker socket.

In the same Advanced → Docker Run Config Override field:

"user": "root",
"privileged": true,
"volumes": ["/var/run/docker.sock:/var/run/docker.sock"]
}

This mounts the host Docker socket into the workspace container, giving you full docker CLI access from inside the session. You can now run docker pull, docker run, and docker compose directly — making it dramatically easier to deploy multi-container AI stacks like Ollama + Open-WebUI without leaving the workspace.

💡 Why Docker-in-Docker matters here: Instead of manually installing Ollama via shell script and managing the process yourself, you can use pre-built Docker Compose stacks from the community — pull them into your workspace, docker compose up, and have a full inference UI running in under two minutes. The Ampere Model Zoo and many Hugging Face model repos ship with ready-made Compose files that just work.

Running AI Workloads: Two Paths

Once your workspaces are live, you have two main approaches for running AI models in your lab:

Path A — Frontier Models via Workspace Isolation

Use Kasm workspaces as isolated, controlled containers for accessing frontier AI services (Claude, ChatGPT, Gemini, Perplexity, etc.) Use Calliope Workspaces or Kasm Ubuntu DND:

• Every session is ephemeral — no data persists after logout
• DLP controls prevent accidental data leakage to external APIs
• Session recording gives you an audit trail of all AI interactions
• Works perfectly on ARM64 since these are browser-delivered services — no local compute needed

This is ideal for teams who need governed access to commercial AI tools without the risk of proprietary data being sent to external services unchecked.

Path B — Quantized CPU Inference on Ampere (No GPU Required)

This is where Ampere ARM64 genuinely shines. Modern quantized models (GGUF format, INT4/INT8 quantization) run surprisingly well on high-core-count ARM CPUs — and Ampere is purpose-built for exactly this workload.

Using Ollama:

Ollama makes pulling and running quantized models trivially easy. From within your Kasm workspace:

# Install Ollama (ARM64 binary available)
curl -fsSL https://ollama.com/install.sh | sh

# Pull a quantized model
ollama pull llama3.2:3b          # 2GB, great for fast inference
ollama pull mistral:7b-instruct  # 4.1GB, strong general assistant
ollama pull qwen2.5:14b          # 9GB, excellent reasoning

# Run it
ollama run llama3.2:3b

💡 On an A2.Flex with 8 OCPUs / 64GB RAM, you can comfortably run 7B–14B parameter models at INT4/INT8 quantization with solid token/sec throughput — all on CPU, zero GPU cost.

or build a File mapping or Script

cat << 'EOF' > start_ollama.sh
#!/bin/bash

# 1. Install Ollama
echo "Installing Ollama..."
curl -fsSL https://ollama.com/install.sh | sh

# 2. Start Ollama server in the background
echo "Starting Ollama server..."
# OLLAMA_HOST=0.0.0.0 allows connections from outside the container if needed
OLLAMA_HOST=0.0.0.0 ollama serve > ollama.log 2>&1 &

# 3. Wait for the server to be ready
echo "Waiting for server to initialize..."
until curl -s http://localhost:11434/api/tags > /dev/null; do
  sleep 2
done
echo "Ollama is up and running!"

# 4. Pull the Qwen models
echo "Pulling qwen3:8b..."
ollama pull qwen3:8b

echo "Pulling llama3.2:latest..."
ollama pull llama3.2:latest


echo "---------------------------------------"
echo "All set! Models are ready to use."
ollama list
EOF

# Make it executable and run it
chmod +x start_ollama.sh
./start_ollama.sh

From the Ampere Model Zoo:

Ampere maintains an optimized model zoo at solutions.amperecomputing.com with models specifically benchmarked and tuned for their silicon. Look for:

• LLaMA family — Optimized GGUF builds
• Mistral / Mixtral — Excellent performance per core
• Phi-3 / Phi-4 — Microsoft’s small, efficient models that punch above their weight on ARM
• Qwen2.5 — Strong multilingual and coding performance

From Hugging Face (with llama.cpp / Ollama backend):

# Using the HuggingFace CLI to pull GGUF models directly
pip install huggingface_hub
huggingface-cli download \
  bartowski/Llama-3.2-3B-Instruct-GGUF \
  --include "*.Q4_K_M.gguf" \
  --local-dir ./models

Then point Ollama or a llama.cpp server at the downloaded model file for inference.

Putting it together — Open-WebUI as your AI Lab frontend:

# Run Open-WebUI connected to your local Ollama instance
docker run -d \
  --network=host \
  -e OLLAMA_BASE_URL=http://127.0.0.1:11434 \
  -v open-webui:/app/backend/data \
  --name open-webui \
  ghcr.io/open-webui/open-webui:main

Access it at http://localhost:8080 from within your Kasm workspace — you now have a full ChatGPT-style interface running entirely on your Ampere instance, with no API keys, no usage limits, and no data leaving your OCI environment.

What You’ve Built

Let’s take stock of what’s running:

OCI Ampere ARM64 Instance (VM.Standard.A2.Flex or better)
    └── Kasm Workspaces (from OCI Marketplace)
            ├── Calliope.AI Registry Workspaces
            │       ├── Frontier Model Interfaces (isolated)
            │       └── AI Development Environments
            ├── Scully's Registry Workspaces
            │       ├── Dev Tools & Utilities
            │       └── Custom AI Workspaces
            └── Local Inference Stack
                    ├── Ollama (ARM64)
                    ├── Quantized Models (GGUF / INT4/INT8)
                    │       ├── Ampere Model Zoo Optimized Builds
                    │       └── Hugging Face GGUF Downloads
                    └── Open-WebUI (Chat Interface)

Next Steps & Resources

• 🔗 Kasm Workspaces Docs: kasmweb.com/docs
• 🔗 OCI Ampere Always Free: oracle.com/cloud/free
• 🔗 Ampere Model Zoo: solutions.amperecomputing.com
• 🔗 Ollama Model Library: ollama.com/library
• 🔗 Hugging Face GGUF Models: huggingface.co/models?library=gguf
• 🔗 Calliope.AI Registry: Calliope.Ai Workspace Registry link
• 🔗 Scully’s Workspace Registry: Scully’s OpenClaw Workspace
• 🔗 Kasm Helm Chart (for Kubernetes deployments): github.com/kasmtech/kasm-helm

Direct internet access from user endpoints is one of the highest-impact attack vectors in enterprise environments. A single malicious link, clicked from a corporate laptop, can be the entry point for ransomware, credential theft, or a supply chain compromise. Traditional defenses (proxies, URL filtering, endpoint AV) reduce the likelihood of that click causing harm, but they don’t eliminate the underlying problem: the browser executes untrusted code directly on the endpoint.

Browser isolation takes a different architectural approach. Instead of trying to make the local browser safe, you move it off the endpoint entirely.

This post covers how to combine F5 BIG-IP as an explicit forward proxy with Kasm Workspaces browser isolation to achieve seamless, transparent redirection of all web traffic through isolated, containerized browser sessions, without modifying how users browse.

What is Kasm Workspaces?

Kasm Workspaces is a platform that streams browser sessions and desktops to users directly from isolated Docker containers running on a server. Instead of executing web content locally, the user’s device receives only a pixel stream of the remote session. All browsing activity, including JavaScript execution, file downloads, and media rendering, happens inside the container, completely separated from the endpoint. Sessions are ephemeral by default, meaning each session starts from a clean state and leaves nothing behind when it ends.

The Architecture at a Glance

Before jumping into configuration, it’s worth understanding what this setup actually does and why each component exists.

What Is Browser Isolation?

With Kasm Workspaces, users don’t browse the internet from their local device. Instead, they interact with a remote, containerized browser session running on a Kasm server. The local browser renders a pixel stream of that session. All web content (JavaScript, CSS, media, executables) is processed inside the container, never on the endpoint.

The user experience is essentially unchanged. But the execution environment is completely different.

What Is Seamless Browsing?

Seamless browsing is the redirection mechanism that makes this transparent to the user. The flow looks like this:

1. A user enters a URL in their local browser.
2. The request is intercepted by the F5 forward proxy.
3. F5 applies an iRule that redirects the request to Kasm’s /go endpoint, passing the original URL as a parameter.
4. The user authenticates to Kasm (if not already logged in).
5. Kasm launches the user’s default workspace (like Chrome or Firefox).
6. The isolated browser automatically navigates to the originally requested site.

From the user’s perspective, they clicked a link and a webpage opened.

The Kasm /go Endpoint

Kasm provides a special endpoint that acts as the entry point for seamless redirection:

https://kasm.company.local/#/go?kasm_url=<destination-url>

When a request hits this URL, Kasm automatically launches the configured default workspace for that user or group and opens the destination URL inside the containerized session.

To configure the default workspace on Kasm, navigate to Access Management → Groups → Edit Group → Settings. Click Add Settings and add the default_image setting, selecting the workspace you want launched for that group. Once set, any request to the /go endpoint will automatically spin up that workspace and navigate to the specified URL.

F5 BIG-IP Architecture for Forward Proxy

The F5 deployment uses several cooperating components. Understanding how they fit together matters before you touch the configuration.

Key points:

• Explicit Forward Proxy Virtual Server: The main entry point. Listens on port 3128 on an internal IP. Clients configure their browser proxy settings to point here.
• DNS Resolver: Handles domain name resolution for all proxied traffic. Configured with a forward zone to send all DNS queries to an upstream resolver.
• Internal TCP Tunnel (tcp-forward profile): An internal tunnel interface that carries proxied traffic from the forward proxy VS to the wildcard virtual servers for further processing.
• Wildcard HTTP Virtual Server: Handles plain HTTP traffic on port 80 from within the tunnel. Applies the redirect iRule.
• Wildcard SSL Virtual Server: Handles HTTPS traffic on port 443 from within the tunnel. SSL Forward Proxy is enabled here, allowing F5 to decrypt, inspect, and redirect HTTPS traffic.

The SSL virtual server is the most important piece for HTTPS. Without SSL Forward Proxy, F5 cannot inspect the contents of encrypted requests, and seamless redirection to Kasm will not work for HTTPS sites.

SSL Forward Proxy: How It Works

When an HTTPS request arrives at the Wildcard SSL VS, F5:

1. Presents a dynamically generated certificate to the client, signed by a local CA you create on BIG-IP. The SSL connection is then established provided that the client already trusts the BIG-IP’s CA
2. Decrypts the client traffic using the Client SSL profile.
3. Inspects the plaintext HTTP request and applies the iRule redirect logic.
4. Redirects the client to the Kasm /go endpoint.

Because F5 is generating certificates on the fly and signing them with its own CA, clients must trust that CA. This is a hard requirement. Any client that does not trust the F5 CA will receive SSL certificate errors for every HTTPS site.

In Active Directory environments, the CA certificate can be distributed via Group Policy. In smaller deployments, it can be installed manually.

Step-by-Step Configuration

Step 1: Create the CA Certificate for SSL Forward Proxy

Navigate to: System → Certificate Management → Traffic Certificate Management → SSL Certificate List

Click Create and generate a new self-signed certificate. This certificate will be used by F5 to sign dynamically generated certificates for intercepted HTTPS traffic.

After creation, download the certificate. You’ll need to install it as a trusted root CA on all client machines.

Step 2: Create the DNS Resolver

Navigate to: Network → DNS Resolvers → DNS Resolver List

Click Create, give the resolver a name, and leave defaults.

After creating the resolver, click into it and go to the Forward Zones tab. Click Add:

• Name: . (a single dot; this forwards all DNS queries)
• Nameserver Address: Your preferred DNS server (e.g., 8.8.8.8)
• Service Port: 53

Click Finished.

Step 3: Create the TCP Forward Tunnel

Navigate to: Network → Tunnels → Tunnel List

Click Create:

• Name: tcp_forward_tunnel
• Profile: tcp-forward

Leave all other settings at defaults and click Finished. This creates the internal tunnel interface that carries traffic from the explicit proxy VS to the wildcard virtual servers.

Step 4: Create the HTTP Explicit Proxy Profile

Navigate to: Local Traffic → Profiles → Services

Click Create:

• Name: Choose a descriptive name (e.g., http_explicit_proxy)
• Parent Profile: http-explicit
• Proxy Mode: Explicit

Enable the Custom checkbox and scroll to the Explicit Proxy section:

• DNS Resolver: Select the resolver you just created
• Tunnel Name: tcp_forward_tunnel

Click Finished.

Step 5: Create the Client SSL Forward Proxy Profile

Navigate to: Local Traffic → Profiles → SSL → Client

Click Create:

• Name: Choose a descriptive name
• Parent Profile: clientssl

Scroll to SSL Forward Proxy and enable the Custom checkbox:

• SSL Forward Proxy: Enabled
• CA Certificate: Select the CA certificate created in Step 1
• CA Key: Select the corresponding private key
• Certificate Lifespan: 30 (days, or adjust per your policy)
• SSL Forward Proxy Bypass: Enabled
• Bypass Default Action: Intercept

Click Finished.

Step 6: Create the Server SSL Forward Proxy Profile

Navigate to: Local Traffic → Profiles → SSL → Server

Click Create:

• Name: Choose a descriptive name
• Parent Profile: serverssl

Enable the Custom checkbox under Configuration:

• Certificate: Select the CA certificate
• Key: Select the corresponding key
• SSL Forward Proxy: Enabled
• SSL Forward Proxy Bypass: Enabled

Click Finished.

Note: The Server SSL profile is required by BIG-IP when SSL Forward Proxy is in use, even though it doesn’t perform significant processing in this flow. It must be attached to the SSL virtual server or the configuration will not be valid.

Step 7: Create the Kasm Redirect iRule

Navigate to: Local Traffic → iRules → iRule List

Click Create and name it Kasm_Redirect_iRule. Paste the following iRule:

when HTTP_REQUEST {
 # Extract the original URL
 set scheme "https"
 if { [TCP::local_port] == 80 } {
 set scheme "http"
 }
 
 set original_url "${scheme}://[HTTP::host][HTTP::uri]"
 
 # Log for debugging (optional)
 log local0. "Redirecting: $original_url to Kasm"
 
 # Redirect to Kasm workspace
 HTTP::redirect "https://kasm.company.local/#/go?kasm_url=$original_url"
}

What this does:

• Triggers on every inbound HTTP request.
• Determines the original scheme based on the local port (80 = HTTP, anything else = HTTPS).
• Reconstructs the full original URL from the host header and URI.
• Issues an HTTP redirect to the Kasm /go endpoint with the original URL encoded as a query parameter.

Replace kasm.company.local with your actual Kasm FQDN.

This is a minimal implementation. In production, you’ll likely want to add bypass logic for internal domains, trusted SaaS applications, or other traffic that should not be redirected to Kasm.

Click Finished.

Step 8: Create the Explicit Forward Proxy Virtual Server

Navigate to: Local Traffic → Virtual Servers → Virtual Server List

Click Create:

• Type: Standard
• Destination Address/Mask: Your internal subnet (e.g., 10.0.0.0/24)
• Service Port: 3128
• Protocol: TCP
• Protocol Profile (Client): tcp
• Protocol Profile (Server): tcp
• HTTP Profile (Client): Your HTTP Explicit Proxy profile
• VLAN and Tunnel Traffic: Enabled on: tcp_forward_tunnel
• Source Address Translation: Auto Map
• iRules: Kasm_Redirect_iRule

Click Finished.

Using an internal subnet range (not a public IP) for the destination address is strongly recommended. Exposing an explicit forward proxy on a public IP attracts automated abuse traffic.

Step 9: Create the Wildcard SSL Virtual Server

Navigate to: Local Traffic → Virtual Servers → Virtual Server List

Click Create:

• Type: Standard
• Destination Address/Mask: 0.0.0.0/0
• Service Port: 443
• Protocol: TCP
• Protocol Profile (Client): tcp
• Configuration: Advanced
• HTTP Profile (Client): http
• SSL Profile (Client): Your Client SSL profile
• SSL Profile (Server): Your Server SSL profile
• VLAN and Tunnel Traffic: Enabled on: tcp_forward_tunnel
• Source Address Translation: Auto Map
• Address Translation: Disabled
• iRules: Kasm_Redirect_iRule

Click Finished.

The 0.0.0.0/0 destination combined with tunnel-only VLAN binding ensures this virtual server matches all HTTPS destinations forwarded through the internal tunnel, without being reachable from outside.

Step 10: Create the Wildcard HTTP Virtual Server

Navigate to: Local Traffic → Virtual Servers → Virtual Server List

Click Create:

• Type: Standard
• Destination Address/Mask: 0.0.0.0/0
• Service Port: 80
• Protocol: TCP
• Protocol Profile (Client): tcp
• Configuration: Advanced
• HTTP Profile (Client): http
• VLAN and Tunnel Traffic: Enabled on: tcp_forward_tunnel
• Source Address Translation: Auto Map
• Address Translation: Disabled
• iRules: Kasm_Redirect_iRule

Click Finished.

F5 configuration is now complete.

Client Configuration

Install the CA Certificate

The F5 CA certificate must be trusted by every client that will use the forward proxy for HTTPS traffic.

Manual installation (Windows):

1. Press Win + R, type certmgr.msc, and press Enter.
2. Navigate to Trusted Root Certification Authorities → Certificates.
3. Right-click and select Import.
4. Browse to the CA certificate downloaded from F5 and complete the wizard.

For domain-joined environments, you can distribute the certificate via Group Policy (GPO). This ensures all domain machines automatically trust the F5 CA without manual intervention.

Configure Windows/Browser Proxy Settings

Navigate to Settings → Network & Internet → Proxy → Manual proxy setup:

• Proxy IP: The internal IP address of your F5 BIG-IP (check Network → Self IPs in the F5 management interface)
• Port: 3128
• Exceptions: Add your Kasm FQDN and any other addresses that should bypass the proxy (e.g., internal management interfaces)

Click Save.

All outbound web traffic from the browser is now routed through the F5 forward proxy.

For enterprise deployments, manually configuring proxy settings on each machine is not practical. A common approach is to use a PAC (Proxy Auto-Config) file hosted on an internal web server and distribute it to clients automatically via DHCP option 252. When a client receives this DHCP option, the browser picks up the PAC file URL and applies the proxy configuration without any manual steps. This also gives you a centralized place to define bypass rules for internal domains, rather than managing exceptions per machine.

Verifying the Setup

With the proxy configured and the CA certificate trusted, open any browser and navigate to an external URL. The sequence of events:

1. The browser sends the request to F5 on port 3128.
2. F5 decrypts the traffic (for HTTPS), applies the iRule, and issues a redirect to https://kasm.company.local/#/go?kasm_url=<original-url>.
3. The browser follows the redirect to Kasm.
4. After authentication, Kasm launches the default workspace for the user’s group.
5. The isolated browser session opens the originally requested URL.

From the user’s perspective: they navigated to a URL and it opened. The redirect, authentication, and container launch all happen in the background.

Security Considerations

Proxy exposure: Keep the forward proxy virtual server bound to an internal IP. Avoid exposing port 3128 on a public IP, as it will be abused.

CA certificate distribution: The F5 CA must be trusted before SSL traffic will work correctly. Plan your deployment method (GPO vs. manual) based on your environment before rollout.

iRule bypass logic: The example iRule redirects everything. In practice, you should add bypass conditions for:

• Internal domains and SaaS applications that don’t require isolation
• Kasm itself (to avoid redirect loops)
• Any URLs that cannot function correctly inside an isolated container

Session stickiness: If users need persistent sessions in Kasm (e.g., authenticated sessions on specific sites), configure Kasm workspace persistence accordingly. Ephemeral containers are more secure but require users to re-authenticate to sites on each session.

Conclusion

Integrating F5 BIG-IP’s explicit forward proxy with Kasm Workspaces browser isolation is a defensible, operationally practical approach to eliminating direct endpoint internet access. The architecture is straightforward: intercept all web traffic at F5, redirect it to Kasm’s /go endpoint, and let Kasm handle execution in isolated containers.

The configuration involves several cooperating components (DNS resolver, TCP tunnel, explicit proxy profile, SSL Forward Proxy profiles, wildcard virtual servers, and a redirect iRule), but each serves a specific role and the overall design is coherent once the data flow is understood.

For organizations looking to move beyond perimeter filtering toward genuine endpoint isolation, this stack provides a solid foundation.

In early 2026, Google issued an emergency patch for CVE-2026–2441, a zero-day vulnerability buried deep inside Chrome’s CSS rendering engine. The exploit required nothing unusual from the victim. A user visited a page. Chrome rendered it. The CSS engine did the rest, triggering memory corruption during what looked like ordinary browsing.

That framing matters. This wasn’t an attack that relied on a user making a mistake. It operated at a layer most enterprise defenses don’t reach.

But before you reach for the next layer of endpoint tooling, consider whether the architecture itself (not just the tooling) needs to change.

When the Runtime Becomes the Threat

Modern browsers are not simple applications. They are effectively operating systems, parsing and executing HTML, CSS, JavaScript, WebAssembly, fonts, media codecs, and GPU-accelerated rendering pipelines in real time, against content pulled from untrusted corners of the internet.

CVE-2026–2441 exploited this reality. The vulnerability lived inside the browser’s native rendering engine, and a valid-looking page from an otherwise legitimate compromised website was enough to trigger it. The traffic looked normal. The domain may have been trusted. The browser just rendered the page and the exploit ran.

That’s the nature of engine-level zero-days. The browser’s own code becomes the weapon.

Why Your Existing Stack Couldn’t See It Coming

Most enterprise browser security stacks are built around a shared assumption: that the browser runtime itself remains trustworthy.

• Secure Web Gateways evaluate domains, IPs, and traffic signatures. CVE-2026–2441 was delivered as valid HTML and CSS, with nothing anomalous to catch.
• Browser extensions operate within the browser’s extension APIs and have no visibility into memory allocation or rendering engine internals, by design.
• EDR agents can detect post-exploitation behavior, but exploitation here happens inside a trusted process executing complex code all day long.

These are good tools solving real problems. They just operate within the same failure domain as the browser itself. If the browser is compromised, they’re all riding that same sinking ship.

The deeper issue isn’t that these tools failed. It’s that they were never designed to handle a compromise of the platform they run on.

The Architectural Answer: Isolation

If you can’t reliably prevent engine-level vulnerabilities (and history tells us you can’t, given the patch cadence of every major browser vendor), the next best thing is to contain them.

This is the premise behind browser isolation architectures: assume the browser will be compromised, and design so that compromise doesn’t matter much.

In an isolated model:

• The browser executes in a segmented environment away from the user’s physical endpoint.
• Network access from that environment is explicitly controlled.
• Sensitive internal systems aren’t directly reachable from the browsing session.
• Sessions are ephemeral, reset to a known-good state after each use.

Arbitrary code execution in the browser becomes a contained event rather than a beachhead into your environment.

This is where Kasm Workspaces enters the picture.

How Kasm Workspaces Reframes the Browser Security Problem

Kasm Workspaces is a container-native streaming platform that delivers browser sessions (and full desktops) from isolated containers directly to users’ screens. The user sees and interacts with a browser. But that browser runs inside a Docker container on a server, not on the user’s device.

The user’s endpoint receives only a pixel stream. The entire browser stack runs server-side: the DOM, the JavaScript engine, the CSS renderer. None of it touches the endpoint.

Here’s why that matters for CVE-2026–2441 specifically:

The Exploit Stays in the Container

With Kasm, the Chrome instance processing that malicious CSS runs inside an ephemeral container on a Kasm server, not on your employee’s laptop or corporate desktop. Even if CVE-2026–2441 achieves arbitrary code execution, the attacker is running code inside a container with no access to:

• The user’s local file system
• Cached credentials or session tokens on the endpoint
• Corporate VPN connections
• Internal network segments not explicitly routed to the container

The blast radius is fundamentally smaller because the execution environment is fundamentally separated.

Sessions Are Ephemeral by Design

Kasm’s container model is inherently disposable. When a browsing session ends, the container is destroyed. Any foothold the attacker established, whether modified files, planted malware, or injected processes, evaporates with it. There is no persistent state to harvest later.

This directly addresses one of the core CISO questions raised by CVE-2026–2441: Can browsing environments be quickly reset or destroyed to eliminate persistence? With Kasm, the answer is yes, by default, every session.

Network Segmentation Is Architectural, Not Bolted On

Kasm allows administrators to define granular network policies for each workspace. A general internet browsing container can be firewalled away from internal resources entirely. An employee browsing the open web for research doesn’t need a path to your ERP system or Active Directory, and with Kasm, they won’t have one.

This aligns directly with the least-privilege and segmentation principles that zero-trust frameworks demand but that traditional browser deployments consistently fail to deliver. The browser has always had too much access to too many things. Kasm makes that access explicit and controllable.

Flexible Deployment for Enterprise Needs

Kasm can be deployed on-premises, in your own cloud environment, or as a managed service, which matters for organizations with data residency requirements or compliance obligations. It supports a range of workspace types:

• Isolated browser sessions for general web access
• Full containerized desktops for sensitive workflows
• Application streaming for specific apps that need web access without exposing the endpoint

Want to see it in action? This demo link opens a live Kasm Chrome session right in your browser, no account or install needed, try it out: https://app.kasm.com/#/cast/chrome-casting

Evaluating Your Posture

CVE-2026–2441 is not an outlier. Browser engines receive frequent high-severity patches. Active exploitation in the wild has become routine. The time between vulnerability disclosure and weaponization continues to compress.

Security leaders should honestly assess their browser security posture against three questions:

1. Assumption of Compromise: Does your architecture account for the possibility that the browser is already exploited?
2. Blast Radius Control: If exploitation occurs today, what systems and credentials are immediately reachable from the browser process?
3. Session Containment and Reset: Can you destroy a potentially compromised browsing environment and restore a clean one in minutes?

If the honest answers are “no,” “too many,” and “not really,” the gap isn’t in your tooling. It’s in your architecture.

Conclusion

CVE-2026–2441 is a useful lens for evaluating a truth the security industry has long understood but often underweighted: browsers are exposed execution environments processing untrusted content, and they will have exploitable vulnerabilities.

The organizations that will weather the next engine-level zero-day most effectively are not necessarily those with the most tools. They’re the ones whose architecture assumes browsers can be compromised and designs accordingly: limiting what a compromised browser can reach, ensuring sessions leave no lasting foothold, and separating browsing execution from the endpoint entirely.

Kasm Workspaces is one of the most operationally practical ways to get there. It doesn’t ask you to replace your existing security stack. It asks you to rethink where the browser runs and what it can touch, and provides the infrastructure to do that at enterprise scale.

Kasm’s community edition is free to self-host. If you want to stand up your own instance, the single-server install gets you a working environment in well under 20 minutes: https://docs.kasm.com/docs/install/single_server_install

When browsing Rancher’s Apps and Charts catalog, you will see two Kasm-related charts available: Kasm and Kasm Demo. For any evaluation, testing, or real-world use, the Kasm chart is the recommended option. The Kasm Demo chart is an older variant and is not recommended.

In this walkthrough, we will use the standard Kasm Helm chart.

Prerequisites

The Kasm Helm chart expects an SSL certificate to be provided for ingress. If you already have a certificate signed by a trusted certificate authority, you can use that. Otherwise, a self-signed certificate can be generated using OpenSSL on any VM or local machine.

Use the following OpenSSL command to generate your own self-signed certificate and private key. Refer to the SSL cert instructions our Helm Chart GitHub repo for more information.

openssl req -x509 -nodes -days 365 -newkey rsa:2048 \
  -keyout tls.key -out tls.crt \
  -subj "/CN=kasm.example.com/O=Kasm Self-Signed"

Once the certificate and private key are generated, the next step is to create a dedicated Kubernetes namespace for Kasm. This namespace is required before creating secrets. Open a shell on Rancher and execute the following command to create a kasm namespace.

kubectl create ns kasm

Once the namespace is created, go to “Storage” → “Secrets” → “Create” and select “TLS Certificate”.

Over here, paste the generated Private Key and Certificate content and click “Create”.

Installing the Kasm Helm Chart

With the namespace and TLS secret in place, the Kasm chart can now be installed from Rancher.

Go to the Kasm Chart on Rancher, and click “Install”.
During installation, a few required fields must be configured:

• The public address where the Kasm control plane will be accessible
• The name of the TLS certificate secret
• Ingress settings, typically using a ClusterIP service when ingress is enable

These values are the minimum required to get the chart up and running. For more advanced configuration and additional options, go to the “Edit YAML” tab. All available settings are documented in the values.yaml file on our GitHub repo, along with descriptions and example configurations.

Finally, click “Install” and the Kasm pods will initialize. It is normal for some pods to remain in an init state for a few minutes.

Accessing the Kasm Control Plane

After all pods are running, the Kasm web interface becomes accessible at the configured hostname. If a self-signed certificate was used, the browser will display a security warning. This does not occur when using a properly signed certificate.

Administrative credentials and other secret values can be retrieved directly from Rancher shell. The Kasm Helm Chart’s release notes on Rancher provide commands to extract the admin password and other credentials.

For example, you can run this command to extract your Kasm Admin Password:

kubectl get secret --namespace kasm kasm-secrets -o jsonpath="{.data.admin-password}" | base64 -d

You can then login to your Kasm deployment with the default Admin username admin@kasm.local and the retrieved password.

Once the Kasm control plane is online, sessions cannot be launched until compute resources are connected. Kasm supports multiple resource types, allowing administrators to choose the delivery model that best fits their environment.

Kasm can broker sessions to existing infrastructure such as machines running SSH, VNC, RDP, or KasmVNC. This makes it easy to integrate Kasm with environments that already have virtual desktops or remote-access servers deployed.

In addition to existing systems, Kasm can also deploy container-based sessions by connecting Linux systems running the Kasm Agent. For Windows-based workloads, Windows VMs or servers can be added to Kasm and accessed through the browser using RDP, without requiring a separate client.

Both Kasm Agents and Windows servers can later be configured for autoscaling, allowing resources to be dynamically provisioned and removed based on user demand.

Connecting an Existing Windows VM to Kasm

Kasm can deliver Windows desktops and applications by connecting to existing Windows virtual machines or servers. This is a common approach for organizations looking to provide traditional VDI-style workloads through a browser-based interface.

To connect a Windows system, first ensure the Windows VM is running and reachable over RDP. On the Windows system, install the Kasm Desktop Service using the installer provided in the Kasm documentation.

The installer requires three values:

• The hostname or IP address of the Kasm API
• The Kasm API port (443 by default)
• A registration token generated by the Kasm control plane

The registration token is generated from the Kasm admin interface by navigating to Infrastructure → Servers and selecting Add Server. After defining basic server details, setting the connection type to RDP, and enabling “Kasm Desktop Service Installed”, Kasm generates a registration token.

Once the token is entered into the installer, the Windows system securely registers with Kasm and appears in the admin interface as a managed server.

A server-based workspace can then be created and assigned to this system, allowing users to launch Windows sessions directly from the browser using Kasm’s Web Native client or a traditional RDP client.

Installing an Agent

For container-based sessions, at least one Kasm Agent must be connected to the deployment. Installing Kasm Agents inside Kubernetes is not currently supported, so an external Linux VM or bare-metal system is required.

The agent installation command is available in the Kasm documentation under the multi-server installation section. The command requires three key values:

• The agent hostname or IP address
• The manager hostname where the Kasm control plane is running
• A manager token retrieved from the Kasm deployment

# Kasm Agent installation commands
cd /tmp
curl -O https://kasm-static-content.s3.amazonaws.com/kasm_release_1.18.1.tar.gz
tar -xf kasm_release_1.18.1.tar.gz
sudo bash kasm_release/install.sh --role agent --public-hostname [AGENT_HOSTNAME] --manager-hostname [MANAGER_HOSTNAME] --manager-token [MANAGER_TOKEN]

To retrieve the Manager Token, you can once again browse to the Release Notes of the Kasm chart on Rancher and find the appropriate command to retrieve the manager token.

kubectl get secret --namespace kasm kasm-secrets -o jsonpath="{.data.manager-token}" | base64 -d

Then, substitute the agent installation command with your retrieved values and execute the command.

Once the command is executed on the VM and the license is accepted, the agent installs and automatically registers with the Kasm control plane.

After installation completes, the agent appears in the Kasm admin interface and can be enabled.

With the agent enabled, workspaces can now be installed from the registry. Installing a workspace image may take a few minutes on first use while the image is downloaded to the agent.

Once the image is ready, a session can be launched. This confirms that the control plane, agent, and workspace infrastructure are all functioning correctly. From here, users can launch desktop environments, browsers, and other applications supported by Kasm.

Autoscaling in Kasm

In this walkthrough, resources were connected manually by registering a Windows VM and installing a Kasm Agent on a Linux system. In production environments, Kasm does not require these resources to be managed by hand.

Kasm supports autoscaling for both Windows servers and Kasm Agents. Autoscaling allows Kasm to automatically provision and deprovision resources based on real-time user demand or scheduling policies. This functionality is supported across major cloud providers as well as on-prem hypervisors, including Harvester.

With autoscaling enabled, Kasm can dynamically create Windows VMs or agent hosts, automatically register them with the control plane, and remove them when demand decreases. Detailed autoscaling configuration is covered in provider-specific documentation and videos.

Links

• Kasm Helm Chart GitHub Repo: https://github.com/kasmtech/kasm-helm
• Kasm Kubernetes Documentation: https://docs.kasm.com/docs/install/kubernetes
• Rancher Partner Chart for Kasm: https://github.com/rancher/partner-charts/tree/main-source/charts/kasm
• Kasm Autoscaling YouTube playlist: https://www.youtube.com/playlist?list=PLGVRoK_5yweRIyFJjejDW1kzjlDb7C5ba

What is Kasm?

Kasm allows you to stream Windows desktops and containerized Linux desktops to any modern web browser. It can be used for everything from Zero-Trust Browser Isolation to VDI.

Kasm consists of several containerized services that govern authentication, session management, and collaboration. In the simplest case, Kasm can be deployed on a single server and can power dozens of concurrent sessions. Tens of thousands of users run Kasm like this every day in their homelabs and in the cloud.

Scaling challenges

Kasm customers also deploy in environments that must support thousands of concurrent sessions, sometimes with users distributed across the globe. To meet such scenarios, Kasm can be deployed in a multi-server configuration (or under Kubernetes with sessions powered by VMs). It can be spread across different data centres or cloud regions to support a globally distributed user base.

Such large-scale deployments will always require a degree of planning. Administrators must understand access patterns and identify where their users will be accessing workspaces from around the world. Kasm also has built-in autoscaling for on-premise virtualisation platforms as well as for major cloud providers. Autoscaling can dynamically create VMs to deal with elastic usage patterns cost-effectively.

These deployments typically fall into two categories:

1. All users in a single geography: Kasm can be deployed with autoscaling in a single data centre or cloud region.
2. Users across geographies: Kasm can be deployed in one primary region with satellite installations in other data centres or cloud regions.

Kubernetes

The Kasm control plane is deployed into a managed Kubernetes environment with the Postgres database configured as an RDS database (for AWS) or CloudSQL (for GCP).

Kasm workspaces run in Docker containers on EC2 instances or Cloud VMs that are configured for the Kasm Agent role. The reason these don’t run inside Kubernetes today is that Kasm requires specific host-level configuration which are not universally achievable on Kubernetes nodes.

Kasm Autoscaling

Kasm agent VMs can be autoscaled using the built-in Kasm Autoscaler. This gives customers control over the number of VMs that are available as Kasm Agents in each zone — improving efficiency, end-user experience, and minimising cost.

The Pulumi integration pre-configures these, so all an administrator needs to do is set up an IAM role (AWS) or Service Account (GCP) with appropriate permissions.

Pulumi automation

Deploying Kasm into a cloud environment for large-scale use can be time-consuming to set up. Administrators will need to set up networking, routing, load balancers, SSL certificates, and other related components. There can easily be hundreds of cloud resources that need to be created and configured. Aside from the amount of work involved, it is also prone to human error, and any architectural adjustments can require time-consuming planning efforts.

Pulumi is an Infrastructure-as-Code (IaC) tool similar to Terraform and Ansible. It enables infrastructure engineers to define cloud resources through code in multiple programming languages. This allows for consistently reproducible infrastructure and provides an effective audit trail for infrastructure configuration.

Our Pulumi scripts are developed in Python to make them accessible for engineers of all levels. With Pulumi, administrators can define infrastructure requirements in YAML format and run a command to deploy it into either GCP or AWS cloud environments.

Planning

At the outset, administrators need to decide which cloud region(s) they want to deploy Kasm into, as well as the initial sizing of Kasm zones and agents within them. They will also need to decide which area will serve as primary (this is where a Kubernetes cluster will be configured and will serve as the control plane for all zones). Finally, you will also need a domain name that the Kasm deployment will use. For more detail,s look at the GCP configuration example or the AWS configuration example. We populate the key information into a spreadsheet at Kasm, but how you do this is up to you:

Setup guide

Our GitHub repo includes comprehensive setup guides. Refer to the AWS README or GCP README for full details. The key points to summarise are:

1. Install a Python environment and create a virtualenv per the documentation
2. Install GCP or AWS CLI tools
3. Clone our repo and install Python requirements, including Pulumi (note: a Pulumi cloud account is not required)
4. Populate the configuration YAML file with the information from your plan.

Summary

With the Pulumi scripts provided, customers can provision and maintain production-grade Kasm environments within hours, whereas previously it could take days or weeks to plan and set up. Being written in Python makes these scripts accessible to engineers who want to customise or add their own cloud resources into a deployment. Ultimately, the entire process can be integrated into a CI/CD flow to achieve a high degree of automation.

AutoScaling is a powerful feature that dynamically provisions and destroys Kasm system resources based on a predefined schedule or real-time user demand. This means you can automatically scale your infrastructure up to meet peak demand and scale it back down during quiet periods, ensuring you only pay for what you use.

Kasm Workspaces offers robust AutoScale capabilities for both full-stack virtual machines (VMs) and containerized environments. It can dynamically provision and integrate full-stack VMs into a Server Pool to support RDP, KasmVNC, VNC, and SSH sessions for Windows or Linux desktops. Additionally, Kasm can AutoScale Docker Agent VMs to efficiently manage and deploy container-based workspaces, ensuring optimal resource utilization and scalability.

By leveraging a cloud provider like Microsoft Azure, you can build a highly efficient, secure, and cost-effective Kasm deployment that adapts to your needs in real time.

The Benefits of Cloud-Native Autoscaling

• Maximize Cost-Efficiency: Instead of paying for a large fleet of idle VMs 24/7, autoscaling ensures you only spin up — and pay for — resources when they are actively needed. When demand subsides, resources are automatically destroyed, slashing your infrastructure costs.
• Ultimate Scalability: Handle sudden traffic spikes with ease. Whether it’s the start of the workday or the launch of a new training program, Kasm and Azure can automatically provision new agents or servers to meet user demand without manual intervention.
• Enhanced Security: Autoscaling promotes the use of ephemeral, or temporary, instances. When a user session ends, the underlying VM can be destroyed. This practice significantly reduces the attack surface, as any potential compromises, malware, or misconfigurations are wiped away with the instance, and a fresh, clean VM is provisioned for the next user.

Overview of Autoscaling:

AutoScale - Kasm 1.17.0 documentation

Technical Guide: Configuring Kasm Autoscaling in Azure

This technical section, based on the Kasm Workspaces demonstration video, walks through configuring autoscaling for both Docker Agents (for containerized workspaces) and Windows Servers (for RDP sessions).

For the detailed configuration guidance, please refer to our documentation:

Pools - Kasm 1.17.0 documentation

Part 1: Autoscaling Docker Agents

This setup will automatically create and destroy Linux VMs to run containerized Kasm Workspaces like Chrome, Firefox, or Slack.

Step 1: Create an Azure App Registration

Kasm needs an identity in Azure to manage resources. We’ll create an App Registration for this.

1. Navigate to Microsoft Entra ID in the Azure portal.
2. Go to App registrations and select + New registration.
3. Give it a descriptive name, like kasm_autoscale_app. The other defaults are fine. Click Register.
4. On the app’s overview page, copy the Application (client) ID. You will need this for the Kasm configuration.
5. Go to Certificates & secrets and click + New client secret.
6. Add a description and choose an expiry period suitable for your organization’s security policy. Click Add.
7. Immediately copy the Value of the secret. This is your only chance to see it. This is the client secret key.

Step 2: Assign Permissions

Now, give this new application identity permissions to manage resources.

1. Navigate to the Resource Group where you want Kasm to create the VMs.
2. Go to Access control (IAM) and click + Add -> Add role assignment.
3. Assign the necessary roles. The Contributor role is sufficient for it to manage VMs and networking, but for more granular control, refer to the official Kasm Workspaces documentation for the minimum required permissions.
4. Select the app registration you created (kasm_autoscale_app) as the member and save the assignment.

Step 3: Configure Kasm Workspaces

Log into your Kasm admin dashboard to link it with Azure.

1. Create a Pool: Go to Infrastructure -> Pools -> Add Pool.

• Name: Azure Autoscale Pool
• Pool Type: Docker Agent
• Click Submit.

1. Create an Autoscale Config: Go to Infrastructure -> Autoscale Configs -> Add Autoscale Config.

• Name: Azure Autoscale Config
• Pool: Select the Azure Autoscale Pool you just created.
• Downscale Backoff (Seconds): Set how long an unused agent should wait before being considered for destruction (e.g., 60).
• Standby Resources: Define the minimum resources you want available at all times (e.g., 1 Standby Core, 1024 Standby Memory). Kasm will automatically create VMs to meet this minimum.

1. Configure the VM Provider:

• Under VM Provider Details, click Add Provider.
• Provider Type: Azure
• Name: Azure Docker Provider
• Fill in the Azure details:
• Subscription ID: Your Azure Subscription ID.
• Resource Group Name: The name of the Resource Group you configured in IAM.
• Tenant ID: Your Azure Tenant ID (found under Microsoft Entra ID -> Properties).
• Client ID: The Application (client) ID you copied earlier.
• Client Secret: The Value of the client secret you created.
• Azure Authority: Select the appropriate cloud (e.g., Azure Public Cloud).
• Region: The Azure region to deploy VMs in (e.g., Sweden Central).
• Max Instances: A cap on the number of VMs Kasm can create (e.g., 3).
• VM Size: The Azure VM size (e.g., Standard_B2ms).
• OS Disk Type & Size: Standard_LRS and 100 GB.
• OS Image Reference: This requires a specific JSON blob. You can get this using the Azure CLI. For an Ubuntu image, it will look something like this:

{
  "publisher": "canonical",
  "offer": "0001-com-ubuntu-server-jammy",
  "sku": "22_04-lts-gen2",
  "version": "latest"
}

• Network Security Group/Subnet: Navigate to an existing VM in your Azure portal, go to its networking settings, and use the JSON View to get the full resource ID for the NSG and Subnet. Paste these full IDs into the Kasm config.
• SSH Public Key: Paste your public SSH key to allow for administrative access.
• Agent Startup Script: Copy the agent startup script from the Kasm Workspaces GitHub repository. Important: Uncomment the section for Azure Private IP so the agent registers correctly.

Click Submit. Kasm will now begin provisioning VMs in Azure to meet your standby requirements.

Part 2: Autoscaling Windows Servers (RDP)

This process is similar but tailored for full-stack Windows VMs that users will connect to via RDP.

Prerequisite: Azure Compute Gallery Image

You must first have a generalized Windows VM image (Sysprepped) available in an Azure Compute Gallery. This will be your template.

Step 1: Configure Kasm Workspaces

1. Create a Pool: Go to Infrastructure -> Pools -> Add Pool.

• Name: Azure Windows Pool
• Pool Type: Server

1. Create an Autoscale Config: Go to Infrastructure -> Autoscale Configs -> Add Autoscale Config.

• Name: Azure Windows Config
• Pool: Select the Azure Windows Pool.
• Connection Type: RDP
• Credentials: Choose your desired method (e.g., Static for a shared account).
• Minimum Available Sessions: Set the number of standby Windows VMs you want ready (e.g., 1).

1. Configure the VM Provider:

• Create a new Azure VM Provider config as before.
• Fill in the same credentials and resource details.
• OS Image Reference: Navigate to your image version in the Azure Compute Gallery and go to the JSON view. Copy the id and place it in a JSON blob like this:

{
  "id": "/subscriptions/YOUR_SUB_ID/resourceGroups/YOUR_RG/providers/Microsoft.Compute/galleries/YOUR_GALLERY/images/YOUR_IMAGE_DEF/versions/YOUR_VERSION"
}

• Agent Startup Script: Use the appropriate Windows agent startup script from the Kasm GitHub.
• Config Override: If your Windows image uses Secure Boot and Trusted Launch (common for modern images), you must add a JSON override to enable it. This is detailed in the Kasm documentation.

{
  "properties": {
    "securityProfile": {
      "uefiSettings": {
        "secureBootEnabled": true,
        "vTpmEnabled": true
      },
      "securityType": "TrustedLaunch"
    }
  }
}

Click Submit. Kasm will now begin provisioning full Windows Server VMs from your template, ready to accept RDP sessions. When users connect, Kasm will scale up to meet demand, and when they disconnect, it will deprovision the costly Windows VMs, saving you money.

Kasm Workspaces is a powerful, container-based solution that lets you stream applications and even entire desktop environments directly to your web browser. It’s a fantastic tool for creating secure, isolated workspaces, setting up a centralized browser for your team, or just tinkering in a homelab. Since you can self-host Kasm, you have full control over your data and infrastructure.

This guide by LearnLinuxTV explores several ways to deploy Kasm, from a manual installation on a Proxmox VM to a one-click deployment on DigitalOcean. Whether you’re using on-premise hardware or a cloud provider, there’s a method here for you.

Method 1: Manual Installation on a Proxmox VM

This method is perfect for homelabs or if you’re running your own physical server with Proxmox. The steps are also applicable to any bare-metal Linux installation.

1. Prepare Your Virtual Machine

First, create a new virtual machine in Proxmox. A Debian or Ubuntu base is a great choice. Once the VM is running, SSH into it and perform some initial server setup:

• Create a non-root user: It’s a security best practice to avoid operating as the root user.

# Create the user (replace 'jay' with your desired username) 
adduser jay 
# Add the user to the sudo group 
usermod -aG sudo jay

• Set the hostname: Give your server a unique identity. Edit the /etc/hostname and /etc/hosts files to set your desired name (e.g., kasm or kasm.yourdomain.com).
• Update your system: Ensure all packages are up to date before installing new software.

# For Debian/Ubuntu 
sudo apt update && sudo apt dist-upgrade -y  
# For Fedora/AlmaLinux 
sudo dnf update -y

• Reboot: A quick reboot ensures all updates are applied.

sudo reboot

2. Install Kasm Workspaces

Now you’re ready to install Kasm.

1. Download the latest release: Find the latest version on the Kasm releases page. Right-click the link for your architecture (usually amd64) and copy the URL.
2. Download and extract the package: Use curl to download the file into your server's /tmp directory and then extract it.

# Navigate to the temporary directory 
cd /tmp  

# Download the release (replace with the URL you copied) 
curl -O https://kasm-static-content.s3.amazonaws.com/kasm_release_1.17.0.7f020d.tar.gz  

# Extract the archive 
tar -xf kasm_release_*.tar.gz

1. Run the installer: Execute the installation script.

sudo bash kasm_release/install.sh

The script will take a few minutes. Once it’s finished, it will display your login credentials. Save these in a secure location!

You can now access your Kasm instance by navigating to https://<your-server-ip-or-hostname>.

Method 2: Deploying on a Cloud VPS (Linode)

Running Kasm on a cloud provider like Linode (now Akamai) gives you a publicly accessible instance without needing to configure your home firewall. This process involves a manual installation similar to the Proxmox method but adds the crucial step of securing it with an SSL certificate.

1. Create and Configure Your Instance

1. Launch a VPS: In your cloud provider’s dashboard, create a new instance. A Debian or Ubuntu image is a reliable choice.
2. Set up DNS: Once the instance is created, copy its public IP address. Go to your domain’s DNS settings and create an A record pointing a subdomain (e.g., kasm.yourdomain.com) to that IP.
3. Initial Server Setup: SSH into your new cloud server and perform the same initial setup as in Method 1: create a non-root user, set the hostname to your fully qualified domain name (FQDN), and update all system packages.
4. Install Kasm: Follow the exact same steps for downloading and installing Kasm as you did in the Proxmox method.

2. Secure Your Instance with Let’s Encrypt 🔐

A public-facing server should always use a valid SSL certificate. We’ll use Certbot and Let’s Encrypt to get a free one.

1. Check DNS Propagation: Before requesting a certificate, make sure your DNS record has propagated.

# Replace with your domain 
nslookup kasm.yourdomain.com

1. If it returns the correct IP address, you can proceed. If not, wait a bit longer.
2. Install Certbot:

sudo apt install certbot -y

1. Request the Certificate: Stop the Kasm proxy container so Certbot can bind to the necessary port, then request the certificate.

# Stop the proxy 
docker stop kasm_proxy  

# Request the certificate 
sudo certbot certonly --standalone --agree-tos --preferred-challenges http -d kasm.yourdomain.com

1. Link the New Certificate: Kasm needs to be told to use the new certificate. We’ll back up the default self-signed certs and create symbolic links to the ones from Let’s Encrypt.
2. Bash

# Navigate to the certs directory 
cd /opt/kasm/current/certs  

# Back up the old certs 
sudo mv kasm_nginx.crt kasm_nginx.crt.bak 
sudo mv kasm_nginx.key kasm_nginx.key.bak  

# Link the new certs (replace with your domain) 
sudo ln -s /etc/letsencrypt/live/kasm.yourdomain.com/privkey.pem kasm_nginx.key 
sudo ln -s /etc/letsencrypt/live/kasm.yourdomain.com/fullchain.pem kasm_nginx.crt

1. Reboot:

sudo reboot

Once the server restarts, you should be able to access your Kasm instance at your domain over HTTPS without any browser warnings.

Method 3: The Easy Way with DigitalOcean Marketplace 🚀

DigitalOcean offers a Marketplace App for Kasm, which automates the entire installation process.

Kasm Workspaces | DigitalOcean Marketplace 1-Click App

1. Navigate to the Marketplace: In your DigitalOcean dashboard, go to the Marketplace.
2. Find Kasm: Search for “Kasm” and select the Kasm Workspaces app.
3. Create Droplet: Click “Create Kasm Workspaces Droplet”.
4. Configure the Droplet: Choose a region and a plan size. The marketplace app will pre-select a recommended size. Finalize your settings and click “Create Droplet”.

1. Get Your Credentials: After the Droplet is created, you’ll need to get your admin password. Access the Droplet’s Console from the DigitalOcean dashboard. A script is provided to display your credentials.

# Run this in the Droplet console ./show_kasm_credentials.sh

1. Log In: Use the provided credentials to log in to your new Kasm instance. You will be prompted to change your password immediately. That’s it!

Advanced: Kasm on Proxmox with Autoscaling

For a more robust Proxmox setup, you can configure Kasm to automatically create and destroy worker nodes based on demand. This is a more complex setup but provides incredible scalability.

Proxmox AutoScale - Kasm 1.17.0 documentation

1. Prepare Proxmox

1. Create a Resource Pool: In Proxmox, go to Datacenter -> Permissions -> Pools and create a new pool (e.g., KasmPool).
2. Create a Dedicated User: Create a new user (kasm-autoscale-user) under Datacenter -> Permissions -> Users. Use "Proxmox VE Authentication".
3. Create an API Token: Under Datacenter -> Permissions -> API Tokens, add a token for the user you just created. Uncheck “Privilege separation” and save the Token ID and Secret.
4. Create a Role: Create a new role (kasm-autoscale-role) with the specific permissions Kasm needs to manage VMs.
5. Create a VM Template: Build a fresh Debian VM, install the qemu-guest-agent, generalize the machine ID, and then convert it into a Proxmox template. This template will be the base for all new worker nodes.

2. Configure Kasm for Autoscaling

1. Log in to your primary Kasm server’s admin dashboard.
2. Configure Pools: Go to Autoscale Configs, give the configuration a name, and set the deployment zone.
3. Set Scaling Parameters:

• Standby Cores/Memory: Define the minimum resources you always want available.
• Downscale Backoff: Set a delay (in seconds) before Kasm removes an idle worker node.

1. Configure VM Provider Details:

• Provider: Select Proxmox.
• API Info: Enter your Proxmox server URL, the user you created (kasm-autoscale-user), the API Token ID, and the Secret.
• VM Details: Specify the VM ID range for new nodes, the exact name of your Proxmox template, the resource pool name, and the CPU/memory to allocate to new nodes.

1. Add the Startup Script: In the “Startup Script” box, paste the official Kasm startup script for agent nodes. This script will run on each new VM created by the autoscaler, installing the Kasm agent and registering it with your primary server.

Once you save the configuration, Kasm will connect to Proxmox and, if your standby settings require it, immediately begin cloning new worker nodes from your template.

Try this out on another hypervisor or Cloud:

Downloads | Kasm Workspaces

While this guide focuses on Harvester, the principles are applicable to other hypervisors like Proxmox, vSphere, cloud environments, or even bare-metal Linux deployments.

Important Considerations Before You Begin:

• Dedicated GPU: When you passthrough a GPU via PCI passthrough to a hypervisor (and subsequently to a VM), that GPU becomes unavailable to the host operating system. It’s recommended to have at least two GPUs in your system if your host OS requires a GPU: one for the host and another dedicated to Harvester for Kasm Workspaces.
• vGPU as an Alternative: An alternative to PCI passthrough is using virtual GPUs (vGPUs). However, this typically requires enterprise-grade Nvidia GPUs and licensed drivers, which is beyond the scope of this article.

Step 1: Configuring GPU PCI Passthrough in Harvester

This section details how to pass a physical Nvidia GPU directly to a Harvester Virtual Machine.

Enable PCI Controller in Harvester:

• Navigate to Advanced → PCI Devices in your Harvester UI.
• If not already enabled, enable the PCI controller. This allows Harvester to manage and passthrough PCI devices.

Create an Ubuntu Server VM Image:

• Go to Images → Create.
• Provide a name for the image.
• Upload an ISO image file or paste a URL from where the image can be download. The recommended image is Ubuntu Noble Server Cloud Image (Ubuntu 24.04 LTS).
• Click Create.

Create a Virtual Machine Network:

• Navigate to Networks → Virtual Machine Networks.
• Click Create.
• Name: Give your network a descriptive name (e.g., kasm-vm-network).
• Type: Choose UntaggedNetwork.
• Cluster Network: Select your management cluster network (e.g., mgmt).
• Click Create.

Create an SSH Key (Recommended):

• Go to Advanced → SSH Keys → Create.
• Name: Give your SSH key a name.
• Public Key: Paste your SSH public key.
• Click Create. This will allow passwordless SSH access to your VM.

Create and Configure the Virtual Machine for Kasm:

• Navigate to Virtual Machines → Create.

Basics Tab:

• Name: Assign a name to your VM (e.g., kasm-gpu-server).
• CPU: Define the number of vCPUs.
• Memory: Allocate sufficient RAM.
• SSH Key: Select the SSH key you created.

Volumes Tab:

• Click Add Volume → Existing.
• Image: Select the Ubuntu Noble Server image you uploaded.
• Size: Set an appropriate disk size (e.g., 100 GB or more, depending on your Kasm image storage needs).

Networks Tab:

• Choose the network you created earlier (e.g., kasm-vm-network)
• Click Add Network.

Advanced Options → PCI Devices Tab:

• In the PCI Devices section, search for your Nvidia GPU. You might see multiple entries related to your GPU (e.g., the GPU itself and its associated audio device).
• Identify and select the GPU and its audio device you wish to dedicate to Kasm.
• Click Enable Passthrough.
• Once passthrough is enabled for the desired devices, attach them to your VM.
• Click Create to provision the Virtual Machine.

Verify PCI Passthrough in Harvester:

• Once the VM is in the “Running” state, select it.
• Check the VM’s annotations or details page. You should see your PCI devices listed as allocated to this VM, confirming the passthrough from Harvester’s perspective.

Step 2: Install Kasm Workspaces on the VM

1. SSH into your VM: Use the SSH key and the IP address assigned to your VM to log in.
2. Install Kasm Workspaces: Follow the official Kasm Workspaces documentation for a single-server installation. Typically, this involves downloading the installation script and running a few commands:

cd /tmp 
curl -O https://kasm-static.s3.amazonaws.com/kasm_release_1.17.0.3bf277.tar.gz 
# Check for the latest version 
tar -xf kasm_release_1.17.0.3bf277.tar.gz 
sudo bash kasm_release/install.sh

Upon completion, the installer will output randomly generated credentials for your Kasm deployment. Store these securely. Log in to your Kasm instance via a web browser using these credentials.

Step 3: Install Nvidia Drivers and Container Toolkit in the VM

Even though the GPU is passed to the VM, you need to install Nvidia drivers and the Nvidia container toolkit within the VM’s operating system (Ubuntu Noble in this case) for Docker containers to utilize the GPU.

Verify GPU Visibility in the VM: Inside your VM, run the following command to check if the OS can see the Nvidia PCI device:

lspci | grep -i nvidia

You should see your Nvidia GPU listed.

Install Nvidia Drivers and Container Toolkit: Kasm Workspaces documentation provides a script for this, especially for recommended distributions like Ubuntu Noble. This script typically performs the following actions:

• Checks for an available Nvidia card.
• Adds the official PPA for graphics drivers on Ubuntu.
• Installs the latest available Nvidia drivers compatible with your GPU.
• Installs the nvidia-container-toolkit.
• Configures Docker to use the nvidia runtime.

Save the following script (or one provided by Kasm documentation) to a file (e.g., gpu_install.sh) on your VM:

#!/bin/bash

# Check for NVIDIA cards
if ! lspci | grep -i nvidia > /dev/null; then
    echo "No NVIDIA GPU detected"
    exit 0
fi

add-apt-repository -y ppa:graphics-drivers/ppa

curl -fsSL https://nvidia.github.io/libnvidia-container/gpgkey | sudo gpg --dearmor -o /usr/share/keyrings/nvidia-container-toolkit-keyring.gpg \
  && curl -s -L https://nvidia.github.io/libnvidia-container/stable/deb/nvidia-container-toolkit.list | \
    sed 's#deb https://#deb [signed-by=/usr/share/keyrings/nvidia-container-toolkit-keyring.gpg] https://#g' | \
    sudo tee /etc/apt/sources.list.d/nvidia-container-toolkit.list

apt update
apt install -y ubuntu-drivers-common

# Run ubuntu-drivers and capture the output
DRIVER_OUTPUT=$(ubuntu-drivers list 2>/dev/null)
# Extract server driver versions using grep and regex
# Pattern looks for nvidia-driver-XXX-server
SERVER_VERSIONS=$(echo "$DRIVER_OUTPUT" | grep -o 'nvidia-driver-[0-9]\+-server' | grep -o '[0-9]\+' | sort -n)
# Check if any server versions were found
if [ -z "$SERVER_VERSIONS" ]; then
    echo "Error: No NVIDIA server driver versions found." >&2
    exit 1
fi
# Find the highest version number
LATEST_VERSION=$(echo "$SERVER_VERSIONS" | tail -n 1)
# Validate that the version is numeric
if ! [[ "$LATEST_VERSION" =~ ^[0-9]+$ ]]; then
    echo "Error: Invalid version number: $LATEST_VERSION" >&2
    exit 2
fi
# Output only the version number
echo "Latest version is: $LATEST_VERSION"
ubuntu-drivers install "nvidia:$LATEST_VERSION-server"
apt install -y "nvidia-utils-$LATEST_VERSION-server"
# Install NVIDIA toolkit + configure for docker
apt-get install -y nvidia-container-toolkit
nvidia-ctk runtime configure --runtime=docker

Make the script executable and run it with sudo privileges:

chmod +x gpu_install.sh 
sudo ./gpu_install.sh

Note: A reboot of the VM might be necessary after the drivers are installed.

Verify Driver Installation: After rebooting, SSH back into your VM and run:

nvidia-smi

This command should output details about your Nvidia GPU, the installed driver version (e.g., 570.133.20), and the CUDA version (e.g., 12.8).

Verify Nvidia Docker Runtime: Execute the following command to list all configured Docker runtimes:

sudo docker info | grep -i runtime

You should see nvidia listed among the runtimes (e.g., Runtimes: io.containerd.runc.v2 nvidia runc).

Step 4: Configure and Verify GPU Support in Kasm Workspaces

Now, let’s configure Kasm to recognize and use the GPU.

Verify GPU Detection in Kasm UI:

• Log in to your Kasm Workspaces admin dashboard.
• Navigate to Infrastructure → Docker Agents.
• Select your agent and scroll down to the GPU Info section. Extend it. You should see your Nvidia GPU listed here.

• Scroll further to Docker Info and extend it. Verify that the nvidia runtime is recognized by Kasm.

Install the Kasm AI Registry (Optional, but Recommended for AI/ML workflows):

• Go to the Registries tab in the Kasm admin UI.
• If you are on Kasm version 1.17 or newer, the Kasm AI Registry should be visible in the “Registry Spotlight.” Click Install.

• This registry contains pre-configured workspaces with GPU support for various AI/ML tools.

Enable GPU for Workspaces:

By default, all images from the Kasm AI Registry have GPU support enabled. For other workspaces (e.g., a standard Ubuntu desktop or Blender from the default registry), you need to enable GPU access manually:

• Go to Workspaces.
• Find the workspace you want to configure, click its menu (three dots), and select Edit.
• In the workspace settings, set the GPU Count to 1. You can increase this if you want to pass through multiple GPUs to a single session (though this implies multiple physical GPUs passed to the VM or vGPU configurations).
• Save the changes.

Agent GPU Override (Advanced): You can configure the Kasm Agent to allow multiple container sessions to share the same physical GPU.

• Go to Infrastructure → Docker Agents.
• Edit your agent.
• Set the GPU Override setting. For example, setting it to 4 means up to four container sessions can attempt to use the same GPU.
• Note: This does not evenly distribute GPU resources. For fine-grained resource allocation, vGPU solutions are required.

Step 5: Launching and Verifying GPU-Accelerated Workspaces

Basic GPU Test in a Standard Workspace:

• Launch a workspace for which you’ve enabled GPU (e.g., a Kasm Ubuntu Desktop).
• Open a terminal within the Kasm session and run nvidia-smi. You should see the GPU details, confirming the GPU is accessible within the container.

• You can also launch Firefox within the workspace and run WebGL browser tests (e.g., webglsamples.org/aquarium/aquarium.html) to confirm GPU-accelerated rendering. (Note: Chrome/Chromium-based browsers in Kasm might not have full GPU acceleration support for rendering at the time of writing; this is being worked on.)

Showcasing Kasm AI Registry Workspaces:

Easy Diffusion:

• Install the “Easy Diffusion” workspace from the Kasm AI Registry.
• Launch it. This workspace comes pre-loaded with all necessary tools.
• The environment will set up, and Easy Diffusion’s web interface will automatically launch in a browser within the Kasm session. You can start generating images from text prompts, leveraging the GPU for fast processing.

CUDA-enabled PyTorch:

• Install and launch the “CUDA-enabled PyTorch” workspace from the Kasm AI Registry.
• This workspace includes PyTorch pre-installed.
• Open a terminal or Python environment and verify PyTorch can detect the GPU:

import torch
print(f"PyTorch version: {torch.__version__}")
print(f"CUDA available: {torch.cuda.is_available()}")
if torch.cuda.is_available():
    print(f"CUDA version: {torch.version.cuda}")
    print(f"GPU Name: {torch.cuda.get_device_name(0)}") print(f"CUDA available: {torch.cuda.is_available()}") if torch.cuda.is_available():     print(f"CUDA version: {torch.version.cuda}")     print(f"GPU Name: {torch.cuda.get_device_name(0)}")

• This output will confirm that PyTorch is successfully utilizing the GPU.

Blender with GPU Acceleration:

• The standard “Blender” workspace may not have GPU enabled by default.
• Edit its settings as described in Step 4.3 to set “GPU Count” to 1.
• Launch Blender.
• Inside Blender, navigate to Edit → Preferences → System.
• Under Cycles Render Devices, select CUDA or OptiX and ensure your Nvidia GPU is checked.
• You can now use Blender for your VFX workflows with GPU-accelerated rendering in Cycles.

GPU Workloads

By following these steps, you have successfully configured PCI passthrough for an Nvidia GPU on your Harvester hypervisor, installed the necessary drivers and runtime in your Kasm-hosting VM, and enabled GPU acceleration for Kasm Workspaces. Your Kasm deployment is now equipped to handle demanding GPU-accelerated workloads, providing a powerful and flexible container streaming solution.

Seamless Security and Enhanced Productivity: Kasm Workspaces Now Offers Smartcard Passthrough for ChromeOS to Windows

Kasm Technologies is excited to announce a powerful new feature for Kasm Workspaces: Smartcard Passthrough for Windows Workspaces accessed from ChromeOS endpoints. This enhancement significantly boosts security and productivity for users who rely on smart cards for authentication, digital signing, and certificate-based operations within their virtualized Windows environments.

Leveraging RDP-based Kasm sessions, Kasm Workspaces now supports passing through physical smart card devices directly from a ChromeOS device into the Windows workspace. This means users can utilize their existing smart cards and readers just as they would on a local machine, eliminating the need for complex workarounds or reduced functionality in their virtual sessions.

The integration of smartcard access into your virtual desktop infrastructure (VDI) offers tangible productivity gains. Users can seamlessly perform tasks requiring smart card authentication, such as logging into secure applications, digitally signing documents, or accessing sensitive systems, directly from their Kasm session. This streamlined workflow saves time and reduces frustration, making the virtual workspace a more complete and efficient work environment.

Enabling this feature involves straightforward configuration steps on both the Kasm platform and the ChromeOS endpoint. Administrators can enable smartcard passthrough for specific user groups within the Kasm admin interface by adding and setting the allow_kasm_rdp_smartcard_passthrough setting to 'true' for the desired group (e.g., the default administrators group).

On the ChromeOS device, users or administrators need to install a few key extensions from the Chrome Web Store to facilitate the passthrough:

1. Drive Lock smart card middleware: This provides the necessary middleware for smart card interaction on ChromeOS.
2. Smart Card Connector app: This app manages the connection between the smart card reader and the ChromeOS device. Users will need to grant the requested permissions upon installation.
3. Kasm smart Card bridge extension: This extension specifically facilitates the communication between the ChromeOS smart card services and the Kasm RDP session. Again, users should allow the necessary permissions.

Once these steps are completed, connecting to a Windows workspace in Kasm from the configured ChromeOS device should result in the automatic detection of the smart card within the Windows session. Users can then interact with their smart card as needed, including entering their PIN for authentication or operations. The functionality can be easily tested using tools or websites designed to detect smart cards and their associated certificates within the Windows environment.

By enabling direct smartcard access, Kasm Workspaces removes a common barrier for organizations and users who require this layer of security for daily tasks. This feature underscores Kasm’s commitment to providing a flexible, secure, and productive virtual workspace experience across a variety of endpoints.

Detailed documentation is available at: https://www.kasmweb.com/docs/latest/guide/smartcard_passthrough.html

That’s why we’re excited to introduce the Kasm AI Workspace Registry: a curated set of secure, containerized AI workspaces that make it easy to move fast without sacrificing control.

In this article, I’ll show you exactly how to set up the Kasm AI Workspace Registry inside your Kasm Workspaces 1.17+ environment and how to start deploying AI-ready workspaces like AnythingLLM and Easy Diffusion in minutes.

About the New AI Workspaces: Noble Numbat and Jammy Jellyfish

The new AI Workspaces are based on two Ubuntu Long Term Support (LTS) releases:

Noble Numbat (24.04 LTS): The latest, featuring updated software packages, enhanced security, and longer support lifespan.

Jammy Jellyfish (22.04 LTS): The previous LTS release, still supported but with a shorter remaining lifecycle.

By leveraging these bases, our AI Workspaces offer newer features, more modern software versions, and a longer runway for enterprise deployments.

What’s Inside the Kasm AI Workspace Registry?

Today, we’re kicking off the Registry with three initial AI Workspaces types:

AnythingLLM Kasm Workspace

A powerful, private AI agent framework:

Custom models: Bring your own models — run them locally or connect to OpenAI, Azure, AWS, and others.

Document ingestion: PDFs, Word files, CSVs, even online docs.

Privacy by design: Local defaults for LLMs, embedding, vector databases, and storage. Nothing leaves your environment unless you choose.

Easy Diffusion Kasm Workspace

A one-click install of Stable Diffusion for secure, local, text-to-image generation:

Full installation of all necessary components.

• Simple, browser-based UI to generate stunning AI images.

CUDA-Enabled Workspaces

Lightweight, secure, PyTorch and Tensorflow configured Linux-based workspaces for development and experimentation.

How to Install the Kasm AI Workspace Registry

First, make sure you have Kasm Workspaces version 1.17 installed. (This version introduces important updates for Workspace Registries.)

Here’s the step-by-step:

1. Access the Workspace Registry

• Log in to your Kasm Workspaces Admin Panel.
• Navigate to Workspaces → Workspace Registry.
• Click “Install” on the new Kasm AI Registry
• Here’s what it looks like once the Registry is installed:

3. Browse and Deploy Workspaces

Once added:

Use the filter buttons under the Registry name to view available AI Workspaces.

Select AnythingLLM, Easy Diffusion, or KasmOS.

Click Deploy to add them to your Kasm Workspaces environment.

Configuring AnythingLLM with a Google Gemini API Key

After deploying AnythingLLM, you can enhance its capabilities by integrating it with a Google Gemini Key.

Here’s a quick guide:

Log in to Google AI Studio and get a Gemini API Key

Launch your AnythingLLM workspace.

Navigate to the API configuration section inside the web interface.

Paste your Google Gemini API Key. Choose your Model

Save the settings.

You’re now ready to use a powerful, privacy-first AI agent with access to custom and public models!

Let’s Get You Experimenting

By installing the Kasm AI Workspace Registry, you’re giving your developers, researchers, and knowledge workers a secure sandbox to:

✅ Train private LLMs. Use AI-Assisted Development or CUA tools
✅ Explore text-to-image generation.
✅ Build document-based AI applications. Use A2A Frameworks or MCP
✅ Stay fully compliant and secure — at cloud speed.