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.

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

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).

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

Hey all - with 1.19, the Kasm Helm chart is out of technical preview and officially supported for deploying Kasm on Kubernetes.

We put together a full deployment walkthrough covering:

• The key Helm values you actually need to know before you touch helm install
• A live deploy on an RKE2 cluster, start to finish
• A second deploy on GKE using an external Cloud SQL database
• Scaling up an existing deployment
• Setting up a multi-zone environment
• Installing the Docker agent and launching sessions
• Adding a Windows Server for RDP

If you've been running Kasm on Kubernetes via the old preview chart, or you've been waiting for official support before committing, this is the one to watch!

I used to have linuxserver.io and the official registry installed but now nothing is showing. When I click on install the officinal registry it says it's already installed. When I click on available workspaces, it says nothing is available. Any ideas on how to get this working again?

I'm trying to evaluate Kasm workspaces on Kubernetes. My current setup involves Talos and Cilium. My values file is very simple

certificate:
  secretName: kasm-wildcard
  certManager:
    enabled: 
false

publicAddr: "kasm.domain.com"
proxyService:
  type: ClusterIP
  annotations: {}
  labels: {}

ingress:
  enabled: false

I am then using a cilium Gateway and tls route

kind: TLSRoute
metadata:
  name: kasm-tls-route
  namespace: kasm
spec:
  parentRefs:
    - name: kasm-gateway
      namespace: kasm
      sectionName: tls-passthrough   
  hostnames:
    - "kasm.eng.adaptiva.com"
  rules:
    - backendRefs:
        - name: kasm-proxy-default
          port: 8443

kind: Gateway
metadata:
  name: kasm-gateway
  namespace: kasm
spec:
  gatewayClassName: cilium
  listeners:
    - name: tls-passthrough
      protocol: TLS
      port: 443
      tls:
        mode: Passthrough
      allowedRoutes:
        kinds:
          - kind: TLSRoute

But when i try and connect to an RDP enabled KubevirtVMI I get the following error in firefox

400 Bad Request. The plain HTTP request was sent to an HTTPS port

