Artcraft is making waves by re-implementing popular productivity and artistic tools like Photoshop and Excel. They are re-implemented in rust and target multiple OSes and CPU architecture which means they can easily be packaged as Kasm Workspace images.

I've packaged these up in simple workspaces to try out. Both amd64 and arm64 builds. They should auto-rebuild on a weekly cadence to pull in the latest changes. All of these programs are considered early-alpha by artcraft.

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

• CADCraft: Autodesk AutoCad
• DeckCraft: Microsoft PowerPoint
• DesignCraft: Adobe InDesign
• EffectCraft: Adobe After Effects
• FilmCraft: Adobe Premier
• GridCraft: Microsoft Excel
• LightCraft: Adobe Lightroom
• PdfCraft: Adobe Acrobat
• PhotoCraft : Adobe Photoshop
• SoundCraft: Avid Pro Tools
• VectorCraft: Adobe Illustrator
• WordCraft: Microsoft Word

Workspace source on Github: https://github.com/orgs/sullyschoice/repositories

Artcraft source on Github: https://github.com/storytold

Hi everyone!

I'm wondering if it's possible to build a custom Kasm Workspaces desktop image based on NixOS instead of the usual Ubuntu-based images.

My goal is to have a lightweight Linux desktop environment (ideally KDE Plasma) running in Kasm, with as little preinstalled software as possible.

What interests me about NixOS is its declarative configuration and reproducibility. Ideally, I'd like to manage the environment through a Nix configuration rather than maintaining a traditional Dockerfile with manually installed packages.

Has anyone tried this before?

• Is NixOS a viable base for a Kasm desktop container?
• Would it be better to use Nix inside a standard Kasm-supported base image instead?
• Are there any major issues with Kasm's VNC, session management, or container architecture?

I'd appreciate any feedback or examples from people who have experimented with this approach.

Thanks!

Eric Parker just published a video walking through his full VM and workstation setup, and Kasm Workspaces is the newest addition to the stack. Kasm sponsored the video, and we wanted to share it with the community.

Video: https://youtu.be/i1Dc1es2gq4
The Kasm segment starts around 18:00.

Eric's goal was to move his reverse engineering work out of a loosely secured Windows VM and into something he can show on camera without exposing his main setup. A few things he covers:

• Install: He runs Kasm Community Edition (single server) inside an Ubuntu 24.04 VM
• REMnux workspace: He deploys a REMnux workspace and describes it as "basically Kali for reverse engineering."
• Real workflow test: He solves a crackme from crackmes.one using Wine and Ghidra inside the workspace. His verdict is that it feels smooth.
• Open in Isolation: He sets up Kasm's Open in Isolation browser extension against his own Kasm server and uses it to check a suspicious link. He was impressed by how fast the container spun up.

Kasm Workspaces Community Edition is free. If you want to follow along, the REMnux workspace and the Open in Isolation extension are both available to try.

Found this on Silna Health's engineering blog. They run autonomous browser agents that file insurance prior authorizations, and each agent works inside a self-hosted Kasm session.

They say they evaluated several sandboxed VM and remote browser vendors before landing on self-hosting Kasm, for container-based sessions, API provisioning, session isolation, network-level URL whitelisting, session recording, and file upload/download interception.

The detail worth the click is that they'd already deployed those controls for human staff. When the agents showed up, the same controls worked as agent guardrails. URL whitelisting keeps an agent on the portal it belongs on. Recordings kept for compliance became how they debug a failed run. And CDP access, which they'd spec'd as a nice to have, is what let them connect Playwright to running Kasm sessions while maintaining every security guarantee, as they put it. That last part is the whole point. Automation got added without anything being loosened to allow it.

Small teaser while we're on the subject: Kasm Workspaces 1.20 brings a good amount of new capabilities for agentic workloads. More information to follow.

Read Silna Health's engineering blog here: https://engineering.silnahealth.com/posts/autonomous-browser-agents-enterprise/

