Kasm Workspaces server on one dedicated machine: sizing, install, firewall

What the host has to provide

Kasm 1.19.0's system requirements list Ubuntu 22.04 and 24.04, Debian 11, 12 and 13, RHEL 8, 9 and 10, and AlmaLinux, Rocky Linux and Oracle Linux 8 and 9, on amd64 or arm64. It installs on bare metal or in a VM; Kasm does not recommend LXC or WSL. The docs recommend a single-purpose machine where the installer supplies Docker and Docker Compose. If Docker is already there at a version Kasm does not support (the minimum listed is 28.5.2), the install fails; an unsupported Compose is replaced automatically.

• Minimum for the services: 2 cores, 4 GB, 75 GB of SSD.
• Per session: the default Workspaces require 2,768 MB and 2 cores each. A session is not provisioned when the agent lacks that much.
• Disk: Kasm only measures free space on the volume holding /var/lib/docker. Check it with df -h /var/lib/docker before you start; too little can block the install.
• Swap: recommended for session stability. The installer offers to create a swap partition if none exists; --swap-size 8192 creates 8 GB unattended.

Sizing by concurrent sessions

The table is our arithmetic from the two documented figures: the service minimum plus the default reservation multiplied by sessions running at once. Named accounts that never connect at the same moment cost nothing. Workspace settings can raise or lower each session's allocation, which changes the sums.

Leave headroom on top for the host itself and for swap. Storage is the third axis: the 75 GB SSD minimum has to sit on the volume holding /var/lib/docker, and it grows with the images you pull, since each Workspace is a Docker image on that same volume.

Which machines carry it

Kasm wants the whole box, and a dedicated server is that: every core and all the memory for session containers, root to let the installer own Docker, and no neighbour's workload competing with interactive desktops. Every line in the catalogue has an unmetered port, so streamed desktops have no transfer allowance to burn through.

• Up to five sessions: a 16-core Xeon D-1587 cartridge with NVMe and up to 128 GB covers the Community ceiling with room for heavier Workspaces.
• Ten to fifteen sessions: dual-socket Xeon Gold 6130 machines, 32 cores across two sockets, which by the arithmetic above reserve out at 15 default sessions, with memory into the hundreds of GB.
• Twenty or more on one host: the quad-socket Xeon lines, 48 to 80 cores, roughly 23 to 39 default sessions. Past that, Kasm's multi-server layout is the better design.
• Not this one: X-Gene ARM. Its images stop at Ubuntu 18.04 (16.04 and 18.04 only), older than any release Kasm supports.

Desktops are latency-bound, so put the machine in the city nearest your users; the five locations each publish a test IP to ping first. Racked machines are handed over in about 30 minutes once payment is approved; built-to-order lines take 4 to 24 hours. Racked single-, dual- and quad-socket servers have an out-of-band console (iLO, iDRAC or a Supermicro BMC), which matters the day a firewall rule locks you out of SSH.

Firewall before the installer runs

Turn ufw on with SSH as the only allowed service before Kasm exists. ufw gets IPV6=yes first, because ufw writes IPv6 copies only of rules added while that setting is on.

sudo apt-get install -y ufw
sudo sed -i 's/^IPV6=.*/IPV6=yes/' /etc/default/ufw
sudo ufw default deny incoming
sudo ufw default allow outgoing
sudo ufw allow 22/tcp
sudo ufw --force enable
sudo ufw status verbose

This fences what the host itself listens on. It does not fence port 443 once Docker publishes it: Docker diverts published-port traffic in its own nat-table rules, ahead of the INPUT chain that ufw filters. The next two sections handle that.

Single-server install from the tarball

1. Take the current bundle file name from Kasm's single-server install page. The commands below use the 1.19.0 bundle listed there at the time of writing.
2. Download the bundle and its .sha256sum file to /tmp, run sha256sum --check, and continue only if it prints OK. The chained commands stop on their own if it does not. If you also compare the result with the checksum table on the docs page and the two disagree, ask Kasm before installing. Then extract and run the script with sudo bash: a file you can read first, never piped into a shell.
3. Answer the licence (EULA) prompt, and the swap prompt if the host has no swap. If the install fails, the log stays in the working directory as kasm_install_ plus a timestamp; on success it is removed.
4. Log in at https:// plus the host's IP or name; the web app answers on 443. The certificate is self-signed until you replace it.

