Install Kasm Workspaces in 10 Minutes (Docker + Remote Desktops in Your Browser)

At a glance

Sonoran Tech opens with the two moments that make a person want disposable computing: you hover over a link you do not fully trust, and you sit down to check a bank account on the same machine that has everything else on it. His answer is Kasm Workspaces, a self hosted platform that runs containerized apps and full Linux desktops on a server in your home lab and streams them into a browser tab. You launch a workspace, use it, close it, and it is gone. Nothing was ever installed on your machine and nothing survives the session unless you deliberately ask it to.

The video is deliberately ordered demo first, install second. He shows Chrome running in a tab, then a whole Ubuntu desktop in a tab, then explains where disposable stops being enough and persistent profiles take over. Only then does he build a fresh Proxmox virtual machine, install Ubuntu Server on it, paste the single server install command straight off the Kasm documentation, and get a working console in one script run.

The last third is the part most quick start videos skip. He enables persistent profiles, which is the feature that turns Kasm from a novelty into something you use daily. That means creating one directory on the host, setting ownership to uid and gid 1000, locking it to mode 700, and then configuring a profile path per workspace, because there is no global switch. He proves it by touching a file inside an Ubuntu session, destroying the session outright, launching a fresh one, and finding the file still there.

This page rebuilds all of it in the video's order: every command, every port, every version string, the exact VM he sizes, the credentials warning he is emphatic about, the access management screens he detours into, and the one gotcha that bit him live on camera. A reader who never plays the video can go from an empty hypervisor to a Kasm install with working persistent profiles.

The pitch: computers you can throw away (0:00)

He starts with a question rather than a product. Have you ever paused before opening a link, or before browsing to something like your bank account, and worried what if something goes wrong, what if I get hacked? Or have you ever wanted a clean Linux desktop set up just for one task, and then wanted it gone like it never happened? That is what Kasm is for, and he notes he has covered it more than once in previous videos.

The plan for this one is stated up front: show Kasm in action first, then walk through the installation using Docker Compose so you can get it running in your own home lab.

Then the definition. Kasm Workspaces is a platform that streams containerized apps and even full desktop environments right into your browser. The framing he gives it is a comparison against the reflex most home labbers have, which is to spin up a whole virtual machine just to test something. Instead of that, you launch a workspace, and the workspace can be Chrome, Firefox, Ubuntu, or whatever else. You use it, and when you close it, it is completely gone.

His verdict on why that matters is the thesis of the entire video: that disposable nature is the whole point of it. Fast, clean, and very useful.

The demos (0:56)

Demo one: a Chrome session that is not on your computer

He logs in to a running Kasm instance and lands on a catalog of workspaces. He picks Chrome. Kasm offers two ways to open it: right inside the current window, or in another tab. With a couple of clicks he has a Chrome session running in a web browser.

Then comes the sentence that matters. It is not running on his machine. It is running on a server inside a container on his home lab, and he is just streaming the UI in the browser.

Two use cases follow immediately from that fact:

• The link you do not trust. If he wants to open something questionable, he does it here.
• The bank account. He does not want to mix the rest of his machine's data with his banking session, so he does it in the workspace instead, and it is disposed of when he is done.

And that is the key part. When he is done he just closes the session and it is gone. No leftover browser state, no cache junk.

Demo two: an entire Linux desktop in a browser tab

Back to the workspaces screen, he opens Ubuntu. What appears is a full Linux desktop in a browser tab, running on the Kasm server.

He lists what that buys him. If he needs a quick Linux environment to run a tool, test a script, or even do some coding, he opens this. He can open VS Code inside it, clone a Git repository, do some work, let his AI agents handle the coding for him, and then dispose of it when it is done.

The alternative he is rejecting is explicit: he does not need to remote into a VM or keep a bunch of VMs around just in case. He launches this, uses it, and gets rid of it.

The obvious objection: what if I want to keep something

He raises the objection himself. Disposable is very cool, but what if you want to persist some stuff? With Kasm you can do both. You keep it disposable, or you enable persistent profiles so your settings and files stick between sessions. He calls that combination the sweet spot: disposable compute, with convenience when you want it.

Then he draws a boundary that is easy to miss and expensive to learn the hard way. Persistent profiles persist user data, and only user data. Think bookmarks. On an Ubuntu desktop workspace, it persists what is in the home directory. But:

If you start to do things like install applications or even run something like apt update, those changes will not persist.

For that you need a different workspace, and potentially a custom workspace built for your use case, which he explicitly says he is not covering in this demo.

Where he personally draws the line

