Kasm VDI on Proxmox: Autoscaling Virtual Desktops Made Easy

Looking for a modern Virtual Desktop Infrastructure (VDI) solution that’s easier to deploy, scale, and manage? In this video, I’ll show you how to set up Kasm Workspaces with Proxmox VE and take advantage of Kasm’s powerful autoscaling capabilities to automatically provision virtual machines on demand.

We’ll begin by exploring what Kasm is, how it differs from traditional VDI solutions, and why organizations are increasingly turning to containerized and browser-based workspaces for remote access, development environments, application delivery, and secure desktop access. I’ll also explain the fundamentals of Virtual Desktop Infrastructure (VDI) and discuss the benefits Kasm can bring to enterprise IT environments.

From there, we’ll walk through the Kasm platform, launch several example workspaces, and then dive into the process of implementing autoscaling with Proxmox VE. By the end of this tutorial, you’ll understand how Kasm can automatically create and manage virtual machines when users request new workspaces, making it possible to build a highly scalable self-hosted VDI platform.

Kasm Links

What is Kasm?

Let’s take a moment to recap what Kasm is — I’ve covered this before, so I’ll keep it brief.

Kasm is a platform that makes it easy to deploy apps and services on your network and access them directly through your web browser. For example, you can spin up a secure, isolated Firefox session, launch an Ubuntu desktop from a Windows machine, or run a Windows desktop from Linux — it works in both directions. Each of these is called a workspace, and each one is purpose-built for a specific task, whether that’s a single application or a full operating system.

Now, that might sound complicated — configuring entire environments, managing individual apps — but that’s exactly what makes Kasm stand out. Installation comes down to running a single setup script, after which you access the Kasmdashboard in your browser, log in, and choose a workspace to launch. That’s genuinely it. And it runs on everything from a high-end Dell PowerEdge server to a Raspberry Pi sitting in your closet.

Those qualities make Kasm appealing to homelabbers and enterprise teams alike — but for organizations, there’s an additional layer of value, particularly around security and compliance. Workspaces in Kasm are isolated by design, meaning users interact with applications in contained environments that never expose the underlying infrastructure. Kasmcan also help you achieve HIPAA, NIST and other compliance standards.

The bottom line is this: Kasm’s goal is to make secure remote environments easy to manage and accessible to everyone — whether you’re running a homelab in your basement or deploying infrastructure across an entire organization.

What is “VDI”?

Now let’s talk about Virtual Desktop Infrastructure — VDI for short.

The core idea is straightforward: instead of installing apps and services directly on your local machine, you run everything through a remote desktop service. Depending on the solution, that could mean a complete desktop environment or just a single application streamed to your browser.

That might sound unnecessary at first, but there are some genuinely practical use cases — even for everyday users. Take Linux users as an example. Most of us have encountered that one application that still doesn’t have a native Linux version, and maintaining an entire Windows installation just for a single app isn’t exactly efficient. With VDI, you can run it in your browser regardless of what OS you’re actually sitting in front of. Privacy-conscious users can spin up isolated browsing sessions that leave no trace on the local machine. Developers can test their code against multiple Linux distributions simultaneously, each in its own browser tab. And if you really want to put Kasm through its paces — yes, you can run Doom in it. And honestly, if something can’t run Doom I’m not sure I can take it seriously.

For enterprise users though, the benefits go much deeper — and this is where VDI starts to address some genuinely serious problems.

One of the biggest threats any organization faces is a data breach. The financial and reputational damage from a breach can take years to recover from — if the company recovers at all. But here’s a principle worth keeping in mind: threat actors can’t steal data that isn’t there. If an employee’s laptop gets compromised, the damage is limited if sensitive data never lived on that device in the first place.

That’s the core security argument for enterprise VDI. Sensitive information stays on centrally managed, approved servers — it never touches endpoint devices. And as a bonus, companies can safely support remote workers and BYOD policies, because employees are working inside predefined, controlled environments running in their browser rather than directly on their personal hardware.

Getting Started with Kasm

Now that we’ve covered what Kasm is and why VDI matters, let’s talk about actually getting it running.

I’ve walked through the full installation process in previous videos, so I won’t go into extreme detail here – but what I’ll do instead is give you an overview of what the overall process is like.

The first decision is where to run it. Kasm isn’t picky — a physical server, a virtual machine, a cloud VPS — it just needs somewhere to live. If you’re not sure what size of system you need, Kasm provides a sizing guide in their documentation which I’ll link to in the description.

As for the operating system, Kasm runs on most popular Linux distributions and also supports Windows. But since this is a Linux channel, here’s what the process looks like on Linux.

You’ll SSH into your server and run three commands:

bash

cd /tmp
curl -O https://kasm-static-content.s3.amazonaws.com/kasm_release_1.18.1.tar.gz
tar -xf kasm_release_1.18.1.tar.gz
sudo bash kasm_release/install.sh

The installer will run for a few minutes, and when it finishes it will output the credentials you need to log in. From there, just point your browser at the server’s IP address or fully qualified domain name, enter those credentials, and you’re in.