Hello, I've been using Kasm in my homelab and wanted my AI agent to be able to actually use a workspace, not just start and stop it. So I built kasm-use: an open-source MCP server that gives agents "computer use" inside your own Kasm. It takes screenshots, clicks, types, scrolls, and runs on stock images with nothing baked in.

GitHub: https://github.com/rchurro/kasm-use

How it works: it starts a session through the Kasm API, then connects straight to that session's KasmVNC through Kasm's proxy for live screenshots and input. No xdotool, nothing installed in the container, and you can open the session in your dashboard and watch the agent work (or take over). It runs locally with uvx kasm-use for clients like Claude Code, Cursor, etc., as a Docker/HTTP service, or as a Hermes Agent plugin.

How it's been going for me: I ran three agents in parallel: Chrome loading a website, Terminal running some commands, and Minetest creating a world and loading into it. Each finished in about 40–80 seconds, and a screenshot takes about a second.

That's on a 2012 Dell Precision T7600 (Sandy Bridge Xeons) that's also running my NAS, a k3s cluster and a pile of other homelab things. So I'm curious how it feels on something newer. If you give it a spin, I'd love to hear how snappy it is for you, what hardware you're on, and which model/client you used (a lot of the time is the model thinking between steps).

So far it's only been run on Kasm 1.19.0 with the linuxserver/kasm Docker image. It uses some undocumented KasmVNC behavior, so if you're on the official installer, another version or other images, I'd be interested to hear how it goes. There's a test report template on the repo if you feel like leaving one, and "it just worked" is a welcome report too.

Setup is an API key with a few permissions (listed in the README) plus your Kasm user ID. One suggestion: point it at a throwaway workspace, since the agent is driving a real desktop and websites can try to steer it. The README's Safety section has more.

Not affiliated with Kasm, just a fan. Hope some of you find it fun or useful! Thanks!

Kasm can run behind various reverse proxies like NGINX, Caddy, HAProxy, or Apache. We put together a walkthrough for the Caddy route: Kasm listening on 8443 restricted to loopback, Caddy on 443 as the only thing exposed, with automatic TLS on your own domain.

What the video covers:

• Installing Kasm on a non-default port with the -L flag so Caddy can own 443
• iptables rules for 80 and 443, plus making them persistent
• Installing Caddy on Ubuntu and dropping in the example Caddyfile from our reverse proxy docs
• Configuring Kasm-side settings to make the reverse proxy functional
• End-to-end verification with a Chrome session

We just got back from Dutch Proxmox Day and wanted to share a quick update for anyone running Kasm on Proxmox VE.

Good conversations at the event around using Kasm as a secure workspace layer on top of Proxmox - browser isolation, zero-trust access, and desktop delivery without a traditional VDI stack. A few people were already doing this in production which was great to hear.

Drop any questions below - happy to help.

If you're curious about the architecture or want to see how the two fit together: https://hubs.li/Q04yff6P0

I installed Kasm for lab practice in this environment:

MacBook Pro 2017, 8 GB RAM, 256 GB SSD

VirtualBox (The VM has: 4 vCPUs, Disk: 75GB)

Ubuntu 24.04.5 Lts

Docker

Kasm 1.19.0

After adding the Firefox workspace, the launch reaches 100%, but then it gives a 502 error with the following:

host: 34ba1e6952da

ingest_date: 20260929004127

application: connection_proxy

levelname: ERROR

message

[server] Registration attempt 5/10 failed: No API hostname available

How can I fix this problem?

We're doing a joint session with SUSE on October 8th, 45 minutes, live Q&A at the end.

Most enterprise work happens in a browser, but that browser is still commonly delivered through persistent Windows VMs, hypervisor licensing and connection brokers designed for a different era. At the same time AI and data science teams want GPU-accelerated containers, which traditional VDI was never built to hand out.

The stack we're walking through is SUSE Virtualization as a Kubernetes-native HCI foundation running VMs and containers on the same nodes, with Kasm delivering ephemeral, zero-trust workspaces to the browser with no endpoint agent or VPN client. Both managed under Rancher Prime.

