Wie Workspace-Isolation in LaraDep mein Multi-Client-Management verändert hat

Der Zustand vor der Workspace-Isolation

Bevor ich das Workspace-Modell in LaraDep einbaute, sah ein Multi-Client-Setup so aus: ein Git-Repository, ein Ansible-Vault für alle Secrets, nach Kunden benannte Ordner und eine ungeschriebene Team-Vereinbarung „fass nicht an, was nicht deins ist". Funktioniert das? Technisch ja. Sicher? Absolut nicht.

Umgebungen zu verwechseln ist in einem solchen Setup eine Frage der Unaufmerksamkeit, nicht der bösen Absicht. Man wechselt in den falschen Ordner im Terminal, startet einen Run gegen Produktion statt Staging, und das Ergebnis sagt einem, was passiert ist. Mit Glück ist es nur verlorene Zeit. Ohne Glück ist es ein Vorfall.

Was Workspace-Isolation in der Praxis bedeutet

In LaraDep ist ein Workspace ein Datenkontext, der physisch trennt:

• Server und ihre Gruppen von anderen Workspaces.
• Ansible-Variablen und den Secret-Store von anderen Workspaces.
• Run-Historie und Audit-Einträge nach Workspace-Kontext.
• Berechtigungen — wer was in einem bestimmten Workspace tun kann.

Den Workspace zu wechseln bedeutet nicht nur einen anderen Browser-Tab. Es bedeutet, dass man versehentlich nichts im falschen Kontext anzeigen oder ausführen kann, weil das System es nicht erlaubt. Das ist kein „wir hoffen, dass Sie es bemerken". Das ist eine strukturelle Einschränkung.

Ein konkreter Fall: Agenturbetrieb

Für Agenturen ist das Workspace-Modell wahrscheinlich der größte Mehrwert von LaraDep. Jeder Kunde bekommt einen eigenen Workspace. Das Onboarding eines neuen Projekts bedeutet, einen Workspace zu erstellen, Server hinzuzufügen, Variablen zu konfigurieren und Berechtigungen zuzuweisen. Das ist ein expliziter Akt — kein „gib Jan Zugriff auf den Ordner".

Run-Audits funktionieren nach Workspace-Kontext. Wenn ein Kunde fragt „was haben Sie letzten Monat bei uns gemacht", ist die Antwort ein paar Klicks entfernt, keine Stunde des Wühlens in der Git-Historie.

Wo das Workspace-Modell nicht ausreicht

Workspace-Isolation ist eine Governance-Schicht, kein Ersatz für gute Template Composition oder Runbook-Disziplin. Wenn das Playbook das Falsche tut, fängt der Workspace das nicht ab. Jede Schutzschicht löst ein anderes Problem, und das Workspace-Modell löst genau und nur: Kontext- und Zugriffstrennung.

Für ein vollständiges Betriebsmodell braucht man Workspace-Isolation zusammen mit Preflight, Templates und Audit-Historie. Jede Schicht hilft allein weniger als alle zusammen.

Nächster Schritt: Vollständiger Kontext steht in der Dokumentation und im Vergleich.