Ich teste momentan HomeDockOS. Eigentlich läuft mein Heimserver wunderbar. Aber dann entdeckte ich Kasm Workspaces – und plötzlich wollte ich einen kompletten Linux-Desktop im Browser. Natürlich wollte ich das.
Warum?
Weil ich offenbar nicht damit leben kann, dass mein Heimserver einfach nur funktioniert.
Mein kleiner HP EliteDesk, liebevoll Kylife-Server genannt, macht seinen Job nämlich wirklich hervorragend. Kubuntu 26.10 läuft, meine Docker-Container verrichten brav ihren Dienst, Homarr begrüßt mich mit einer hübschen Übersicht, und Cockpit kümmert sich um die Systemverwaltung.
Eigentlich könnte ich zufrieden sein.
Bin ich auch.
Zumindest so lange, bis ich wieder irgendein interessantes Projekt im Internet entdecke.
Weil ich momentan HomeDockOS teste, kam mir der völlig harmlose Gedanke:
„Schauen wir doch mal, was es sonst noch für ähnliche Projekte gibt.“
Ein Satz, der bei mir ungefähr dieselbe Bedeutung hat wie „Ich trinke heute nur ein Bier“ bei jemandem, der anschließend um vier Uhr morgens auf einer Parkbank seine Lebensentscheidungen hinterfragt.
Ich trinke übrigens keinen Alkohol.
Meine schlechten Entscheidungen treffe ich vollkommen nüchtern.
Jedenfalls landete ich irgendwann bei Kasm Workspaces. Und dann las ich etwas von vollständigen Linux-Desktops, die direkt im Browser laufen.
Moment.
Ein ganzer Desktop?
Im Browser?
Von jedem Gerät aus?
Mein innerer Linux-Bastler war sofort hellwach. Mein Verstand versuchte noch, die Situation sachlich zu bewerten.
Zu spät.
Das Kaninchenloch hatte bereits die Eingangstür geöffnet.
Was zum Teufel ist Kasm Workspaces?
Stellt euch vor, ihr öffnet auf eurem Rechner einen Browser, ruft eine Webseite auf und bekommt plötzlich einen vollständigen Linux-Desktop angezeigt.
Mit Fenstern. Mit Anwendungen. Mit Dateimanager. Mit allem, was man von einem normalen Desktop erwartet.
Nur läuft dieser Desktop überhaupt nicht auf eurem lokalen Rechner.
Er läuft auf einem Server – und der Browser übernimmt Darstellung und Bedienung.
Genau das ist eine der zentralen Ideen hinter Kasm Workspaces. Die Plattform stellt komplette Arbeitsumgebungen oder einzelne Anwendungen über einen Webbrowser bereit.
Das kann ein Linux-Desktop sein. Oder Firefox. Oder eine Entwicklungsumgebung. Oder ein isolierter Browser, in dem man unbekannte Webseiten besucht, ohne sie unmittelbar auf dem eigenen Alltagsrechner auszuführen.
Kasm kombiniert dafür Containerisierung, Streaming-Technologie, Benutzerverwaltung und Sitzungssteuerung.
Klingt wie eine Mischung aus Docker, Remote Desktop und App-Launcher?
Ist es im Grunde auch.
Allerdings sollte man eines nicht verwechseln:
Kasm möchte nicht bloß eure vorhandenen Serverdienste hübsch sortieren. Es möchte euch ganze Arbeitsumgebungen bereitstellen.
HomeDockOS vereinfacht vor allem das Bereitstellen und Verwalten selbst gehosteter Anwendungen. Homarr ist das Dashboard, mit dem ich meine vorhandenen Dienste öffne und im Blick behalte. Kasm liefert mir dagegen bei Bedarf einen Arbeitsplatz.
Drei unterschiedliche Konzepte. Drei unterschiedliche Einsatzzwecke.
Und natürlich musste ich sie trotzdem erst einmal gedanklich in denselben Topf werfen.
Wäre ja langweilig, wenn ich die Unterschiede sofort akzeptieren würde.
Die Entstehung: Eigentlich ging es gar nicht um hübsche Linux-Desktops
Das Interessante an Kasm ist, dass die ursprüngliche Idee gar nichts damit zu tun hatte, einem Linux-Nerd seinen Desktop auf jedem Gerät hinterherzutragen.
Die Geschichte beginnt im Bereich der IT-Sicherheit.
Nach der Entstehungsgeschichte des Unternehmens beschäftigte sich der spätere Mitgründer Justin Travis schon während seines Studiums mit sogenannten Drive-by-Angriffen: Ein Mensch besucht eine Webseite, und durch eine ausgenutzte Schwachstelle wird sein Rechner kompromittiert.
Besonders unangenehm, wenn dieser Rechner in einem Unternehmensnetzwerk steht, in dem mehr zu holen ist als die private Sammlung fragwürdiger Katzenbilder.
Travis stellte sich deshalb eine durchaus vernünftige Frage:
„Warum müssen wir potenziell gefährliche Webseiten überhaupt direkt auf unserem eigenen Rechner öffnen?“
Die Idee: Der Browser läuft in einer entfernten, isolierten Umgebung. Der Benutzer sieht und bedient nur dessen Oberfläche. Wenn die Umgebung kompromittiert wird, kann man sie verwerfen und neu erstellen.
Eine einfache Idee. Jedenfalls auf Papier.
Jahre später arbeitete Travis in der offensiven IT-Sicherheitsforschung. Dort begegnete ihm dasselbe Problem erneut. Die verfügbaren Remote-Systeme waren häufig umständlich zu pflegen und selbst wieder ein Risiko, wenn sie dauerhaft weiterliefen.
Gemeinsam mit seinem früheren Kollegen Matt McClaskey nahm er die Idee wieder auf. Der Aufstieg von Docker kam ihnen entgegen: Statt schwergewichtiger, dauerhaft laufender virtueller Maschinen ließen sich kurzlebige Arbeitsumgebungen auf Abruf erstellen.
Ein früher Prototyp stellte einen Browser bereit, der innerhalb eines Containers lief und aus der Ferne bedient werden konnte.
Und dann kam ein erster Kunde, der gar nicht nur sicher surfen wollte. Er benötigte eine kontrollierte Umgebung, auf die mehrere externe Organisationen zugreifen konnten, ohne alle Beteiligten erst mit lokalen Clients, VPN-Konfigurationen und sonstigen IT-Freuden zu beglücken.
Kasm entwickelte sich deshalb über die reine Browser-Isolation hinaus. Als Remote-Arbeit ab 2020 enorm an Bedeutung gewann, passte das Konzept plötzlich auf noch viel mehr Anwendungsfälle.
Aus dem isolierten Browser wurde nach und nach eine Plattform für komplette Desktop-Umgebungen, Anwendungen und den kontrollierten Zugriff auf entfernte Systeme.
Und ich?
Ich stolpere über das Ganze, weil ich eigentlich nur eine Alternative zu HomeDockOS gesucht habe.
Manchmal frage ich mich wirklich, ob meine Internetrecherchen überhaupt noch einen roten Faden besitzen.
Wie funktioniert das technisch?
Jetzt wird es interessant. Und keine Sorge: Wir müssen dafür keinen dreistündigen Vortrag über Container-Orchestrierung veranstalten.
Den überlasse ich Menschen, die freiwillig Kubernetes-Cluster zum Frühstück konfigurieren.
Das Grundprinzip ist relativ einfach:
- Ein Benutzer meldet sich an der Kasm-Weboberfläche an.
- Er wählt eine Anwendung oder einen Desktop aus.
- Kasm startet beziehungsweise verbindet die passende Sitzung.
- Die Benutzeroberfläche erscheint direkt im Browser.
Bei den klassischen Linux-Workspaces kommen Docker-Container zum Einsatz. Diese enthalten die benötigten Programme und die grafische Umgebung. Über KasmVNC wird die Oberfläche zum Browser übertragen; Tastatur- und Mauseingaben gehen zurück zur Sitzung.
Die Anwendungen arbeiten also auf dem Server, nicht auf eurem lokalen Notebook oder Smartphone.
Kasm kann aber auch bereits existierende Systeme einbinden, etwa über RDP, VNC oder SSH. Nicht jeder Workspace muss deshalb zwingend ein frisch gestarteter Docker-Container sein.
Das ist einer der wichtigen Unterschiede zwischen einem temporären Testdesktop und einem dauerhaft betriebenen Arbeitsplatz.
Und bleiben meine Dateien erhalten?
Hier versteckt sich ein kleines, aber wichtiges Detail.
Viele containerbasierte Sitzungen sind zunächst temporär. Wird die Sitzung endgültig gelöscht, verschwinden ohne entsprechende Konfiguration auch die darin erzeugten Daten.
Bei einem abgeschotteten Wegwerf-Browser ist das wunderbar.
Bei einem Desktop, auf dem man gestern noch drei Stunden gearbeitet hat?
Weniger wunderbar.
Deshalb gibt es unter anderem persistente Benutzerprofile sowie Funktionen zum Pausieren und Fortsetzen von Sitzungen. Wer einen wirklich dauerhaft laufenden Desktop möchte, kann auch eine eigene VM über Kasm erreichbar machen.
Und genau da wurde ich hellhörig.
Ein Desktop. Dieselben Dateien. Dieselben Einstellungen. Egal, ob ich gerade am Mainrig, ThinkPad oder Foldable sitze.
Ein persönlicher Cloud-PC, nur möglichst auf meiner eigenen Hardware.
Ohne dass ein Anbieter morgen aufwacht und beschließt, mir für die Farbe meiner Taskleiste ein Premium-Ultra-Super-Abo verkaufen zu müssen.
Für wen ist Kasm eigentlich sinnvoll?
Und hier kommen wir zum entscheidenden Punkt: Kasm ist weit mehr als ein Spielzeug für Menschen, die zu viele Linux-ISOs besitzen.
Unternehmen und externe Mitarbeiter
Ein Unternehmen kann bestimmten Mitarbeitern oder externen Dienstleistern eine kontrollierte Arbeitsumgebung bereitstellen, die direkt über den Browser erreichbar ist.
Das ist spannend, wenn nicht jeder einen eigens konfigurierten Firmenrechner bekommen soll oder darf. Anwendungen und Zugriffsrechte lassen sich zentral verwalten, statt jedes Endgerät einzeln zum kleinen IT-Projekt zu machen.
Schulen, Universitäten und Schulungsanbieter
Man könnte beispielsweise allen Teilnehmern dieselbe vorbereitete Linux-Umgebung mit passenden Programmen geben.
Keine unterschiedlichen Softwarestände, keine vergessenen Installationen und hoffentlich weniger von diesen wundervollen Unterrichtsmomenten, in denen zwanzig Leute gleichzeitig erklären, dass bei ihnen „irgendwas nicht funktioniert“.
Für Übungen lassen sich Umgebungen vorbereiten, zurücksetzen und erneut verteilen.
IT-Sicherheit und Forschung
Hier liegen die Wurzeln der Plattform. Isolierte Browser können beim Umgang mit unbekannten oder riskanten Webseiten helfen. Auch für OSINT-Recherchen oder zeitlich begrenzte Analyseumgebungen kann das interessant sein.
Allerdings ist ein Container kein magischer Schutzschild. Docker-Container teilen sich den Kernel des Hosts; wie gut eine Lösung schützt, hängt von der gesamten Konfiguration ab.
„Läuft im Container“ bedeutet eben nicht „Kann unmöglich etwas kaputtmachen“.
Wäre das so, hätte ich in meinem Homelab vermutlich deutlich weniger Sorgen.
Privatpersonen und Homelab-Betreiber
Natürlich kann man damit auch einen persönlichen Desktop anbieten, verschiedene Linux-Umgebungen testen oder Anwendungen benutzen, ohne sie auf jedem Client installieren zu müssen.
Für solche nichtkommerziellen Experimente gibt es eine kostenlose Community Edition, die unter anderem auf fünf gleichzeitige Sitzungen begrenzt ist. Kasm Workspaces ist dabei nicht pauschal vollständig Open Source; einzelne Komponenten wie KasmVNC sind separat quelloffen.
Spannende Möglichkeiten also.
Vor allem für Leute, die regelmäßig Remote-Arbeitsplätze brauchen.
Oder für Leute wie mich, die sich erst einmal einreden, dass sie so etwas regelmäßig brauchen könnten.
Natürlich musste ich es ausprobieren
Ein vollständiger Desktop im Browser. Docker im Hintergrund. Linux. Virtuelle Arbeitsumgebungen.
Was könnte einen Menschen, der ohnehin ständig an seinem Homelab herumbastelt, mehr begeistern?
Also bekam mein Kylife-Server eine neue virtuelle Maschine.
Debian 13.
Vier virtuelle CPU-Kerne. Acht Gigabyte Arbeitsspeicher. Rund 100 Gigabyte virtueller Festplattenspeicher.
Alles unter QEMU/KVM.
Mein eigentliches Hostsystem durfte dabei unangetastet bleiben. Ich habe mittlerweile gelernt, dass man spontane Experimente vielleicht nicht unbedingt gleichzeitig zum Problem von Nextcloud, Jellyfin und der restlichen Serverbelegschaft machen sollte.
Also eingerichtet, ein wenig mit Kasm gespielt und die Möglichkeiten angeschaut.
Und tatsächlich: Das Konzept finde ich weiterhin verdammt interessant.
Nur schlich sich irgendwann eine ausgesprochen lästige Frage in meinen Kopf.
„Okay, sieht cool aus. Aber was genau bringt mir das jetzt eigentlich?“
Eine unangenehme Frage.
Besonders wenn man gerade Zeit damit verbracht hat, etwas Neues einzurichten.
Doch je länger ich darüber nachdachte, desto deutlicher wurde mir etwas.
Der Moment, in dem mein Kaninchenloch eine Notbremse bekam
Ich habe bereits mehrere Rechner.
Mein Mainrig wartet auf Spiele, Videoschnitt und lokale KI. Mein ThinkPad ist wieder ein normaler Laptop. Ein älterer HP-Laptop darf sich mit Hyprland und Noctalia austoben. Und mein kleiner Kylife erledigt inzwischen fast alles andere.
Dort laufen meine Container.
Dort liegen meine Daten.
Dort verwalte ich meine Dienste.
Wenn ich einen lokalen Desktop brauche, starte ich KDE Plasma. Wenn nicht, wird die grafische Sitzung beendet und der kleine Rechner konzentriert sich auf seine Serveraufgaben.
Eigentlich angenehm.
Klar wäre ein zentraler, browserbasierter Desktop schön.
Aber würde ich ihn wirklich regelmäßig benutzen?
Wahrscheinlich nicht.
Ich müsste Kasm pflegen, Workspaces konfigurieren, mich um Profile und Sitzungen kümmern und zusätzliche Ressourcen reservieren.
Und wofür?
Damit ich einen weiteren Desktop besitze, obwohl ich bereits genügend davon habe?
Herzlichen Glückwunsch, Kiru. Du hast einen Computer eingerichtet, damit du einen anderen Computer im Browser benutzen kannst.
Klingt beeindruckend.
Bis man sich fragt, was man darauf eigentlich machen möchte.
Und dann kam sie, die völlig unromantische Erkenntnis:
Ich brauche Kasm momentan schlicht nicht.
Nicht, weil es schlecht wäre.
Im Gegenteil. Für Menschen mit echtem Bedarf an entfernten Arbeitsumgebungen kann die Plattform richtig sinnvoll sein.
Aber eine interessante Technologie ist nicht automatisch eine nützliche Ergänzung für meine eigene Infrastruktur.
Eine Lektion, die ich offenbar alle paar Wochen neu lernen muss.
Homarr, Docker und die große Erkenntnis des faulen Bastlers
Was brauche ich tatsächlich?
Meine Dienste bequem erreichen? Homarr.
Container installieren und verwalten? Docker Compose und bei Bedarf Portainer.
Den Host administrieren? Cockpit.
Ein anderes Linux ausprobieren? Virtuelle Maschine starten.
Fertig.
HomeDockOS teste ich zwar weiterhin, aber auch dort merke ich inzwischen: Vieles, was es anbietet, erledigen meine vorhandenen Werkzeuge bereits.
Wichtig ist dabei die Unterscheidung: Homarr kann Kasm nicht ersetzen und Kasm ist keine Alternative zu Homarr. Ich habe bloß keinen konkreten Bedarf für die zusätzliche Art von Arbeitsumgebung, die Kasm mir anbieten würde.
Nur weil ich zwei Technologien kombinieren kann, muss ich es noch lange nicht tun.
Ich könnte schließlich auch einen Kubernetes-Cluster aufbauen, um drei Container zu betreiben.
Oder einen ganzen Virtualisierungscluster, weil ich gelegentlich eine Debian-VM brauche.
Oder mir einen zweiten Server kaufen, um den ersten besser überwachen zu können.
Technisch alles machbar.
Praktisch?
Nun ja.
Mein innerer Minimalist würde irgendwann anfangen, mit Gegenständen zu werfen.
Fazit: Ich habe das Kaninchenloch tatsächlich lebend verlassen
Und damit kommen wir zu einem für mich erstaunlich ungewöhnlichen Ergebnis.
Ich habe eine interessante Software entdeckt.
Mich über sie informiert.
Ihre Entstehungsgeschichte recherchiert.
Eine virtuelle Maschine eingerichtet.
Die Plattform ausprobiert.
Und anschließend beschlossen:
„Nö. Brauche ich momentan nicht.“
Ich weiß.
Erschreckend.
Vor einiger Zeit hätte ich vermutlich schon angefangen, meine gesamte Infrastruktur um Kasm herum neu zu organisieren. Ein eigenes Netzwerksegment hier, persistente Workspaces dort, vielleicht noch einen Reverse Proxy und eine zentrale Benutzerverwaltung für sämtliche Dienste.
Drei Tage später hätte ich eine Architektur, die für eine mittelgroße Forschungseinrichtung gereicht hätte.
Nur leider würde ich weiterhin hauptsächlich Jellyfin, Nextcloud und ein paar andere Docker-Anwendungen benutzen.
Diesmal blieb es beim Experiment.
Die Debian-VM darf vorerst bleiben. Vielleicht beschäftige ich mich später noch einmal intensiver mit Kasm. Vielleicht ergibt sich irgendwann ein wirklich sinnvoller Anwendungsfall.
Momentan jedenfalls nicht.
Docker läuft. Homarr funktioniert. Kylife erledigt seine Aufgaben. Warum sollte ich mir zusätzliche Arbeit machen?
Das bedeutet nicht, dass ich weniger neugierig geworden bin. Ich probiere weiterhin gerne Dinge aus.
Nur muss inzwischen nicht jedes interessante Projekt einen dauerhaften Platz auf meinem Server bekommen.
Man könnte das persönliche Weiterentwicklung nennen.
Oder Alterserscheinungen.
Ich bin da noch unentschlossen.
Jedenfalls ist Kasm Workspaces eine spannende Plattform – besonders für Unternehmen, Bildungseinrichtungen, Sicherheitsforscher und alle, die wirklich einen entfernten Arbeitsplatz benötigen.
Für mich wäre es derzeit vor allem eines:
Eine ziemlich aufwendige Lösung für ein Problem, das ich überhaupt nicht habe.
Und vielleicht ist genau das die wichtigste Erkenntnis:
Nicht jede gute Software muss man selbst betreiben. Manchmal reicht es, sie interessant zu finden.
So.
Kasm bleibt vorerst geparkt.
Der Server bleibt, wie er ist.
Ich werde jetzt etwas vollkommen Vernünftiges tun.
Mich zurücklehnen.
Entspannen.
Keine weiteren Projekte suchen.
Keine zusätzlichen Container installieren.
Keine virtuellen Maschinen starten.
…
Moment mal.
Was ist eigentlich dieses Apache Guacamole?
Ach, verdammt. 🐇🤣
Quellen und weiterführende Links
- Kasm Technologies – Die Entstehungsgeschichte
- Kasm Workspaces – Offizielle Dokumentation
- Kasm – Persistente Benutzerprofile
- Kasm – Lizenzmodelle und Community Edition
- HomeDockOS – Projektüberblick
- Homarr – Dokumentation
Stand: Oktober 2026. Dieser Beitrag beschreibt meinen ersten Test in einer Debian-13-VM – keinen vollständigen Langzeittest sämtlicher Kasm-Funktionen.