This feature requires an Enterprise license. Please contact a Kasm Technologies representative for details.

Session Recording

The Session Recording feature allows administrators to record user activities passively for compliance or monitoring purposes. These recordings are initially saved in segments on local storage. Later, they are converted to videos and uploaded to a pre-configured storage bucket.

Session recording is supported on container based workspaces as well as RDP, VNC, and SSH server based workspaces. Containers must be either 1st party Kasm published images, or built upon the 1st party images with 1.15.0 tags or newer.


Session recording is a CPU intensive task and will have an effect on the sizing of Connection Proxies and Agents. Refer to the Kasm sizing guide for more information.


Session recording is not supported on staged sessions. If a user has a group with record_sessions set to True, and selects a workspace that has staged sessions provisioned a fresh on demand session will be provisioned for the user instead.


  • Log into the Kasm Web UI as an administrator.

  • Click Settings->Global.

  • Configure session recording (see settings for more detail):

    • Define Object Storage Key

    • Define Object Storage Secret

    • Define Session Recording Upload Location

    • Modify Session Recording Bitrate if desired

    • Modify Session Recording Framerate if desired

    • Modify Session Recording Width if desired

    • Modify Session Recording Height if desired

    • Modify Session Recording Retention Period if desired

    • Modify Session Recording Queue Length if desired

  • Enable session recording for the desired groups:

    • Click Access Management->Groups

    • Edit the desired group

    • Click Settings

    • Click Add Setting

    • Search for record_sessions setting and set to True


For container based Workspaces, Workspaces that have sudo or root access enabled will result in the user having enough permissions to subvert the session recording process and prevent those recordings from being uploaded to the cloud.


Changes to feature licensing may take up to 10 minutes to be applied since certain requests are cached by the system. If after applying the license and making all of the above configuration changes sessions are still not being recorded check the logs for warning/errors. If Kasm logs that the feature is not licensed wait 10 minutes for the cache to be refreshed and try again.

S3 Endpoint configuration

By default, the endpoint used for S3 access is Administrators may desire to specify a custom endpoint in order to support the following use cases.

  • A private VPC Endpoint

  • AWS Gov Cloud end-points

  • Region specific end-points

  • AWS S3 Accelerated Endpoints

  • S3 Compatible Solutions

To specify a custom endpoint, in the Workspaces settings, format the Session Recording Upload Location path in the following format:


The following example configures Kasm to use GCP Cloud Storage (an S3 compliant cloud storage provider) for a session recording storage, where kasm is the bucket name, is the endpoint name, and the remaining is the path with {user_id} replaced by the Kasm user ID, {image_friendly_name} replaced by the workspace name, and {start_date} is replaced by the date the user started the session.



Some S3 compatible providers will have additional requirements to be compatible. For instance GCP cloud storage also requires the use of HMAC keys for authentication. Please consult the documentation for the choosen provider to ensure all neccesary configuration is met.

S3 Session Recording Variable Substitution

The session recording upload location setting provides the ability to specify template variables that are automatically filled in by Kasm when uploading the recording clip. The table below lists each valid template value and an example of what the value looks like.

Template name

Example Value












2023-12-12 21:12:45.386547




2023-12-13 20:27:13.853047




1706554545220 (in millisecond resolution)


The connection proxy, which relies on Guacamole, records RDP, VNC, and SSH sessions in a rolling fashion, breaking the data into 150MB segments. These segments are initially stored in an intermediate format and are later converted into a playable video using the guacenc encoding tool. These are video only recordings, audio from the session, or recording of what the user says into their microphone is not recorded. If recording is set to true and the system is unable to initiate recording, for instance because the connection_proxy has run out of space, or because the global settings are invalid, then the session is not provisioned for the user to prevent an unrecorded session the administrator intended to be recorded.

Resource Considerations

It’s important to note that session recording involves CPU-intensive video encoding. The number of videos that can be concurrently encoded is controlled by the Session Recording Queue Length setting. Each concurrent video encoding process typically utilizes one CPU core. To prevent negative impact on session performance, adequate resources should be allocated to the connection proxy. Additionally, session recording requires local storage space for the real-time encoding of active sessions. As a general guideline, at least 1GB of local storage should be available for each connected user. The system will prevent new users from connecting if the available local storage falls below 500MB and session recording is required for the connecting user.

Failure Recovery

In cases where there are interruptions in user connectivity or instances of reconnection, the system will still proceed with the encoding and uploading of pending session recordings. This guarantees that no session data is lost due to these disruptions. If there are any problems with the upload process, the recorded files will be retained on local storage. The system will continue to attempt to upload these files periodically. The duration for which these files will be locally retained is controlled by the Session Recording Retention Period setting.

Viewing Session Recordings


Users will need the SESSIONS_VIEW group permission to view the session history page. Users will need the SESSION_RECORDINGS_VIEW group permission to be able to view the session recordings on the session history page.

There is a new administration page under Sessions->History that displays a history of all past sessions.


Session History

This is also where users can view the recordings for each session. If session recordings are available there is a side arrow for that session row that will expand to allow selecting either a download or a view option.


View and Download options

Clicking the download button will zip up and download all clips for that session. For the Download All option to work the s3 bucket must be configured for CORS. See the section on setting up s3 bucket CORS configuration below.

A log similar to User admin@kasm.local downloaded entire session: 10307f51fd2749f3a84a7aaa2f81d26e will be generated whenever a User downloads all recordings for a session. This allows an administrator to track when recordings are downloaded.


Download All

When clicking on the preview (eye) icon the user is taken to a screen that lists all the clips for the session along with thumbnails, a download button (small cloud icon with a down arrow next to the clip number) for each individual clip, and a video playback window. For the Download button to work the s3 bucket must be configured for CORS. See the section on setting up s3 bucket CORS configuration below.

Clicking on the video player window will initiate playback of the selected clip.

A log similar to User admin@kasm.local played 10307f51fd2749f3a84a7aaa2f81d26e video: s3:// will be generated whenever a User plays a recording for a session. This allows an administrator to track when recordings are viewed.

Clicking the download button will allow the user to download the individual clip that is selected.

A log similar to User admin@kasm.local downloaded 10307f51fd2749f3a84a7aaa2f81d26e video: s3:// will be generated whenever a User plays a recording for a session. This allows an administrator to track when recordings are viewed.



S3 CORS configuration

When utilizing the download options for the recording clips there are CORS settings on the s3 bucket that have to be configured. Two providers are covered here, Amazon S3, and GCP cloud storage.

Amazon S3

Select the Amazon S3 bucket that will be used for storing session recordings. Select the permissions tab and scroll down until you see the Cross-origin resource sharing (CORS) section click edit and configure it as below replacing with the appropriate origin (the Kasm domain).


Amazon S3 Bucket Permissions


Amazon S3 Bucket CORS permissions

CORS configuration
        "AllowedHeaders": [
        "AllowedMethods": [
        "AllowedOrigins": [
        "ExposeHeaders": []

GCP Cloud Storage

Like Amazon S3 GCP cloud storage buckets need to have CORS configuration applied for Kasm to be able to provide the download access for recording clips. GCP only supports bucket CORS configuration through the commandline gcloud client. Download and install the gcloud client follow the instructions to apply a CORS configuration the following is an example configuration that should work when replacing with the Kasm domain of the installation.

CORS configuration
      "origin": [""],
      "method": ["GET", "PUT", "POST", "DELETE"]