Once you’re in the dashboard, head over to Workspaces to see what’s available out of the box. Let me launch one right now so you can see just how straightforward the process is.

(Note: I’ll record a walkthrough of the process unscripted)

Kasm ❤️ Proxmox

Now that we’ve established Kasm as a serious VDI platform, it’s time to put that into practice. In this section we’re going to set up a Kasm cluster inside Proxmox from start to finish.

Why Proxmox? Well, I’ll be honest — part of it is selfish. Proxmox is my favorite virtualization platform, and if you’ve spent any time on this channel you’ve probably noticed I don’t need much of an excuse to talk about it.

But there’s a legitimate reason this time. On April 20th, Proxmox and Kasm announced an official partnership, positioning the two together as a full-stack VDI solution. And it’s a natural fit — Proxmox provides the virtualization layer that Kasmruns on, and Kasm can use Proxmox’s infrastructure to autoscale its resources on demand. That means as users spin up workspaces, Kasm can automatically provision additional resources from Proxmox to match the load — and scale back down when they’re no longer needed.

That autoscaling behavior is exactly what we’re going to demonstrate. We’ll build the entire Kasm cluster inside Proxmox so you can see how the whole thing comes together.

I’ll assume you already have Proxmox up and running and have a basic familiarity with it. If not, I have a full Proxmox course on this channel that covers everything you need — I’ll link to it in the description.

Let’s build it.

Proxmox Demonstration (New)

Next, it’s time to revisit another of my favorite technologies, Proxmox! When you combine Proxmox and Kasm together with autoscaling, it becomes even more effective.

And by autoscaling, I’m referring to a concept where individual servers come and go as needed, rather than having a fixed number all the time. For example, if the company you work for provides software downloads, you can reasonably expect more traffic when you put out a new release. In that case, you can set up your infrastructure to create new servers as demand increases, and automatically remove them when it slows back down.

Putting this all together, Proxmox is a fantastic virtualization solution and makes it easy to spin up virtual machines. Kasm can be installed as a Proxmox VM, but even better it’s able to communicate directly with the Proxmox server it’s running on and create and remove worker VMs as needed to keep up with user demand at any given time.

Of course, autoscaling isn’t required in order to use Kasm. It’s a great choice for mission critical deployments where you need that kind of scaling and fault tolerance, but for small organizations a single Kasm instance can serve you just fine.

That said, what I’ll do in this section is outline the entire process, step by step. Also worth noting is the fact that all of the commands I’ll be using in this section can be found in the official blog post for this video, which will be linked down below.

If you want to set this up, the first thing I recommend creating within Proxmox is a resource group. This will help you organize Kasm-related objects under one namespace, which helps keep things organized.

The next thing you’ll need is a Kasm VM. If you’ve already created an instance for Kasm and set it up, then you’re good to go – just add it to your Kasm resource group, and we’ll continue on.

If you haven’t set up Kasm yet, I’ve covered the entire installation process in another video – which I’ll leave a card for here. But if you want to speed through the process right now, what you’ll need is an ISO file for your chosen distribution (I used Debian in my case). The easiest method is to copy a download link for your distro’s ISO file, and in Proxmox you can go to your primary storage, click on ISO images and have Proxmox fetch the ISO file for you.

Next, you’ll create a new VM – and note that it’s highly recommended to create a VM and not a Proxmox container, as the latter is unsupported. As you create the VM, it’s recommended that you set it up with at least 2 CPU cores and at least 4GB of memory, but if you plan on using Kasm heavily you might need to adjust those numbers accordingly. While you’re tweaking resource settings, ensure CPU type is set to “host”.

Also, as you go through the process it’s recommended to set the system type to “q35”, enable the Qemu agent checkbox, set SCSI mode to VirtIO SCSI Single, and the disk type to VirtIO Block. If your Proxmox storage utilizes an SSD, enabling Trim support can be helpful.

After that, it’s just a matter of going through the setup process for your distribution, and then once it’s done you can install Kasm.

On Debian, I first installed the curl package since it’s not a part of the default Debian image, and then after that I simply followed the commands from Kasm’s “Single Server” documentation page – and that was super easy, as all I had to do was download their installer, extract it, and then run the install script. The commands that you’re seeing on the screen right now will get Kasm installed (which can also be found in the blog post for this video).

When the process is all done, you’ll be provided your login credentials.

Creating a template instance

After you get Kasm up and running, another component you’ll need is a template that it can use for spinning up new instances. For this, all you have to do is repeat all the same steps I just gave you for creating the Kasm VM itself, but you don’t have to actually install Kasm, the only requirement is that you have another server we can later convert to a template. Also, it’s worth noting that you can create Windows templates too – Kasm isn’t limited to just Linux.

Anyway, before you create the template, there’s a few commands you can run to make sure each instance Kasm creates doesn’t get the same machine ID. This is a unique identifier, and it should be different each time. To fix that, all we have to do is clear the current machine ID inside the template VM, and when new instances are created a new one will be generated for each:

