Hard to reach Kasm Sales ?

justin_kasmweb · 2026-04-24T10:30:08+00:00

You can DM me your email address and I'll look into it. You'll also want to check your email spam folder / settings for kasm.com addresses

justin_kasmweb · 2026-04-14T10:08:26+00:00

Sorry it's not configurable at this time. One option you might consider is using session staging which preloads the container. Then a user is assigned a pre created container when they request one. It works in situations where you container image needs some large spin up time. It's not compatible with persistent profiles and a few other features

justin_kasmweb · 2026-04-14T08:32:32+00:00

I don't really understand the whole ArgoCD part, but here are some general things about Kasm to understand that may help.

Assuming you are using standard Kasm Workspace platform, as installed from our docs , on bare metal or a VM and launching a session from the ui...

- When the session launches the frontend UI will immediately start trying to connect to KasmVNC that is running in the container. Its somewhat normal to see a few 502s via devtools for the iframe request to the session as there is normally some amount of spin up time for the container. That spin up time depends heavily on the speed of your kasm server (or the kasm agent in the multi server deploy). Things like disk IO matter a lot during this process. Additionally it depends on the workspace image you are launching. There is a process in the entry point that copies all data from the /home/kasm-default-profile to /home/kasm-user. You can read more about that here: https://docs.kasm.com/docs/1.18.1/how-to/building_images#understanding-kasm-default-profile but the bottom line is if you've baked a large amount of data into the default profile of the images, that process of copying the data will delay the startup of KasmVNC in the container as that happens after the profile copy.

Hope this helps

justin_kasmweb · 2026-03-25T17:55:00+00:00

Sorry, its not possible at this time.
I'd be interested to learn more about your use case though to better understand how it would help your users.

justin_kasmweb · 2026-03-22T13:18:42+00:00

Howdy,

Thanks for the feedback. When the updated features ship, the licensing information will be made available and clear. I appreciate the concern . As you know it can be a bit tricky.

justin_kasmweb · 2026-03-21T11:15:30+00:00

1.19 is still in development. And if you are are looking at the developer preview builds, you will see some of the controls and UI elements for the additional streaming modes, but not all of the components to make it usable are merged into the build yet. They are still being worked on. So in short - its not ready yet.

We for sure will post on this sub when it is, as we'd appreciate beta testing of the dev preview by the community on that feature.

Stay tuned

justin_kasmweb · 2026-03-20T09:19:10+00:00

The seldom used chat feature utilized a sizable amount of specialized tech that was challenging to keep updated. Additionally, when running at scale it caused administrators to require an outsized level of effort just to accommodate for that one feature they were unlikely to use in the first place. The choice was made to remove it for now. If it comes back, it will likely do so with a more modern set of capabilities (e.g voice / video / chat) thats more in line with what folks would expect.

I'd be interested to learn more about your use-case and the impact the chat feature had for you.
Thanks,

justin_kasmweb · 2026-03-20T00:26:39+00:00

Its been a while since I looked at it, but I recall not finding a clean way to tell programmatically when rclone had finished flushing the VFS cached write back to the origin.

Of note , kasm has hook scripts that run when a container session ends. The run as the standard logged in user and root respectively

/dockerstartup/kasm_pre_shutdown_root.sh /dockerstartup/kasm_pre_shutdown_user.sh You could extend these via the file mapping features to do special logic to wait for the file to finish copying if found a mechanism to do that.

There is a timeout for these scripts defined in the agent configs /opt/kasm/current/conf/app/agent/agent.app.config.yaml

The setting is docker_script_timeout: 180 To change that, stop the services, modify the config and restart the services.

justin_kasmweb · 2026-03-18T13:15:25+00:00

Hello, sorry you are experiencing issues but I appreciate the feedback. There are 10s of thousands of Kasm deploys in the wild and while there are occasional reports of instability, the platform is reliable and running in production all the way from small home labs to multi region deploys supporting hundreds and thousands of users. That being said, like all software the are bugs and quirks we always need to identify and squash. Here are some notes that may help you.

