Guide to Installing and Using Kasm Workspaces: Build the Ultimate Lab with Kasm Workspaces

What is Kasm Workspaces?

Kasm Workspaces is a container streaming platform. You install it on a Linux server, and it runs desktops, browsers and single applications as Docker containers that stream into a web browser. Nothing is installed on the device you are sitting at, so you can hand someone a fully configured Linux desktop or an isolated browser without touching their machine.

Each session is a self-contained container with its own filesystem, libraries and network namespace. When the user closes the tab the container can be destroyed, so the next person gets a clean environment rather than yesterday's leftovers. The streaming layer is KasmVNC, Kasm's open source VNC implementation, which is what makes a session usable in a browser instead of a thick client.

Everything is managed from a web console: images, users, groups, policies and live sessions. Kasm Technologies maintains a large set of ready-made images (Chrome, Firefox, Kali, Parrot OS, GIMP, VS Code and more), and you can build your own from the open source base images on GitHub.

How Kasm works

Kasm uses KasmVNC to stream an application from the server to your browser. The application runs in a Docker container on the server and only pixels and input events cross the network, which is why a session opens in seconds instead of the minutes a full VM takes to boot. The tradeoff is that you get a container, not a kernel of your own, so anything that needs custom kernel modules or nested virtualization will not fit inside a normal session.

Because the session runs on the server, the device in front of you is not exposed to whatever is running inside it. That is the property that makes Kasm useful for opening a suspicious link, testing an untrusted binary or giving a contractor a desktop that cannot reach your internal network.

Session traffic leaves through the server, not through the client. The sites a session visits therefore see the server's address rather than the end user's, and Kasm can route that egress deliberately: either directly through the host, or through the built-in WireGuard egress network plugin. Managed Egress, which adds third-party egress providers on top, is a licensed feature. For a lab the direct path is fine, but it does mean every session shares one outbound address.

Minimum requirements to run Kasm Workspaces

Kasm services and end-user sessions are Docker containers, so the server needs access to a Docker registry during installation. You can run it on a VM or on bare metal. Kasm does not recommend running it inside LXC or WSL/WSL2, and I would not either: the installer expects to manage Docker on the host, and a nested container platform fights it.

Supported operating systems as of Kasm Workspaces 1.19:

• Ubuntu 22.04 / 24.04 (amd64/arm64)
• Debian 11 / 12 / 13 (amd64/arm64)
• Oracle Linux 8 / 9 (amd64/arm64)
• Red Hat Enterprise Linux 8 / 9 / 10 (amd64/arm64)
• Raspberry Pi OS (Debian) 11 / 12 / 13 (arm64)
• AlmaLinux 8 / 9 (amd64/arm64)
• Rocky Linux 8 / 9 (amd64/arm64)
• Any other Linux with bash, openssl, Docker CE and docker compose, as described in the docs.

CentOS is no longer on the list, which is expected. CentOS 8 reached end of life in 2021 and CentOS 7 in June 2024, so the old CentOS instructions this guide used to carry are gone. If you are still on CentOS, move to Rocky Linux, AlmaLinux or RHEL, which are the supported rebuilds.

System requirements

The server needs at least the following:

• CPU: 2 cores
• Memory: 4GB
• Storage: 75GB SSD

Those figures cover the Kasm services. Each end-user session needs additional resources on top, as defined in the workspace configuration. The default workspaces are configured to request 2768MB of memory and 2 cores, and a session will not start if the agent cannot satisfy that. In practice I give Kasm more than the minimum, because a couple of concurrent desktops will exhaust a 4GB host quickly, and the disk fills faster than you expect once rolling images start pulling.

Storage is worth checking before you start. The 75GB figure assumes the default set of workspace images. Kasm only measures free space in the volume that holds Docker's storage directory, which is /var/lib/docker by default. If your free space sits on a different mount, extend the root volume first, or the install can fail partway through.