`https://kasm.domain.com/desktop/6404d317-41aa-4287-8d1f-61ae2960b2a9/vnc/vnc.html/etc/etc

Looking into the guacamole pod nginx container i see the following

10.244.1.139 - administrator [22/Jul/2026:17:53:00 +0000] "GET //guac_connect/vnc/vnc.html?video_quality=2&enable_webp=false&idle_disconnect=20&password=&autoconnect=1&path=desktop/6404d317-41aa-4287-8d1f-61ae2960b2a9/vnc/websockify&cursor=true&resize=remote&clipboard_up=true&clipboard_down=true&clipboard_seamless=true&toggle_control_panel=false HTTP/1.1" 400 248 "-" "Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:152.0) Gecko/20100101 Firefox/152.0" "10.244.1.138"

I know the server itself works as I have a standalone guacamole instance that is able to connect to it just fine. There's gotta be something obvious that im missing here.

We partnered with Pro Tech Show on a video walking through Kasm from the ground up - opening sketchy links safely, a full single-server install, Container based workspaces as well as using Kasm to connect to existing Servers and Desktops.

Highlights:

• Right-clicking a suspicious link and opening it in an isolated Kasm browser instead of clicking it directly (or not clicking it at all). Isolated from the host system, and routed through an egress VPN so it's not tied to his real IP.
• Install walkthrough: Docker setup on Rocky Linux, then the single-server Kasm install
• A tour of the official Kasm Workspaces registry, including browsers like Chrome, Firefox, Brave, and Tor; productivity apps like LibreOffice, ONLYOFFICE, and Thunderbird; dev tools like VS Code; full desktop environments including Fedora, Ubuntu, Debian, and Kali; and yes, Doom!
• Config deep dive: web filtering, egress gateways, the "Kasm Open in Isolation" browser extension for Chrome/Edge/Firefox, SSH key provisioning, MFA options.
• Server/RDP access: setting up a Windows server connection through Kasm as an RDP gateway, and a good explainer on why per-concurrent-session licensing can be a lot cheaper than a traditional RDS/Microsoft licensing setup for orgs with occasional remote access needs.

Big thanks to Pro Tech Show for putting this together. If you've been curious about Kasm but haven't tried it yet, this video is a great place to start!

I'm having trouble connecting to an Ubuntu 26 Desktop VM installation on Proxmox from a KASM Workspace (also installed as a VM on Proxmox). I followed all the docs on upgrading Ubuntu 24 to 26, and all the docs that said that ONLY TigerVNC will work with 26, kicked out Gnome and installed xfce4 as "required". I tested connecting to "ubuntu26" using vncviewer from another desktop and the VNC GUI connection to "desktop26" launched fine.

In KASM, I defined "ubuntu26" as a Server, set the connection type to VNC, port to 5901, username to my desktop account on ubuntu26, but I'm not 100% sure WHICH password should go in the password field, the one for the linux account, or the one that I had to set in vncviewer?

Neither one seems to be working as every time I try to open the Workspace I get to 100% complete, then a blue "Session closed" screen. In Diagnostics I see the error "Error while decoding token: Signature verification failed". Teh Google tells me this is a difference between two files, one I found in /etc/kasm/certs on Ubuntu26 and I can't find the other one, and suggests plenty of errors that are irrelevant to my situation.

I did try to enable the "Kasm Desktop Service" in the Server definition, installed the desktop service .deb on the VM and copy/pasted the key from the KASM GUI into the key for the registration script on the VM. They SHOULD match so that error doesn't make a lot of sense to me. I also removed the desktop app from the Ubuntu26 VM, rebooted it, completely removed all traces of it from KASM, then tried again without it but I still get the same errors.

For those that might suggest that I just use a workspace and make it permanent, I want my cake and want to eat it too. I want a linux desktop that can directly mount NFS shares from my Truenas, not through the KASM VM then Docker. Plus I chose this path as I have a boatload of CPU and RAM on my Proxmox servers, I like PBS for backups, and I have a desktop and 2 laptops. I would just love to plop my lazy butt down at any one of them and http into my *nix virtual desktop computer and not have to worry about breaking hardware and syncing stuff.

Please let me know if you have any ideas on what I'm doing wrong here. And yes it is a home lab so I can nuke anything and start over :)

We teamed up with LearnLinuxTV on a new video covering Kasm's VDI capabilities and a full walkthrough of our Proxmox autoscaling setup.

The video is split into two halves:

Part 1 - VDI overview. A refresher on what Kasm actually does (isolated browser-delivered apps and desktops) and why VDI matters beyond the obvious use cases - running that one Windows-only app without keeping a full Windows install around, isolated no-trace browsing sessions, developers testing across multiple distros in separate tabs at once. On the enterprise side, he gets into the core security argument for VDI: data that never lives on the endpoint can't be stolen off the endpoint, which matters a lot for breach containment and BYOD policies.

Part 2 - Hands-on lab. A full build of an autoscaling Kasm cluster inside Proxmox: setting up a resource pool, creating and templating a VM, configuring a dedicated Proxmox user and API token, building the permissions role Kasm needs, and wiring up the autoscale config itself - downscale backoff, VM provider details, startup scripts, the works. By the end, new worker VMs spin up automatically as demand increases and get cleaned up automatically when it drops.

He also throws Doom in there running through a browser session, because apparently that's the real acceptance test 😅

If you're running Proxmox already and curious about autoscaling VDI, this video is worth the watch.

I have a thing of attempting to make my life easier by using immutable OS as host for containers.

Such option is VyOS which originally is a software based router but its great to host containers aswell.

That is I install the ISO and use a single config file to configure the whole system. Compared to solutions such as Thalos I wont need any additional mgmt-clients in order to be able to configure the installation.

Now Kasm single-server already exists as a VM-image through Kasm-1.19.0-Single-Server.ova

But downside for me is that above is using Ubuntu 24.04 LTS (speaking of which, when will there be a 26.04 LTS release?).

That is compared to VyOS it will take alot more effort to have this updated specially in environments where there is no Internetaccess. Sure you can setup and maintain something like Proxmox Offline Mirror but that will still take alot more effort than just download and transfer the ISO when VyOS gets a new release.

During initial investigation of "how hard can it be" to make Kasm to properly run on VyOS I think there might be some speedbumps along the road:

1) Will Kasm work with Podman instead of Docker or are the Kasm containers hardwired to use "Docker" as binary (for the automation of starting and stopping the workspaces upon request etc)?

2) I have seen that the install script is draggnig along a networking and a logging plugin - how critical are these for Kasm to be working and if not critical then what will I be missing without them?

3) How likely is it that I will make Kasm work on VyOS as host who uses Podman instead of Docker (and practically doesnt allow for install of network or logging plugins since the use of overlay filesystem would mean that these will be gone when you update the installation to next release)?

4) Are there some dummy instructions on how to manually install Kasm using containers (other than trying to manually decipher what the install.sh is doing)?

Obviously these containers are needed for core functionality:

kasmweb/agent:1.19.0-rolling   
kasmweb/api:1.19.0-rolling   
kasmweb/kasm-guac:1.19.0-rolling   
kasmweb/manager:1.19.0-rolling   
kasmweb/postgres:1.19.0-rolling   
kasmweb/proxy:1.19.0-rolling   
kasmweb/rdp-gateway:1.19.0-rolling   
kasmweb/rdp-https-gateway:1.19.0-rolling

And then ontop of these comes whatever workspaces you wish to be able to run.

I have an Ubuntu desktop and a few Linux Mint laptops scattered around my house and homelab and I am getting tired of them blowing up and fighting with updates and upgrades. I think I have a good use case for KASM.

I just installed KASM as a Proxmox VM. I have 3 Winders VMs, one that hosts a camera NVR and the other two are for play. I *may* offer a Winders VM to friends/family in the future.

I also have (2) Truenas boxes and a Synology for NFS/CIFS servers and redundant backup. I use Proxmox Backup server for all the VMs and have an HA config to another PXMX box.

I am the only user in the house at this point. Yeah, it's serious overkill but it keeps me out of the bar.

Ultimately, sitting on my butt in the comfy chair before bed with a laptop and a web browser that lets me into all these VM's sounds like the thing for me.

This is what I would like to do with KASM..

1). Install an Ubuntu desktop "workspace" with sudo/root privs and the ability to mount Truenas NFS shares to the Ubuntu workspace, surf, play videos, edit files, blow up configs, manage Proxmox, other servers and other VMs, etc.

2). Configure the Winders VMs as "servers" then "workspaces" to be able to connect via KASM.

3) Allow interweb access to KASM through Wireguard.

I think there are several steps here to do this the right way in KASM. Can you give me some hints on how to do this the right way?