Tech Guides

I built a private cloud workspace at home, and it was easier than I expected


SSH, RDP, and VNC, I’ve used every remote access protocol out there, and they all have their place. The thing is, the reason these protocols and platforms are useful is also their biggest problem. When I’m connecting to a remote machine at home, I’m accessing an entire PC and desktop that needs constant maintenance and security because it’s reachable from outside my network.

What I really needed was a private web portal where I could launch remotely-published desktops and apps from inside a browser, from anywhere. That led me to KASM Workspaces, which is a browser-based desktop I could install on my own server. It allowed me to run disposable and persistent desktops, or just individual apps, for free, from anywhere.


Windows 11 on running on a MacBook


Microsoft Remote Desktop: How to Access Windows From Your Mac

Use Microsoft’s free Remote Desktop app to get remote access to your Windows PC from a Mac.

I needed something better than RDP and VNC

Remote access works, but it’s too clunky

RDP and VNC are still super useful remote access tools, but they rest on an outdated assumption. You connect to your remote computer, then you have to work from whatever state that computer happens to be in. If the desktop is cluttered, you’re stuck with it. If the connection to the remote machine is poor, your session is laggy and unproductive. If you just want to run, say, Slack or Discord, you inherit the whole environment, including whatever scaling the native desktop is running.

But what about managing apps over SSH and X11? Yeah, it avoids that mess, but it’s also a terrible experience on mobile. A VPN can help, too, but you’re still stuck with the remote desktop itself.

KASM is different because it’s a remote app publishing platform, a little like Citrix and Neverinstall. With KASM, instead of remoting into my messy box back home, I logged into a clean web portal and launched what I needed. Sometimes that was a full desktop, a terminal, or a disposable testing workspace. KASM felt more like my own private launcher rather than a remote desktop connection. Best of all, it’s completely free for private use.

What I used for my KASM server

It doesn’t need to be a supercomputer

KASM running Debian Trixie full desktop in a workspace

I used an Ubuntu 24.04 LTS minimal install VM with a public subdomain hostname attached to a domain I already own. I wanted my setup to feel like a real service, so I used a proper domain hosted for free on Cloudflare rather than an IP address and an ugly self-signed certificate warning. That also made it significantly easier to add a trusted Let’s Encrypt certificate later on.

You don’t need a monster server for KASM, but RAM is probably the most important factor when choosing a setup, since that’s where the workspaces will run.

Requirements

Minimum

Recommended

CPU

2 cores/2 vCPUs

4 cores/4vCPUs

RAM

8GB

32GB+

Storage

OS + 50GB

OS + 200GB+

Network

Local or public access (no CGNAT)

VPS

OS

Ubuntu Server 24/Debian 12

Ubuntu Server 24/Debian 12

Open Ports

443 (HTTPS)

22 (SSH), 80 (HTTP), and 443 (HTTPS)

In my setup, I opened ports 22 for SSH, 80 for Let’s Encrypt, and 443 for the KASM web front end itself.

Setting up was the easy part

Installation was even easier

UFW port firewall rules for KASM server

I started with a fresh, minimal Ubuntu server and set up the usual first. Creating a new user, adding them to sudoers, and taking basic steps to secure SSH in Linux, like disabling root SSH login. Then I updated the server and opened up the ports I needed by enabling the UFW firewall:

sudo apt update && sudo apt upgrade -ysudo apt install curl ufw -ysudo ufw allow OpenSSHsudo ufw allow 80/tcpsudo ufw allow 443/tcpsudo ufw enable After that, I followed KASM’s single-server installation steps:

cd /tmpcurl -O https://kasm-static-content.s3.amazonaws.com/kasm_release_1.18.1.tar.gztar -xf kasm_release_1.18.1.tar.gzsudo bash kasm_release/install.sh The KASM installer is simple and easy, and handles the interface, web portal, workspace, and container setup on its own.

KASM installation complete showing admin and user credentials

The only gotcha here is that the installer creates the admin@kasm.local and user@kasm.local credentials. It’s best to copy these down immediately, as you’ll need them to log in. The KASM web interface was up and running as soon as the installation script finished, and it was just a matter of opening the public hostname in my browser to get access.