End user requirements

End users reach Kasm through the web UI, and most current browsers work. The supported client browsers are:

• Chrome 92+
• Edge 92+
• Firefox 95+
• Safari 15.4+

Internet Explorer 11 is gone from the list, which is expected since Microsoft ended support for it in June 2022. Two caveats remain: audio does not work on mobile browsers, and the clipboard integration (copy and paste without using the side panel) only works in Chrome and other Chromium-based browsers.

Swap partitions

Even a host with plenty of RAM can get unstable during session provisioning without swap. The installer checks for swap and prompts you to create some if it finds none. To automate it, pass --swap-size with a value in megabytes. An 8GB swap file looks like this:

sudo bash kasm_release/install.sh --accept-eula --swap-size 8192

If you would rather manage swap yourself, pass --no-swap-check to skip the check.

Docker and Docker Compose

The installer will install compatible versions of Docker and Docker Compose if they are missing. If Docker is already present but at a version Kasm does not support, the install fails rather than replacing it; if docker-compose is present at an unsupported version, the installer replaces it. The cleanest option is a single-purpose machine where the installer handles both.

Current minimum versions for Kasm 1.19:

• docker >= 28.5.2
• docker compose >= 2.40.2

Note that Compose is now the v2 plugin invoked as docker compose, not the old docker-compose binary. You can check what you have with:

sudo docker --version
sudo docker info | grep "Docker Compose"

How to install the Kasm Workspaces server

Kasm deploys in two shapes: single-server, where every role runs on one machine, and multi-server, where the roles are split across hosts.

Single server installation

Single-server is the quickest deployment and the one I use for a lab. All internal Docker communication stays on the machine, and there is nothing to configure between roles. Only the web application on port 443 needs to be exposed, plus port 3389 if you want the RDP gateway for thick clients.

Install from the official bundle. The rolling build tracks the latest patch level, and the checksum file is there so you can confirm you got the bytes Kasm published:

cd /tmp \
&& curl --fail-early \
    -fO https://kasm-static-content.s3.amazonaws.com/kasm_release_1.19.0-latest.tar.gz \
    -fO https://kasm-static-content.s3.amazonaws.com/kasm_release_1.19.0-latest.tar.gz.sha256sum \
&& sha256sum --check *.sha256sum \
&& tar -xf kasm_release_1.19.0-latest.tar.gz \
&& sudo bash kasm_release/install.sh

Swap the -latest build for the pinned kasm_release_1.19.0.tar.gz if you would rather not track rolling patches, and add --use-static-images so the workspace images match the release. The full set of URLs and SHA256 hashes for the current release is in the single server install guide. Kasm publishes 1.19.0 with maintenance until September 2027, so this is the version to build on.

If you are on a slow or unstable connection, use the offline installer. The bundle is larger because it carries the images with it, but nothing is pulled from the internet during the install. For x86-64:

cd /tmp \
&& curl --fail-early \
    -fO https://kasm-static-content.s3.amazonaws.com/kasm_release_1.19.0-latest.tar.gz \
    -fO https://kasm-static-content.s3.amazonaws.com/kasm_release_1.19.0-latest.tar.gz.sha256sum \
    -fO https://kasm-static-content.s3.amazonaws.com/kasm_release_service_images_amd64_1.19.0-latest.tar.gz \
    -fO https://kasm-static-content.s3.amazonaws.com/kasm_release_workspace_images_amd64_1.19.0-latest.tar.gz \
    -fO https://kasm-static-content.s3.amazonaws.com/kasm_release_network_plugin_images_amd64_1.5-latest.tar.gz \
    -fO https://kasm-static-content.s3.amazonaws.com/kasm_release_logging_plugin_images_amd64_1.1-latest.tar.gz \