He describes his real usage honestly, and it is more restrained than a product pitch would be. Kasm sits between two poles for him: needing a full VM where he really has to interact with the operating system and make changes, and wanting something very lightweight that he can throw away or persist just a little state in and come back to later.

In practice, most of his Kasm usage is the browser. He persists his bookmarks and a bit of other state, and then when he needs to open a link he is unsure about, or wants complete confidence that he is hitting a website from a completely clean machine, that is what he reaches for. Occasionally he opens the Ubuntu desktop as well, where he will open VS Code, clone his local Git repository, and work on it while using his own machine for something else.

But when he needs an actual full VM, when he has to make operating system changes or wants a particular configuration, he goes back to a full VM running on his Proxmox server. His summary: Kasm really fills a great sweet spot there.

Installation (4:22)

Build the host: a virtual machine on Proxmox

He drops into his Proxmox dashboard. He already has a Kasm VM running, the one he uses at home, but the point of the exercise is to build one from scratch, so he creates a new VM and names it Kasm 2.

The sizing decisions, exactly as he makes them:

• Image: Ubuntu Server. His words: that is fine.
• Disk: increased a little. He is not planning on putting a lot on this one, so he does not need a huge disk.
• CPU: eight cores. He immediately qualifies this, and the qualification is the useful part. This is on a big old slow server, so eight is actually not that much. Eight cores is a sizing decision about that hardware, not a Kasm requirement.
• Memory: he bumps it up on screen without stating a number in the narration.

He starts the VM, goes off camera to get Ubuntu Server installed, and comes back when it is done.

Get the command from the documentation

With the server up, he goes to install Kasm, and his framing is that this step is barely a step: installing this is literally as easy as going to their website and following the directions. The directions are dead simple.

The path he takes through the site:

1. Go to the Kasm site and open Resources.
2. Work with the Community Edition, the free self hosted tier. (If you want the full tier breakdown, the Learn Linux TV getting started page on this site covers the pricing table in detail; Community is $0 per user per month for self hosted use.)
3. Scroll to the bottom and find Documentation, which opens in another window.
4. In the docs, choose the single server installation. That is the simple path and it is what this video does.

He notes the docs also offer an offline install. He is honest that he has not tried it, but observes that it looks like it just predownloads everything.

The single server install is the following block, copied straight from the docs. The version string moves with each Kasm release, so take the current one off the install page rather than pasting a stale tag:

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

The offline variant, the one he skipped, pulls the service, workspace, and network plugin images ahead of time and feeds them to the installer by flag:

cd /tmp
curl -O https://kasm-static-content.s3.amazonaws.com/kasm_release_1.17.0.7f020d.tar.gz
curl -O https://kasm-static-content.s3.amazonaws.com/kasm_release_service_images_amd64_1.17.0.7f020d.tar.gz
curl -O https://kasm-static-content.s3.amazonaws.com/kasm_release_workspace_images_amd64_1.17.0.7f020d.tar.gz
curl -O https://kasm-static-content.s3.amazonaws.com/kasm_release_plugin_images_amd64_1.17.0.7f020d.tar.gz
tar -xf kasm_release_1.17.0.7f020d.tar.gz
sudo bash kasm_release/install.sh --offline-workspaces /tmp/kasm_release_workspace_images_amd64_1.17.0.7f020d.tar.gz --offline-service /tmp/kasm_release_service_images_amd64_1.17.0.7f020d.tar.gz --offline-network-plugin /tmp/kasm_release_plugin_images_amd64_1.17.0.7f020d.tar.gz

Run it, and yes, it needs sudo

He copies the command block, switches to the terminal on the new machine, and pastes it in straight from the website. It does not go cleanly on the first attempt, and he catches it live: it probably needs sudo. He puts it in with sudo and lets it do its thing.

This is worth calling out because it is the only friction in the entire install. The install script writes to system paths and drives Docker, so the final line has to run as root. The documented block already carries sudo on the install.sh line; if you retype the commands from memory instead of copying them, that is the line you will drop.

When it finishes, his report is short and accurate. It took a little while, but it was that simple. Run one script and it takes care of everything.

Write down the credentials. He means it.

The installer finishes by printing the default UI credentials to the terminal. He stops the video to be emphatic about this:

I highly suggest writing them down because you're not going to be able to get them back after seeing them here.

Then the war story that gives the warning teeth. He actually misplaced his admin credentials on one of his Kasm instances once. There is a way to reset it by going into the database, but it is non trivial. His recommendation: just save them.

Workspace setup (7:23)

The admin console, and the empty workspaces list

With the install done, he goes back to the browser, hits the server, and logs in. He starts with the admin account, because that is where you configure workspaces and everything else, and he promises to show the user account view afterwards.