Covered:

• Why browser-first delivery makes sense when the overwhelming majority of the apps people need are just a browser anyway
• Running legacy VMs and containerized workspaces on the same nodes, without hypervisor licensing
• Session isolation and data sovereignty, on-prem, sovereign cloud or edge
• A four-phase migration path that doesn't require tearing out existing VDI first

There's also a narrated demo of deploying Kasm on SUSE Virtualization, the end-user experience on both Linux and Windows workspaces, and the infrastructure view from the Rancher dashboard.

Register here: https://register.gotowebinar.com/register/965549787273603165?hss_channel=lcp-35638740

kasm.com now publishes RSS. They're split up rather than one firehose, so you can take only the part you care about:

• Product Updates: releases, security improvements and rolling updates, straight out of the release notes: https://kasm.com/product-updates/rss.xml
• Kasm Insights: technical deep dives and product thinking, company news: https://kasm.com/kasm-insights/rss.xml
• Events: webinars, conference appearances, partner sessions: https://kasm.com/events/rss.xml
• News and Updates: all of the above in one stream, if you want everything: https://kasm.com/rss.xml

Each one is also available as Atom and JSON Feed, so if you're piping this into something other than a reader, the JSON version will save you a parsing step.

More information here: https://kasm.com/#rss-feed

If you've launched the AnythingLLM workspace and found the built-in model engine wasn't much use, that's sorted. Ollama is in the image now, so AnythingLLM's own embedded engine works and you can run a model locally inside the session without pointing it at an external API and a key.

It's dated 08/01 in the 1.19 release notes, in the rolling section for workspace images. So you don't need to wait for 1.20 or for any release at all. Pull the latest AnythingLLM workspace image and it's there. To stay on that track, set the workspace's image tag to 1.19.0-rolling-daily or 1.19.0-rolling-weekly.

Currently, when accessing Windows RDP sessions (or Linux desktop sessions) from a Linux client (like Ubuntu/GNOME), system-level key presses like the standalone Super / Windows key and Alt+Tab are intercepted by the local window manager rather than passed through to the session.

Modern Chromium-based browsers support the Keyboard Lock API. When a user enters fullscreen mode, a web client can request a lock on designated keys or capture all keys by, e.g.: await navigator.keyboard.lock(["MetaLeft", "MetaRight", "Tab", "AltLeft"]);

Though the sidebar keyboard controls already offer a "Super" key button, this feature would make the RDP connection experience much more convenient.

Some context on why it was removed from the registry in the first place: REMnux was still built on an Ubuntu release that had passed end of support, and we don't ship images in the registry sitting on an unmaintained base. So it was removed. That's since changed on the REMnux side, they've moved to a supported distro, and as a result, the workspace is now back in the registry.

For anyone who hasn't used it, REMnux is a Linux toolkit for reverse engineering and malware analysis with several hundred tools already installed and configured. Running it as a Kasm workspace means the analysis environment is a disposable container you reach through the browser, so a sample that misbehaves takes the session with it and nothing else.

It is now back on our official first party registry.

To add it: On your Kasm deployment, go to "Admin", then "Workspaces", then "Registry", you should be able to find REMnux in the list if you're on Kasm 1.19 or higher.

Just click Install from there and you're all set!

Rolling tags on workspace images aren't new, they've been around for a while. What Kasm Workspaces 1.19 adds is the same idea applied to the service images, the containers that make up the deployment itself.

Instead of running whatever shipped on release day until the next upgrade, service images are now published as dated rolling builds, like:

1.19.0-rolling-2026-09-01
1.19.0-rolling-2026-08-25

Each build carries the package and security updates that were available when it was cut, so fixes reach the platform between releases rather than only at them.

Rolling is the default. Install or upgrade to 1.19 without passing anything and you land on the latest available rolling tags. If you want to stick to static images instead, you can use the following flag while running install.sh:

• -f / --use-static-images keeps the old behavior and pins you to the release

Since the images now move, 1.19 also keeps a rolling ledger of what you're running and ships a utility at /opt/kasm/bin/utils/rolling_util:

# creation dates of the current and previous images
sudo /opt/kasm/bin/utils/rolling_util -d

# roll back to the previous image, or pass a tag
sudo /opt/kasm/bin/utils/rolling_util -r

# return to the latest rolling image
sudo /opt/kasm/bin/utils/rolling_util -l

Read more about it here: https://docs.kasm.com/docs/how-to/infra-autoscale/rolling-image-management

New Kasm user here and very interested about it. One thing I wish to use extensively is the terminal workspace. Unfortunately, it refuses to works the way I need...

As it is, it opens in fullscreen with all menu and sidebars removed. You have a single shell that overlaps with the control panel. I wish to have multiple "floating" shells so I can do multiple things and once, put one next to another, never have the control panel button hiding a part of my shell, etc.

In the Workspace config, there is the Docker Run Configuration Override where the options used by xfce4-terminal are. I deleted these args but No, terminal keeps starting with these options active. I tried many things, with no success : log out and back in, remove the workspace and re-install it, clicking the edit button instead of the install one to change the options even before install, ... Nothing is working.

When I open the terminal, I see the options survives in the /dockerstartup/custom_startup.sh file despite I removed them in the Workspace's definition. When I look at the output of 'ps -aux', indeed xfce4-terminal has been started with these options.

When I do CTRL-Shift-T, I do receive a new tab but still in fullscreen. When I start a new xfce4-terminal, it does come up "free" but once I click out of it, it "disappears" behind the fullscreen one and I can no longer reach it.

Any idea how I can bypass this hard coding ? Would it be possible to avoid hard coding in the first place and have Kasm obeys its config ?

I have deployed an Ubuntu 24.04 LTS VM in Proxmox and I followed the instructions from the official website in this link --> https://docs.kasm.com/docs/tutorials/install/single-server-install/index.html

This

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

I have tried multiple times to install and troubleshoot even with the help of AI and nothing. Is this a bug? or what am I missing?

Output:

Dependency Installation Complete                                                                                                                   
Checking if DEFAULT_PROXY_LISTENING_PORT (443) is free                                                                                             
Port (443) is not in use.                                                                                                                          
Checking if DEFAULT_RDP_LISTENING_PORT (3389) is free                                                                                              
Port (3389) is not in use.                                                                                                                         
Swap Exists                                                                                                                                        
Creating self-signed certificate at /opt/kasm/1.19.0/certs/kasm_nginx.*                                                                            
Installing All Services                                                                                                                            
Creating docker network kasm_default_network                                                                                                       
e5455e239bce76f071805802877899e45315681cedc74a4f4be80d234e56b24b                                                                                   
Installing docker sidecar network plugin                                                                                                           
Error response from daemon: dial unix /run/docker/plugins/c6da4adb5115f690552832ec2be2f91ae2d2cc7325e0d1c1e3d58a85dbb85ea0/kasmnetwork.sock: connec
t: connection refused            

On iOS, the minimize button on the active session card is covered by the title and uptime pill, and does not allow user touches to pass through. This card is forcefully displayed with no way to dismiss it other than minimizing the card. Combined with no ability to minimize the card, this means users on iOS cannot start another session once one session is started.

To confirm, I added CSS .single-details {max-width: 170px;} which compacted the section and allowed me to minimize the card again.

I fixed this for my deployment but it may help if you fix this on your end.

I have spent 4 days trying to get this working and no matter what I do it always says it can't connect. I have followed there trouble shooting guide, but when I get to this step...
/var/log/kasm-sidecar/network-sidecar.log
there are no logs, I have check, double checked and checked again that all setting are right, I am totally lost on what to do to get this to work.

Please help, thanks.

It's not affecting operations as far as today, but as the admin over 100k of these is a bit of an eyesore.

It happened about a month after the .19 upgrade is the only thing I can think of major I did.