&& tar -xf kasm_release_1.19.0-latest.tar.gz \
&& sudo bash kasm_release/install.sh --offline-workspaces /tmp/kasm_release_workspace_images_amd64_1.19.0-latest.tar.gz --offline-service /tmp/kasm_release_service_images_amd64_1.19.0-latest.tar.gz --offline-network-plugin /tmp/kasm_release_network_plugin_images_amd64_1.5-latest.tar.gz --offline-logger-plugin /tmp/kasm_release_logging_plugin_images_amd64_1.1-latest.tar.gz

The arm64 offline install is the same command with arm64 in place of amd64 in the image filenames. Older guides passed a single --offline-plugin bundle; current releases split that into a network plugin and a logging plugin, which is why you now see two extra files and two extra flags.

Multi-server installation

In a multi-server install the roles are split across hosts, which lets you place them in separate network enclaves and scale agents independently of the web tier. The roles are:

• Web App Server: the user-facing entry point. Runs the web application (kasm_api), the manager (kasm_manager) and a proxy (kasm_proxy) on HTTPS 443.
• Database Server: runs kasm_db on PostgreSQL 5432. Can be a standalone Postgres or an RDS instance instead of the container.
• Agent Server: where sessions are provisioned. Runs kasm_agent and a proxy on HTTPS 443.
• Connection Proxy: optional. Brokers web-native RDP/VNC/SSH and thick-client RDP. Runs kasm_guac, kasm_rdp_gateway and a proxy on 443, plus 3389 if thick-client RDP is needed.

Each role is installed by passing --role to the same installer, so the database role is sudo bash kasm_release/install.sh --role db --database-user [USER] --database-name [NAME]. Full role-by-role instructions and the complete port matrix are in the multi-server install guide.

Licensing and activation

If you have an activation key, save it to a file and pass it to the installer. Activation completes during the install:

sudo bash kasm_release/install.sh -a activation_key.txt

This does not work for an air-gapped offline install, because Kasm has to reach its activation server. In a multi-server deployment the flag only applies to the database role. You can accept the end-user license agreement non-interactively with --accept-eula, and change the web port with -L (for example -L 8443).

When the install finishes it prints the credentials. The default usernames are [email protected] and [email protected], with randomly generated passwords unless you set them with --admin-password or --user-password. Save those in a password manager and change them on first login.

Kasm Workspaces on DigitalOcean

There is a Kasm Workspaces 1-Click App in the DigitalOcean marketplace, currently shipping Community Edition 1.18.1 on Ubuntu 24.04. It is the fastest way to get a working instance if you do not want to run the installer yourself. You log in as [email protected] with the droplet name as the initial password, then change it on first login. The marketplace listing has the full instructions, and DigitalOcean usually runs a credit offer for new accounts.

Other providers are fine too. Any Linux VM with the resources above will run it: AWS, Azure, Hetzner, or a box under your desk. If you are standing up a fresh VPS for this, my first 24 hours on a new VPS checklist covers the hardening you want before putting anything internet-facing on it.

Accessing and using the Kasm Workspaces console

In a browser, go to https://[IP address of your server], replacing the placeholder with the server's real address. Accept the self-signed certificate warning for now, then log in with the admin credentials. Put a real certificate in front of it before you expose the console to anyone else.

Launch a workspace

1. From the Kasm console, open the Workspaces section.
2. Pick a browser such as Chrome to launch a containerized browser session. It streams to your computer.
3. Use the three dots beside a running session to open the control panel, which holds the clipboard, audio and session controls, plus the option to destroy the container.

You can stream a lot more than browsers. GIMP, a terminal, an Ubuntu desktop, Visual Studio Code, Kali and Parrot OS are all available as images. Because they run in a container, none of it is installed on the device you are using, and closing the session throws the container away.

The other feature worth knowing is opening a single link in an isolated container. That is useful for a link you do not trust, or for a site you want to visit from the server's address rather than your own.

Installing the Open in Isolation browser extension