The first login worked straight away, although the self-signed certificate warning made the whole thing feel unfinished.

KASM login page with self-signed certificate

I made it official with Let’s Encrypt

Remove the ugly self-signed certificate

KASM workspace login page with TLS certificate

Nothing bugs me more than having to see a self-signed certificate and click through a browser warning every time I want to access my own platform. Since I already had a subdomain pointing at the server, the next obvious step was to make it all nice and polished with a free Let’s Encrypt TLS certificate.

This meant stopping KASM, installing Certbot, and requesting a new certificate for the domain:

sudo /opt/kasm/1.18.1/bin/stopsudo apt install certbot -ysudo certbot certonly –standalone -d kasm.ggcontentlabs.com After that, I just replaced KASM’s default certificate files with the new Let’s Encrypt certificate and restarted KASM:

sudo /opt/kasm/1.18.1/bin/start A quick refresh of the page later, and the ugly browser warning was gone. Now my KASM workspace feels a little less “lab test” and more “production-ready.”

Workspaces and persistent profiles turned it into something useful

Disposable desktops are fun, but I wanted my settings back

KASM user workspace launcher with apps

Once I logged in and created a new admin account, I started publishing some workspaces. First, I added a full Debian Trixie desktop, then a Chrome browser, a terminal, and finally a few tools I use all the time when out and about, on holidays, or at work. Just in case anyone is wondering, yes, you can play Doom on KASM.

Launching a desktop inside a browser felt strange at first, but it soon became natural. Once a desktop or an app is opened, you can log out or choose to destroy it. Destroying a session removes all settings and files, which is handy for testing but not ideal for full-time use.

Split screen view of KASM persistent profiles in desktop and host

Persistent profiles are what I used to fix this. This means enabling the feature inside KASM and creating a folder structure within the Ubuntu server, typically at /mnt/kasm_profiles/. Then it’s simply a matter of assigning that path to individual workspaces using the path /mnt/kasm_profiles/{user_id}.

Once the persistent profiles path has been added to a workspace, all apps and desktops then have access to it. Any file, folder, or setting made inside a desktop becomes sticky, even if the workspace or app is destroyed. You can still run a desktop or app as a disposable workspace. It’s just a matter of deselecting the persistent profile option when it’s first run.

Profiles are not backups in KASM. Remember to regularly back up your KASM persistent profile path to make sure you never lose any important files.

A few settings to tighten before using it daily

Treat it like you would a remote desktop

Enabling MFA on a KASM workspace user

Having a fully functional desktop and apps to launch remotely is handy, but it’s important to remember that you’re still accessing your own server remotely. Anything that’s exposed to the internet deserves some careful security habits.

I created a new admin account and disabled the default one. I also enabled Multi-Factor Authentication for both admin and user accounts. On the server side, I keep Ubuntu and KASM updated, including the registries for the workspaces themselves.

Another lesson I learned quickly is that workspaces grow considerably as you use them, and there’s a real risk of running out of disk space. The Linux terminal, for example, takes up 2.1GB once it’s shared across all users. Desktops and larger applications can easily grow beyond 10-20GB. So, if you’re planning on giving KASM a go, watch your storage because you can be left with a server that can’t even run itself once your storage fills up.

Forget RDP and VNC, KASM is far more useful

It won’t replace my main PC, but it means I can turn off RDP

I started my KASM experiment thinking I was going to get a neat little browser-based remote desktop toy. What I ended up with actually grew into a daily-use private cloud that I can access from anywhere on nearly every device. HTTPS made it feel professional and polished, the workspaces let me run and access the internet using my residential IP address, and the persistent profiles made it something I could continue to use confidently.

If you’re just after an SSH terminal back home, KASM is definitely overkill, and it won’t replace my main PC or even my VPN any time soon. But for isolated browsing and avoiding exposing my homelab servers to RDP and VNC port scanning, KASM is hands-down the most useful self-hosted productivity project I’ve ever tried.


Tailscale dashboard.


I access my home server from anywhere in the world without port forwarding

Homelabbing made real easy.



Source link