The admin console appears. At the top there is a toggle that switches between the admin view and the workspaces view. Down the left side is the navigation. He clicks Workspaces and finds exactly what you would expect on a fresh install: none.

There is an Add button, and that is where you build a custom workspace. He is not going through that today.

Install from the registry

Instead of building anything, he uses the registry of available workspaces, which are predefined by Kasm. You click the ones you want and set them up. He installs four:

• Chrome
• Firefox ("why not")
• Ubuntu, since he demoed it at the start
• VS Code

While scrolling the registry, he points out how wide the catalog is. There are all kinds of applications on there, including Slack and Signal, and there are entire distributions, not just individual apps.

The installs download and set up in the background. He goes back to the workspaces list and can see them in the process of installing.

The detour: sessions, maintenance, and access management

While the images pull, he tours the rest of the admin console.

Active sessions on the left shows any session currently running. If another user is logged in and running sessions, you see them here. Past that there is a stack of general maintenance screens.

But the section he flags as the important thing is Access Management, specifically Users. Two jobs live there:

1. Adding users. Normal users or additional admin users.
2. Controlling which workspaces a user gets access to. This is the one he wants you to notice.

He demonstrates by opening the default user and clicking Edit. There is a pile of parameters on that screen, but the interesting one is the Workspaces tab, where you can see that by default this user can use any of the four workspaces just configured. You can customize that per user, or for entire groups. If you want a particular group that only has a certain set of workspaces, you can divide things up that way.

His own posture is much simpler, and he says so. That kind of granularity is for a more complicated configuration. For a home lab environment he has just stuck with a couple of users for the folks in the house and let them get at everything.

Back to the workspace installs: Chrome is done. He lets the rest finish before switching views.

The user view

Once the workspaces are installed he switches over. You can either click the tab to move to the normal view, or, as he did, log out and log back in as a normal user. He mentions he threw a couple of extra workspaces in while he was at it.

The user view is the catalog: the user picks one of these workspaces and opens it. He launches Firefox and, when Kasm offers the choice, opens it in a new tab.

Running, pausing, and destroying a session

Going back to the workspaces view as the user, the running Firefox session is now visible with controls on it. You can pause it, stop it, or whatever else you want to do.

And then the line that sets up the entire last chapter:

If you delete it, this is where all your state is gone.

He deletes it.

Persistent profiles (10:53)

This is the payoff section, and the reason to watch past the install.

The problem statement is precise. With the demonstrations he just gave, if you bookmark something in a Chrome tab, or in Ubuntu you write something to your home directory, that is just gone when you get rid of the session. There is a way to persist some data across sessions, and, as he repeats, it is mainly just user data.

Step one: create the profile directory on the host

You log back in to your Kasm host and create a directory where the local data will live, then set a couple of permissions on it. His example directory is /mnt/kasm_profiles, owned by uid and gid 1000, mode 700:

sudo mkdir -p /mnt/kasm_profiles
sudo chown 1000:1000 /mnt/kasm_profiles
sudo chmod 700 /mnt/kasm_profiles

His assessment of that: it is that simple.

The reason for those two specific values is worth spelling out, because the video does not. Uid 1000 is the unprivileged user inside a Kasm workspace container, so the mount has to be owned by 1000 for the container to write to it. Mode 700 keeps every other account on the host out of other people's profile data. Kasm's own persistent profiles documentation confirms the shape of this: /mnt/kasm_profiles/ is the only directory an administrator has to create, and every subdirectory beneath it is generated on workspace launch.

Step two: point each workspace at the directory, one at a time

Now back to the admin UI. You configure the persistent profile path for each workspace, and here is the trap:

This isn't some global setting. You need to go workspace by workspace and configure it.

He goes into his workspaces, picks Chrome as the example, and edits it. Scrolling down the workspace form there is a field labelled Persistent Profile Path.

He recommends not hardcoding a plain directory. There are variables you can put into the path that get filled out at launch, which lets the data be segmented by both user and image. For Chrome he sets it to the directory he created, then a subdirectory by user, and then by image, so the same user can have different data for each of the different images. Then he saves.

The tokens Kasm supports in that field, per the documentation, are:

Which makes a path of this shape, segmented exactly the way he describes:

/mnt/kasm_profiles/{username}/{image_id}

The docs' own recommendation puts the image first for uniqueness, /mnt/kasm_profiles/{image_id}/{user_id}, and offers /mnt/kasm_profiles/firefox/{username} as the human readable variant. Either ordering satisfies the rule that matters: every workspace gets its own profile path, so two different apps never fight over the same application configuration files.

Step three: choose per launch