sudo truncate -s 0 /etc/machine-id

sudo truncate -s 0 /var/lib/dbus/machine-id

Finally, we’ll shut down our server, and convert it into a template. At this point, write down the name you gave your template, as we’ll be needing it later.

Create a dedicated kasm user

Continuing, we’ll next create a dedicated user for autoscaling, and the reason for that is because it’s always better to have dedicated users for system level services, not just for resource isolation but also because it helps us organize our infrastructure logically.

To set up our new user, we’ll click on Datacenter, Permissions, then Users. We’ll create a user named kasm-autoscale-user, and we’ll set the authentication mode to “Proxmox VE Authentication”. Be sure to add this name to your notes, it’s one of the things that Kasm will ask for later.

Create an API Token

Next, we’ll create an API token, which is going to end up being what Kasm will use to communicate with the underlying Proxmox server.

To create it we’ll click on “API Tokens” and then click “Add”. Here, we’ll choose the user that we created earlier, and we’ll uncheck “privilege separation”. Once we click add, we’ll generate a new Token ID (be sure to save this information somewhere safe, we’ll be needing it shortly).

Create a role

After that, we’ll create a Role, which will tie everything together that we’ve created so far. The role that we’ll be creating will contain the individual permissions that Kasm will need in order to carry out its tasks. So, we’ll click “Role” and I’ll add mine as “kasm-autoscale-role”.

We’ll need to add several permissions, 15 in total:

Pool.Audit
VM.Allocate
Datastore.AllocateSpace
SDN.Use
SysAudit
VM.Audit
VM.Clone
VM.Config.CDROM
VM.Config.CPU
VM.Config.Disk
VM.Config.HWType
VM.Config.Memory
VM.Config.Network
VM.Config.Options
VM.PowerMgmt

After that, we’ll associate the role to the user we created earlier. So, we’ll go back to “Permissions” and click “Add”. We’ll create three permissions here:

/sdn/zones/

/storage/

/pool/Kasm

Configuring Kasm for Autoscaling

The final step for setting up autoscaling within Proxmox is to configure Kasm to be able to interact with Proxmox. And this is where everything pretty much comes together.

To configure Kasm, we’ll expand infrastructure, then click Zones. Here, we’ll set the upstream auth address to the IP address of your primary Kasm VM, the one we created in the very first section.

Then, in pools, we’ll click add, and set “Docker Agent Pool” and type “docker agent”, then click “save”.

After that, we’ll click autoscale configs, give it a name, set the pool to “docker agent pool” and set deployment zone to “default”.

We’ll also configure Downscale backoff, which refers to how long Kasm waits before removing a server. For example, if resource usage starts to lower and Kasm determines it has more servers than it needs, it will delete servers that aren’t necessary. Here, we’re setting the number of seconds before Kasm starts to do that. We can just set this to 100 seconds, and that should be fine.

Standby Cores refers to how many VMs minimum Kasm will need to have, and if it ever falls below this (for example, a server gets deleted or stops working) then Kasm will create more servers until it has at least this many.

Continuing, under “VM Provider Details”, this is where we specifically instruct Proxmox how to interact with Proxmox itself. We’ll choose Promox here, and give it a name.

We’ll set Max Instances to 2, and the username we enter here should be the exact name of the user we created within Proxmox for Kasm. Token name is the name of the API key we created, and the value is the secret key that was generated earlier.

We’ll also disable SSL, just to keep it simple for this tutorial. However, if you do set up SSL later on (which is a good idea) you’ll need to enable this.

After that, we’ll choose our VM ID range. This refers to the VM ID’s that are assigned to nodes, we can choose a minimum and maximum value here. Basically, every VM or container that Proxmox creates has a unique number, and since we’re setting up autoscaling, we don’t want to have to choose the ID every time, we’ll let Proxmox do that automatically. So in this case, the
lower ID I’ll set to 1000, and the upper to 2000.

Next, we’ll need to instruct Proxmox which template to use as the base OS of any nodes it creates. We created a template in Proxmox earlier in this section, so we’ll copy the exact name of our template here.

For the cluster node name, we’ll set that as “pve”

The pool name will be the same as the resource pool we created in Proxmox. Finally, we’ll leave the target node blank.

We’ll set cores to 4, and memory to 8. For the startup script path, we’ll set that to /tmp

Also, set “Linux” as the OS type

The last thing we’ll set up here is the startup script. The idea here is that anytime Kasm creates a new Proxmox instance, it’ll need to set up Kasm on that device. Remember, we didn’t install Kasm in the VM template, we only installed Debian. There’s no actual software installed within our template other than what comes with Debian. Whenever an instance is created by Kasm, it’ll run the code that we enter into this box automatically. For this, we can use one of Kasm’s startup scripts, which I’ll link in the description below. All you have to do is copy everything, and paste it in here.

And that’s it! At this point, if everything was done correctly, we should see instances start to appear within Proxmox!