cd /tmp
curl -fO https://kasm-static-content.s3.amazonaws.com/kasm_release_1.19.0.tar.gz
curl -fO https://kasm-static-content.s3.amazonaws.com/kasm_release_1.19.0.tar.gz.sha256sum
sha256sum --check kasm_release_1.19.0.tar.gz.sha256sum \
  && tar -xf kasm_release_1.19.0.tar.gz \
  && sudo bash kasm_release/install.sh

At the end the installer prints randomly generated passwords for admin@kasm.local and user@kasm.local. Copy both into a password manager straight away, then change them in the admin UI. The script also accepts --admin-password and --user-password; let it generate them instead, because a password passed as an argument lands in shell history and is visible in ps while the script runs. -L 8443 moves the web app off 443 if that port is taken. From 1.19.0 the default install uses rolling Workspace images that receive ongoing security fixes; -f (--use-static-images) pins static images instead.

Fencing port 443 while you configure

Docker's documentation names the DOCKER-USER chain as the place for your own rules on published ports. Until the passwords are changed and the settings done, drop new connections from everyone but your own address, while keeping replies to the session containers' outbound traffic:

# eno1: your public interface, from: ip route show default
# 203.0.113.10: the address you connect from
sudo iptables -I DOCKER-USER -i eno1 ! -s 203.0.113.10 -j DROP
sudo iptables -I DOCKER-USER -m conntrack --ctstate RELATED,ESTABLISHED -j ACCEPT
sudo iptables -L DOCKER-USER -n --line-numbers

These are IPv4 rules and are not saved across a reboot. Whether Docker also publishes the port on IPv6, and how, depends on the Docker version and its daemon settings; if the server has an IPv6 address, test 443 over IPv6 from another network before relying on the fence. Open to the world later with sudo iptables -D DOCKER-USER -i eno1 ! -s 203.0.113.10 -j DROP.

Certificates, upgrades and backups

• Certificate: stop Kasm with sudo systemctl stop kasm, copy a PEM certificate and key over kasm_nginx.crt and kasm_nginx.key in /opt/kasm/current/certs/, then sudo systemctl start kasm. A reverse proxy in front is the documented alternative.
• Upgrade: with no sessions running, download and check the new bundle the same way, then sudo bash kasm_release/upgrade.sh --proxy-port 443, with 443 replaced by your port if -L chose another. Kasm recommends a snapshot or other backup of the server first.
• Database dump: sudo docker exec kasm_db pg_dump -U kasmapp -F t kasm > /tmp/backup.tar is Kasm's documented backup. For a nightly copy, create /var/backups/kasm with sudo install -d -m 700 /var/backups/kasm and add to root's crontab: 0 3 * * * docker exec kasm_db pg_dump -U kasmapp -F t kasm > /var/backups/kasm/kasm-db-$(date +\%F).tar 2>> /var/backups/kasm/dump.log
• Off the machine: copy those dumps to storage elsewhere yourself; a dump on the same disks dies with them. Restoring needs the same Kasm version as the one that wrote the dump.

Licensing: what Community Edition covers

Kasm's licensing page describes Community Edition as "Free for testing, nonprofit, and eligible non-commercial use", with "Up to 5 concurrent sessions and community support through the public issue tracker". Anything outside that wording is not covered by the free edition. Commercial licensing, in the page's words, is "available through Named User and Concurrent Session models"; pricing requests go to kasm.com/quote.

A purchased Activation Key can go in at install: save it to a file and pass -a activation_key.txt. That needs the server to reach Kasm's activation service, so it does not work for an offline install.

When one server is the wrong design

Single-server means the database, web app and every session share one failure domain: a reboot ends all desktops at once. Kasm documents a multi-server layout with separate database, web app and agent roles; that is the design once you outgrow one machine or cannot lose every desktop with one host. If what you need is plain remote access to Windows machines rather than containerised desktops, a Windows RDP server may be the simpler build, and for browser access to existing machines without containerised desktops, an Apache Guacamole gateway is the lighter option. Kasm can also broker RDP, VNC and SSH sessions to existing systems.