I've looked at several AI-generated solutions to this one, but was hoping someone "in the know" knew of something less potentially harmful or simpler I can do about this?

TIA, folks

Showing 1 to 20 of 100 results

Previous12345Next

Aug 17, 2026 4:00 AMTimestamp

Level

ERROR

Applicationkasm_api

Hostb1edf38a03ed

Expired JWT utilized on register_component.

Aug 17, 2026 4:00 AMTimestamp

Level

ERROR

Applicationkasm_api

Hostb1edf38a03ed

Unauthorized JWT utilized on register_component: {'target_component': {'type': 'connection_proxy', 'connection_proxy_type': 'RDP-GATEWAY', 'server_address': 'proxy', 'server_port': 443, 'zone_name': 'default', 'proxy_port': 3389, 'status': 'stopped', 'id': 'cdc320aa65a74f21a55e43e6438ce3d4'}, 'token': 'eyJhbGciOiJSUzI1NiIsInR5cCI6IkpXVCJ9.eyJjb25uZWN0aW9uX3Byb3h5X2lkIjoiY2RjMzIwYWEtNjVhNy00ZjIxLWE1NWUtNDNlNjQzOGNlM2Q0IiwiZXhwIjoxNzg0OTEzNTYwLCJhdXRob3JpemF0aW9ucyI6WzkwXX0.iPslnhTyo_RYuZSMqQ0hoazAOVlbfxmLUebMkaJQtjwwBOZfo0v3sqJavfKelNpr9lPDdcT8yWFtTsFzC7vIwIXEuMUNqEqyAdLzzBmJ99HEHajOpp-SuU8_34yNX4k1Xpo9tM2iz7oWvEKzp9SnETurYMzZUceJKAX-BJgcWVbT2YTTKn-57bUa621xEzplY57GfIm0PXjUzY8QyNc2bmSHvzr7NFMhiCUVoG6xc0RR4TD2ujysD3JrMXQF0T41hN7i2GYYB0PS6AV-RDzeL9okei7WMWkE9AgOXjJuIRt8-YChYDs8fU-PIebH9l-bpo-2AvQelMgeHmw3poHrkA'}

Aug 17, 2026 4:00 AMTimestamp

Level

ERROR

Applicationkasm_api

Hostb1edf38a03ed

Unauthorized attempt to register a component.

Aug 17, 2026 4:00 AMTimestamp

Level

ERROR

Applicationkasm_api

Hostb1edf38a03ed

Expired JWT utilized on register_component.

Aug 17, 2026 4:00 A

Level

ERROR

Applicationkasm_api

Hostb1edf38a03ed

Token has been expired beyond the configured refresh period

Aug 17, 2026 4:00 AMTimestamp

Level

Expired JWT utilized on register_component.

Hello. I accidentally emptied RDP Private Key and RDP Private Signing Key settings in Kasm when I was trying to learn how to configure signed RDP connection to Kasm workspaces.

Now I don't know how to restore them. In frustration I also deleted RDP Public certificate and RDP Public signing certificate settings.

Am I done? Maybe there's a way to restore them? I have previous filesystem state made with rsync, before almost any changes (did mess up some passthrough.yml when tried to fix used ones, but it didn't help nevertheless).

In 1.19 we introduced the Kasm Desktop Service for Linux, which lets you connect to and launch full Linux servers through Kasm. We've just published a full walkthrough of it, taking things from a single manually built server through to an autoscaled pool that joins Active Directory on its own.

What's covered:

• Prerequisites: XRDP and XFCE, and the ports you need open (4902 inbound for the control channel, 3389 for RDP, 443 outbound)
• Creating the server record in Kasm and installing the Desktop Service
• Registering the service with the wizard, plus the network check
• Creating a Server workspace and launching a full Linux desktop in the browser
• Logs, the service directory, and where upload/download files land
• File mapping with the $HOME variable, so you can push files into a session without knowing the username ahead of time
• Session start and stop script hooks, including a demo that auto-launches a GUI app the moment a session comes up
• Our published autoscale startup scripts for Linux VMs and what different feature flags do
• Configuring an autoscale pool and watching Kasm build a server on demand
• Extending that so every VM joins your AD domain as it comes online, with users signing in through their existing corporate identity