Once persistence is enabled on a workspace, launching it changes. He notes he set it up for Chrome on camera, but demonstrates on the Ubuntu desktop, which he had configured slightly differently. It is basically the same thing.

You get a dropdown when you go to launch the workspace, and you choose whether to enable the persistent profile or not for that session. He picks enabled and launches.

That detail is the design that makes the whole feature work. Persistence is not a mode you are stuck in. The disposable behavior is still one dropdown away every single time you launch, so the same workspace can be your everyday browser with bookmarks on Monday and a scorched earth sandbox on Tuesday.

Step four: prove it

He jokes that he could show you how it does not work, but that would take a long time. So he goes straight to the proof.

Inside the launched Ubuntu session he opens a terminal in the home directory and creates a single empty file:

touch f

The file appears. Now the destructive part. He closes the session window, goes back to the workspaces view, and does not merely stop the workspace, he deletes it outright. His own reasoning, said out loud as he does it: this makes sense, because they created a directory where this state is stored, and that state will persist across the session even after it is gone, because remember, this is basically running in a container.

Then he opens a new one, with persistent profile enabled, in a new tab, and looks in the home directory.

The file is there. It persisted between sessions. And, as he points out, you can imagine doing exactly that with bookmarks or anything else in these workspaces.

Where the video stops, on purpose

He is upfront that this is a super quick introduction, and it is worth being clear about what that leaves on the table, because each of these is a real thing you will hit next:

• Custom workspaces. The Add button in the admin workspaces screen builds your own image. He explicitly skips it, twice, and it is the answer to the apt install limitation.
• TLS certificates. The install produces a self signed certificate, so browsers will warn on first access. He does not swap it. If you want a real certificate, the Learn Linux TV deployment page on this site walks through a Let's Encrypt swap.
• The offline install. Documented, mentioned, untried by him.
• Multi server and agent deployments. Everything here is the single server path.
• Storage mappings and S3 backed profiles. The other half of Kasm's persistent data story, beyond the host directory profiles shown here.

His closing assessment is the one he has earned by this point in the video: he personally finds Kasm very useful for creating environments that are easily disposable. Installation is a breeze, and your basic setup is a breeze as well. He signs off asking whether you are using it and how it is helping you.

Key takeaways

• Kasm streams containerized apps and full desktops into a browser tab. The workspace runs as a Docker container on your server; your machine only sends input and receives pixels. That is why the untrusted link and the bank session are both safe, and why nothing is left behind afterwards.
• The disposable behavior is the product, not a side effect. Close the session and the container is destroyed with every byte inside it. No leftover browser state, no cache junk.
• Installation is genuinely one script. Get the single server block from the Kasm docs, paste it, and remember sudo on the install.sh line. It takes a little while and does everything else itself.
• Save the credentials the installer prints, immediately. You cannot get them back from the screen. Recovery means going into the database and it is non trivial. He lost a set once.
• Workspaces come from a registry, not from you. Chrome, Firefox, VS Code, Slack, Signal, and entire Linux distributions are predefined; you click install. Building custom images is a separate exercise.
• Access Management controls who gets which workspace, per user or per group. For a home lab, a couple of household users with access to everything is a perfectly reasonable configuration.
• Persistent profiles need one host directory: /mnt/kasm_profiles, owned 1000:1000, mode 700. Everything below it is created on launch.
• The profile path is configured per workspace, not globally. Miss that and you will enable it once and wonder why the other three workspaces still forget everything.
• Use the path variables. {username}, {user_id}, and {image_id} segment the data so the same person gets separate state per app, which is what stops two workspaces fighting over the same config files.
• Persistence covers user data only. The home directory survives; apt update and installed applications do not. When you need those to stick, you need a custom workspace image, or you need a real VM.
• Persistence stays optional at launch time. A dropdown on every launch lets you pick disposable or persistent for that session.
• Know where Kasm stops. When he needs to change an operating system or hold a specific configuration, he goes back to a full VM on Proxmox. Kasm is the layer between "spin up a whole VM" and "just use my laptop."

Chapters

• 0:00 Intro
• 0:56 Demos
• 4:22 Installation
• 7:23 Workspace Setup
• 10:53 Persistent Profiles

Notable quotes

"Have you ever paused when opening a link or even browsing to something like your bank account and worried, what if something goes wrong? What if I get hacked?" Sonoran Tech, 0:03, opening on the problem instead of the product.

"Kasm Workspaces is a platform that streams containerized apps and even full desktop environments right into your browser." Sonoran Tech, 0:31, the definition in one sentence.

"And that disposable nature is the whole point of it. It's fast, clean, and very useful." Sonoran Tech, 0:50, the thesis of the video.