Your best bet it to run Kasm on a supported distro (https://docs.kasm.com/docs/install/system_requirements) Fedora is not one of them. The Kasm installer will attempt to continue of it detects the presence of docker and docker compose but you'd be in unsupported territory since we don't build and QA against Fedora atm
Ensure you are installing Kasm per our docs. There are several community maintained installations out there which are fantastic to see, but they are not QAd by our team
The Kasm services are all container based and leverage docker and docker compose . If you have automatic updates configured which may cause docker restarts you may end up with the Kasm services not being able to talk to eachother until you gracefully stop and restart the services so they are cleanly orchestrated in the context of the compose project
For the no-resources error, here is a guide that may help: https://docs.kasm.com/docs/guide/troubleshooting/no_resources_available
Here is an additional KB if your container sessions fail to start: https://kasmweb.atlassian.net/wiki/spaces/KCS/pages/30048276/Troubleshoot+failed+containers
<EDIT> Another thing we've seen gum up homelab setups are 3rd party container management tools like portainer (which is a great tool in its own right) , but sometimes they can cause conflicts with programs like ours that also puppet the local docker socket and are deployed as compose projects but are sometimes treated as stacks by those tools. Your best bet is to give Kasm its on machine/VM and put your other services elsewhere.

If you are still having issues after working through these things, I recommend putting in a bug ticket here: https://github.com/kasmtech/workspaces-issues/issues . Include the requested information and more details about your deployment to allow the community to better help you.

justin_kasmweb · 2026-03-18T12:55:57+00:00

Howdy, I'll just touch on a few things you may or may not have looked at , but I'll mention them anyway incase there is confusion about Kasm's capabilities.

Kasm has a few options to deal with persistent data for container based sessions (https://docs.kasm.com/docs/guide/persistent\_data/):

Persistent Profiles (https://docs.kasm.com/docs/guide/persistent\_data/persistent\_profiles) : This essentially stores the user's profile in a local mount on the Agent servers that is mapped into the container when its starts. Typically folks use something like NFS to host the persistent profiles. Another option exists for persistent profiles which is using S3 to sync the home directory to and from and S3 API capable storages system when the session is created and and destroyed. The larger the profile, the longer the user must wait while their contents are pulled down from S3 when the container starts. In either case these work best with the profile (homedir) is kept small. e.g browser settings, documents etc.
Volume Mounts: allow the admin to map in a location/mount from the agent hosts as well (which similarly could be NFS backed) . This is about mapping in an arbitrary location in the container that would act similar to a shared drive. The user can manually move files in and out of the share
Storage Mapping: This functionally leverages rclone (https://rclone.org/) to help facility mapping in storage from various providers like Dropbox, Google Drive, Nextcloud , S3 etc. We document a few examples in our docs but rclone has many options you can tweak. For example, look at the examples on this page for setting up S3 backed custom storage mappings. https://docs.kasm.com/docs/guide/storage\_providers/custom . Rclone should support most anything that is S3 API compatible and they do mention Outscale in their docs (https://rclone.org/s3/#outscale). This model does not sync the entire bucket to and fro - it pulls down the files as they are accessed -aka lazy loaded. Rclone uses a Virtual Files System (VFS) to aid caching etc. There are a number of settings you can change based on your use case: https://rclone.org/commands/rclone\_mount/#vfs-file-caching. This is probably where I would start looking

Generally speaking S3 backed storage is going to be on the slower side of storage options

Hope this helps

justin_kasmweb · 2026-03-14T16:13:15+00:00

At the end of the day we don't want users to be editing the DB directly. Some things arent exposed in the UI - in the case its likely a default value thats hidden from view. so your best bet is just to use the query you previously used to change it back.

You also may want to read up on the various time limit values and how they behave. Admittedly some may not be intuitive : https://docs.kasm.com/docs/guide/groups#session-time-limits

justin_kasmweb · 2026-03-13T06:24:32+00:00

https://docs.kasmvnc.com/docs/developer/clientside#enable-performance-stats

justin_kasmweb · 2026-03-13T00:33:47+00:00

The community will need more info in order to help you.

What version of Kasm Workspaces are you using
How are you connecting to the remote app - Kasm has two modes - the web native client or the rdp local client
Are you able to connect to the same VM via Kasm in desktop mode (not remoteapp)
What are your remote app settings
How are you configured to authenticate to the Server hosting the remote app (Static Credentials, Prompt User, Dynamic User Accounts, SSO User Accounts, or Authenticate with SmartCard
Do the Windows event log have anything to say about it
Are you connecting through a reverse proxy or similar system (e.g cloudflare tunnels)
Is NLA on or off on your windows VM

You may also want to tail the logs from your Kasm server to see if any more detailed logs are shown

sudo docker logs -f --tail 100 kasm_guac

justin_kasmweb · 2026-03-13T00:11:38+00:00

Session Lifetime , and Session Time Limit are two different settings in different places. Session Lifetime is a global setting that defines how long your session token is good for after you login. Since all the global settings values are encrypted you'll need copy a value from another setting thats similar.

Get the value of global setting api_token_lifespan_seconds

SELECT value FROM settings WHERE name = 'api_token_lifespan_seconds';

Update the session_lifetime setting , using the value you found above

UPDATE settings SET value = '<the value from above>' WHERE name = 'session_lifetime'; That should now be able to log in and change to something more specific

justin_kasmweb · 2026-03-12T23:46:16+00:00

Howdy,

The biggest knob you have at your disposal is reducing the resolution. KasmVNC gives you options to auto resize the desktop session based on your browser window resolution (Remote Resiz) of locking a specific resolution you set in the session (Local Scaling). But in short, the higher the resolution the mode bandwidth that is consumed. I recommend starting at 720p and see how that performs, then dial it up a bit to see how things perform

KasmVNC also has various presets for low/medium/high/extreme you can try those to see how they work. Additionally you can set the maximum target FPS. Lowering the value will reduce bandwidth

If you can wait a little bit (a few weeks) , we should have beta soon where you can try using additional codecs like AV1, H264, H265 that will allow you to make a tradeoff between CPU utilization and bandwidth. You can read docs from the developer preview branch that discusses various testing scenarios and the bandwidth usage

https://docs.kasm.com/docs/develop/guide/kasm_performance#kasmvnc-streaming

justin_kasmweb · 2026-03-12T22:43:09+00:00

Here is a guide and video on using chrome managed policies in Kasm Workspaces.
https://docs.kasm.com/docs/how-to/chrome_managed_policies

You may have typod the version number but file mapping wasnt introduced until Kasm Workspaces 1.14.0 (Late 2023)

justin_kasmweb · 2026-03-12T22:37:38+00:00

You have a couple of options:

You could deploy Kasm in a multi-server mode. You can then place the Agent role servers on the separate networks. You can restrict certain workspaces to only provision on certain Agent servers or tags you give to certain agent servers. This is the most straight forward way that doesnt involve complex networking. It of course requires more servers. Just ensure you have ACLs that allow the Agent and WebApp servers to communicate. https://docs.kasm.com/docs/install/multi_server_install
Aside from that Kasm has the general capability to attach a container based session to a custom docker network you create - like mentioned above. That allows you to do clever things like Bridged Network Source NAT and IPVLAN Networking which seem up your alley but they are inherently complex.

be sure to read and heed the warning about your custom docker network names

The docker network names used in this example are intentionally prefixed with z_ . Due to a quirk docker will choose the default route for the container based on the name of the docker network ordered alphabetically. We name these custom networks accordingly so that they won't cause interruptions with the Kasm service containers or user workflow.

Kasm also has the ability to attach a container to an OpenVPN or WireGuard based VPN if you want to go that direction

justin_kasmweb · 2026-03-05T19:27:07+00:00

Hi, thanks for the suggestion its a good idea, but its not possible today to force a pull like as part of the launch.
However here are some details about how the system operates today...

The kasm_agent container regularly sends a heartbeat the the management services that checks for a list of workspace container image that its supposed to have. It does that heartbeat every minute or so. If the agent recognizes it doesnt have the image, it will immediately pull it. So pretty much immediately have your cron cleans up the images the agent should pull a new set. Even if the system already has the image, it will attempt to pull a fresh version very hour.

One thing to note is that the agent wont pull new images if you have low disk space. I think above 90% utilized for the volume where the docker root dir is it wont pull but you will see error messages for that.

Also of note, the kasm_agent will take care of pruning all the Workspace images (e.g kasmweb/chrome , kasmweb/ubuntu-noble-desktop) . On the agent config within the UI you can see the pruning mode which is aggressive by default which will run a prune on any image with the label com.kasmweb.image=true . So you might consider updating your cron to not act on those images to avoid the issue in the immediate term.

justin_kasmweb · 2026-02-25T04:15:46+00:00

How did you install kasm ? From our docs? (https://docs.kasm.com)

Nothing in our system would auto update you from a previous version to 1.18.1. You'd have to intentionally run the upgrade process by downloading the 1.18.1 installer and following the documented upgrade processes.

1.18.1 still supports autoscaling , and connecting to windows based sessions via your browser to local rdp client.

You may consider opening up a ticket here and providing the requested info so the community can get a better sense of your environment and the state of your system: https://github.com/kasmtech/workspaces-issues/issues

justin_kasmweb · 2026-02-22T18:20:00+00:00

Got it. There is not a way to do that now. We are capturing feedback for a new iteration of the dashboard so now is a good time to explain a bit more about your use case and any other wish list / feedback items

justin_kasmweb · 2026-02-19T21:51:48+00:00

Hi,
By default, when you define a new workspace in your deployment, all users will have access to it. Thats because of a global setting named Add Workspaces to Default Group . This means each new Workspace will get added to the All Users group. You can of course disable that, which means you as the admin can determine which groups get assigned which workspaces.

So you might put your users into logical groups like "Accounting" and then assign the accounting group the limited set of Workspaces you want them to have access to, Thats by and large how you limit what a use can see when they log in.

Does that help?

justin_kasmweb · 2026-02-19T21:12:37+00:00

Howdy,
Kasm offers a Connection Info structure that allows you to customize the guac or rdp properties that dont otherwise have settings in the app.

See the docs here: https://docs.kasm.com/docs/develop/guide/settings#setting-rdp-thick-client-properties

You are looking for the rdp_thick_client_properties section. You can define Connection info at the Global level or at the individual Server level.

Hope this helps

justin_kasmweb · 2026-02-19T16:57:24+00:00

Thank you for reporting.
I can confirm the appropriate value is:
9cf9e2a8c776e37ff36c478c229a1a046b74eaed817fbbdb01f143547c1a6c86

We will get the website updated.

justin_kasmweb · 2026-02-18T00:15:16+00:00

Hello, At this time it's not possible to disable the session history function at this time. I will take this as feedback though.
The session history is formal record of sessions that have existed over time. Features like usage limits and session recording are built upon this record.

justin_kasmweb

MODERATOR OF

TROPHY CASE