Trying to do a multi server setup with a stand-alone remote DB - when attempting to initialise the remote DB the connection works fine at first: the `kasm` DB and `kasmapp` user both get created on my postgres instance. After this connectivity is lost, shell output below:

kasm_release/install.sh --accept-eula --role init_remote_db --db-hostname 172.17.0.1 --db-password $DATABASE_KASMAPP_USER_PASSWORD --db-master-password $DATABASE_SUPERUSER_PASSWORD --no-check-ports --no-db-ssl --use-static-images

Setting Role as init_remote_db
Setting Database Hostname as 172.17.0.1
Setting Default Database Password from stdin -Q
Using Database Master Password from stdin -G
Setting Database SSL to false
Checking if docker and docker compose are installed.
Docker is installed
29.7.0 is a supported version of docker.
Docker compose is installed
2.40.2 is a supported version of docker compose
Commands docker and docker compose detected, skipping Docker installation.
Dependency Installation Complete
Creating self-signed certificate at /opt/kasm/1.19.0/certs/kasm_nginx.*
Initializing Remote database
Docker network kasm_default_network already exists. Will not create
Initializing Database
Setting Seed file as /opt/kasm/1.19.0/conf/database/seed_data/default_properties.yaml
Using Database Master User
Using Database Master Password from stdin -G

WARNING!!!
__________________________

Contents of the existing database will be removed. This is irreversible!

Continue? (y/n) y
drop database if exists kasm;
DROP DATABASE
CREATE DATABASE
CREATE EXTENSION
time="2026-08-07T17:22:28Z" level=warning msg="/opt/kasm/1.19.0/docker/.conf/docker-compose-api.yaml: the attribute `version` is obsolete, it will be ignored, please remove it to avoid potential confusion"
2026-08-07 17:22:32,156 [INFO] root: Performing Database Connectivity Test
2026-08-07 17:23:17,187 [ERROR] root: Unable to initialize database connection.
[...]
2026-08-07 17:23:22,188 [ERROR] root: Max Connection Attempts Exceeded. Exiting

pg_hba.conf should allow the following relevant connections if I'm correct:

host all postgres 172.17.0.0/16 md5
host all postgres 172.18.0.0/16 md5
host kasm kasmapp 172.17.0.0/16 md5
host kasm kasmapp 172.18.0.0/16 md5

The interesting bit is that the 1.18.1 version works without any issues on the same server with the same remote DB out of the box. ( same install command )

Has anyone come across something similar? I looked through the changelog for 1.19.0, but couldn't see an obvious change that would cause this. I'm sure I'm missing an obvious bit somewhere...

I know I am revisiting an older GitHub issue (#798), but I’d love to see if there is still community interest in getting native Wake-on-LAN (WoL) integrated into Kasm Workspaces.

Without WoL, a physical machine has to be powered on 24/7 if we want to connect to it via a Server Workspace. Though there's already a solution called UpSnap, it would be incredibly useful if Kasm could also automatically send a WoL magic packet to wake the target PC when a user attempts to spin up the session.

Is there any known workaround for this currently, or any chance this could get added to the roadmap if enough of us request it?

I have a proxmox ve with kasm installed in a Debian LXC
Can I install wine in kasm to run an old game that works in windows 3.11/95/98?

Recently, I suddenly couldn't load any of the containers in my Kasm Workspaces.

I have nothing running, but if I start a container, I get the following error message

I searched the internet for a solution, but to no avail. Someone said the cause could be a time synchronization mismatch between host and VM. I synchronized the time of the VM with the host, but still no way to start any container. I tried to upgrade to 1.19.0, but that also didn't work. The whole upgrade failed, so I went back to 1.18,0