"It's not running on my machine. It's running on a server inside a container on my home lab and I'm just streaming the UI in the browser." Sonoran Tech, 1:22, the architecture, stated while a Chrome session is open in a tab.

"When I'm done, I just close the session and it's gone. No leftover browser state, no cache junk." Sonoran Tech, 1:44.

"This is a full Linux desktop in a browser tab running on the Kasm server." Sonoran Tech, 2:02, opening Ubuntu.

"I don't need to remote into a VM or keep a bunch of VMs around just in case. I just launch this, use it, and get rid of it." Sonoran Tech, 2:33, the alternative he is rejecting.

"This ends up being the sweet spot: disposable compute but with convenience when you want it." Sonoran Tech, 2:45, on combining disposable sessions with persistent profiles.

"If you start to do things like install applications or even run like apt update, those changes will not persist." Sonoran Tech, 3:06, the single most important limitation in the video.

"Installing this is literally as easy as going to their website and following the directions. And the directions are dead simple." Sonoran Tech, 5:26.

"It is all done. Took a little while, but it was that simple. Run one script and it takes care of everything." Sonoran Tech, 6:35, after the installer finishes.

"I highly suggest writing them down because you're not going to be able to get them back after seeing them here." Sonoran Tech, 6:42, on the credentials the installer prints.

"I actually did misplace my admin credentials on one of my Kasm instances once. And there is a way to reset it by going into the database, but it's non trivial." Sonoran Tech, 6:56.

"This is also where you can control which workspaces a user gets access to." Sonoran Tech, 9:07, in Access Management.

"And then if you delete it, this is where all your state is gone." Sonoran Tech, 10:50, deleting a Firefox session.

"We'll just put the directory in /mnt/kasm_profiles and then you set this to 1000 as the user and group and chmod to 700. It's that simple." Sonoran Tech, 11:43, the entire host side setup for persistent profiles.

"So this isn't some global setting. You need to go workspace by workspace and configure it." Sonoran Tech, 12:01, the gotcha that costs people an afternoon.

"There's actually variables that you can put into the path that will get filled out that allows the data to be segmented by both user and the image." Sonoran Tech, 12:20.

"And you can see it persisted. Yeah, it persisted between sessions." Sonoran Tech, 14:31, after deleting the session and launching a fresh one.

"Installation is a breeze, and your basic setup is a breeze as well." Sonoran Tech, 15:09, signing off.

Resources mentioned

The software

• Kasm Workspaces, the platform the entire video is about, streaming containerized apps and desktops to a browser.
• Kasm documentation, the docs site he opens from Resources on the main site.
• Kasm single server installation, the exact page he copies the install command block from, including the offline install variant he mentions but skips.
• Kasm system requirements, 2 cores, 4 GB, 50 GB SSD minimum, and the supported operating system list.
• Kasm persistent profiles documentation, the {username}, {user_id}, and {image_id} tokens and the /mnt/kasm_profiles/ convention.
• Kasm persistent data overview, the wider feature set, including the storage options this video does not cover.

Infrastructure he runs it on

• Proxmox Virtual Environment, the hypervisor hosting the Kasm VM, and where he goes back to when he needs a real VM instead.
• Ubuntu Server, the guest operating system for the Kasm host.
• Docker, what every workspace actually is.
• Docker Compose, named in the intro as the mechanism the install uses.

Workspaces he installs or names

• Google Chrome, the first demo and the workspace he configures a persistent profile on.
• Mozilla Firefox, installed from the registry, launched in the user view demo.
• Ubuntu Desktop, the full Linux desktop in a browser tab.
• Visual Studio Code, installed from the registry, and what he opens inside an Ubuntu session to work on a cloned repository.
• Slack, spotted in the registry while scrolling.
• Signal, spotted in the registry while scrolling.
• Git, cloning a repository inside a workspace.

The creator

• Sonoran Tech on YouTube, the channel, where he notes he has covered Kasm more than once before.
• Sonoran Tech on Instagram, the only link in the video description.

Related pages on this site

• Learn Linux TV: Kasm Workspaces simplified, the full getting started tour, including the admin console section by section, third party registries, and the complete pricing tier breakdown.
• Learn Linux TV: four ways to deploy Kasm, Proxmox, a cloud instance, a real Let's Encrypt certificate, and a one click marketplace droplet.

A note on the transcript below. YouTube's automatic captions do not know the product. Throughout the transcript panel, "Kasm" is transcribed as "Chasm" and "Ubuntu" appears variously as "Abuntu", "Auntu", and "iuntu". The audio is correct; the captions are not. Quotes on this page use the correct spellings.