Kasm publishes a browser extension that opens links in a Kasm session from the right-click menu. It is called Kasm - Open in Isolation on the Chrome Web Store, and there is a Firefox build. To set it up:

1. Install the extension from your browser's store.
2. Open the extension options, enter the URL of your Kasm server, and choose whether links open in a new tab or a new window.
3. In the Kasm console, open your profile and set the default browser for isolated sessions (Chrome or Brave, for example). This is per user, which matters on a shared instance.

After that, right-clicking a link and choosing Open link in Kasm spins up a container in the background and streams the page into it. When you are done, open the control panel and delete the session.

You can also extend the image library from the admin console. Open the Images tab to browse what is available, enable the ones you want, and edit their settings.

Installing custom images on Kasm Workspaces

Kali Linux is a common one to add, and it is already published as kasmweb/kali-rolling-desktop. To enable it:

1. In the admin console, open the Images tab and find Kali Linux in the list.
2. Click the three dots on the right and choose Edit.
3. Tick Enabled and save. The image downloads in the background, so wait for the warning icon to clear before launching it.

A stock Kali session logs you in as a normal user. To get root, edit the workspace's Docker Run Config, which accepts the same JSON as a Docker container. Setting the user explicitly does the job:

{"user": "root"}

Submit the change, launch Kali again, and you land in a root shell. If you would rather keep the default user and escalate inside the session, su - still works. Either way, remember that a root desktop with network access is a lot of power to hand someone, so keep it on an admin-only group.

Setting up web filtering with Kasm Workspaces

Web filtering is what turns a browser session into something you can safely hand to other people. You create a policy and attach it to a workspace image. The steps:

1. In the admin console, open Users and click Add User to create an account, then set a password. Repeat for each user you need. Organizations with an existing directory can use LDAP or SAML instead.
2. Open Web Filter and click Add Policy.
3. Name the policy. Set it to Deny by Default if you want to block everything except what you explicitly allow, which is the right choice for a locked-down session.
4. Add allowed sites to the domain whitelist and blocked sites to the blacklist. Safe Search is a toggle on the policy if you want to force it on search engines.
5. Category filtering, which blocks whole classes of site rather than named domains, needs a Starter or Enterprise license. It is not in Community Edition.
6. Go back to Images, edit the image you want to protect, and set the Web Filter Policy field to your new policy. Save.
7. Log in as one of the users you created and try a blocked and an allowed site to confirm the policy does what you expect.

Once filtering is on, the admin dashboard shows session activity including the URLs visited, which is useful for auditing and for spotting a policy that is too loose.

Kasm Workspaces for enterprises

For a company, Kasm is an alternative to a full VDI product such as Citrix. Sessions are containers rather than VMs, so they boot in seconds and need far less hardware per user, and end users need nothing installed beyond a browser. The images are rebuilt and published regularly, so a session starts from a patched base rather than a golden image somebody forgot to update.

There is also a developer API for pipeline work: you can drive sessions programmatically to test custom containers or code in a throwaway environment. That API, autoscaling, custom branding and web category filtering are the parts that push you from the free tier into a paid one.

The editions as of 2026:

Community Edition is free for testing, non-profits and non-commercial use. It is not licensed for commercial work, so a business that gets value out of it needs a Starter or Enterprise key. Kasm publishes the full feature matrix if you want to compare the tiers line by line.

Conclusion

Kasm Workspaces gives you a browser-delivered desktop or application from a single Linux box, and it is the least fiddly way I have found to hand someone an isolated environment without shipping them hardware. Install it, add a certificate, put it behind your usual access controls, and start with the browser isolation use case, which is where most people get value first.

If you are exposing it to the internet, do the boring parts: a real TLS certificate, a firewall that only allows 443, and a reverse proxy or tunnel in front of it. My guide to setting up a Cloudflare Tunnel with Docker covers one way to do that without opening inbound ports. Leave a comment if you hit something this guide does not cover.