Multi-Tenant-Architektur für die skalierbare Brand Asset Delivery von SchleeGleixner

Über das Projekt

SchleeGleixner ist eine Designagentur, die sich auf Brand Design, Logo-Erstellung, Farbpaletten und Corporate Identities spezialisiert hat. SchleeGleixner brauchte eine skalierbare Lösung, um Designarbeiten für mehrere Kunden gleichzeitig zu verwalten und auszuliefern. Die Herausforderung: separate, gebrandete Umgebungen für jeden Kunden zu pflegen und dabei nur eine einzige Statamic-Installation zu nutzen.

Als Lösung haben wir eine subdomain-basierte Multi-Tenancy-Architektur auf Statamic CMS implementiert. So kann SchleeGleixner eine zentrale Statamic-Installation betreiben, in der jeder Kunde als isolierter Tenant mit eigener gebrandeter Subdomain existiert (z.B. kundenname.schlegleixner.com).

Das Ergebnis war ein produktionsreifes, getestetes Multi-Tenancy-Fundament, auf dem der Kunde eigenständig weiterarbeiten konnte.

Wichtig: Dieses Projekt wurde im Juni 2024 ausgeliefert. Zu diesem Zeitpunkt basierte es auf Statamic 4.5 mit Eloquent Driver 3.3. Inzwischen ist Statamic 5 erschienen. Die Multi-Tenancy-Architektur bleibt kompatibel, allerdings können Anpassungen am Driver für eine Migration erforderlich sein.

PS: In diesem Projekt wurde keine Frontend-Anpassung vorgenommen, da der Kunde dies selbst übernehmen wollte.

B2B Kunde:

SchleeGleixner

Entwicklung & Deployment:

2 Monate

Technologien:

Laravel

Statamic

Multitenancy

Das Problem des Kunden

SchleeGleixner brauchte eine Statamic-basierte Architektur für ihre internen Workflows, bekam sie aber nicht zum Laufen.

Wie bereits beschrieben, brauchte unser Kunde eine zentrale Statamic-Installation, die mehrere Kunden gleichzeitig bedienen kann – jeden in seiner eigenen isolierten Umgebung. SchleeGleixner hatte sich aus guten Gründen bereits für Statamic entschieden: die moderne Architektur, die bewährten Multi-Tenancy-Fähigkeiten und die datenbankgestützte Flexibilität.

Ein Plattformwechsel kam daher nicht in Frage – der bestehende Ansatz musste zum Laufen gebracht werden. Eine subdomain-basierte Multi-Tenancy wurde als passende Lösung für den internen Workflow identifiziert.

Zuvor gab es bei SchleeGleixner eine Umsetzungsblockade bei kritischen Teilen. Unsere Beobachtungen zeigten eine Wissenslücke zwischen Theorie und Implementierung, bei der wichtige Teile nicht zusammenpassten:

Die Tenant-Isolation war nicht vollständig – Daten liefen zwischen Tenants durch
Die Authentifizierung war nicht richtig auf den Tenant beschränkt
Assets wurden nicht korrekt isoliert
Die Debugging-Spur war kalt geworden

Eine gut orchestrierte Multi-Tenancy-Architektur erfordert tiefgreifende Vertrautheit mit Laravels Request Lifecycle, Middleware Chains und datenbankbasiertem Scoping. Noch wichtiger ist die Erfahrung, diese Systeme zu debuggen, wenn sich das erwartete Verhalten nicht einstellt.

SchleeGleixner brauchte fundierte Erfahrung in der Problemlösung für solche Herausforderungen. Unser Kunde brauchte einen Experten, der erkennen konnte, wo die Tenant-Awareness zusammenbrach, der durch den Statamic Eloquent Driver debuggen konnte, um die Lücken zu finden, und der die fehlenden Teile implementieren konnte, ohne den gesamten Ansatz neu zu schreiben. SchleeGleixner brauchte keine neue Plattform, sondern Infrastruktur-Expertise, um das bereits gewählte Multi-Tenancy-Fundament zum Leben zu erwecken.

WAS IST MULTI-TENANCY?

Multi-Tenancy ist eine Architektur, die entweder mit einer einzelnen Datenbank oder mit mehreren Datenbanken genutzt werden kann. Es ist eine Art von Architektur, die spezifische Anwendungsfälle wie den hier vorgestellten ermöglicht. Sie ist vielseitig und bietet Flexibilität. In bestimmten Situationen können mehrere Datenbanken erforderlich sein.

Es gibt verschiedene Ansätze für die Implementierung. Man könnte bei Bedarf mehr Komplexität hinzufügen, um hohe Last zu bewältigen. Es ist ein erweiterbarer Ansatz, und für den gegebenen Anwendungsfall funktionierte er hervorragend.

In diesem speziellen Fall nutzte SchleeGleixner Statamic CMS nicht als traditionelles Website-CMS, sondern als interne Operations-Plattform – ein Design Delivery System. Statamic CMS bot einen festen Satz an Seiten und einen Form Builder, über den die Designer von SchleeGleixner strukturierte Workflows erstellen konnten, um Assets (Logos, Markenmaterialien, Farbschemata) hochzuladen und als interaktive, responsive Deliverables an Kunden zu präsentieren. Jeder Kunde erhält ein gebrandetes Moodboard-Erlebnis in seiner isolierten Tenant-Umgebung.

Für unseren Kunden war Multi-Tenancy eine Anforderung, weil sie vollständige Design-Anpassung und Benutzerkonfiguration für jeden Kunden ermöglichte, ohne den Aufwand, mehrere Statamic-Installationen zu verwalten – bei gleichzeitig strikter, sicherer Datenisolation.

Jeder Tenant behielt:

1. Separate Benutzerverwaltung und Authentifizierung;

2. Isolierte Asset-Speicherung;

3. Individuelles Branding im Control Panel;

4. Tenant-spezifische Konfigurationen.

Git-basierter kollaborativer Workflow via GitHub

Wir haben ein privates Repository innerhalb unserer Laramate-Organisation eingerichtet und unserem Kunden – SchleeGleixner – kollaborativen Zugriff gewährt. Das ermöglichte eine versionskontrollierte, asynchrone Entwicklung: Das Entwicklerteam konnte die Codebasis herunterladen, die Implementierung schrittweise durch kleine Commits nachvollziehen, Änderungen verstehen und das Multi-Tenancy-Fundament eigenständig erweitern.

Für dieses Projekt haben wir ausschließlich eine Infrastruktur-Übergabe geliefert, kein Code-Deployment. Dazu demonstrierten wir die funktionale Tenant-Isolation und -Identifikation (Tenant A von Tenant B). Jeder Tenant ist eigenständig und kann nicht auf die Daten, Assets oder Benutzer eines anderen Tenants zugreifen.

Wie wurde Multi-Tenancy bei SchleeGleixner umgesetzt?

1. Architektur-Entscheidung

Wir haben eine leere Statamic-Installation aufgesetzt, die für subdomain-getriebene Multi-Tenancy mit einer einzelnen zentralen Datenbank konfiguriert war. Die Subdomain dient als Tenant-Identifier. Wenn zum Beispiel eine Anfrage bei clientA.schlegleixner.com eingeht, ermittelt das System automatisch, auf welchen Tenant zugegriffen wird, und beschränkt alle nachfolgenden Operationen auf die Daten dieses Tenants.

2. Subdomain-Struktur

Jeder Kunde erhält seine eigene gebrandete Subdomain unter der Domain von SchleeGleixner. Zum Beispiel funktionieren clientA.schlegleixner.com und clientB.schlegleixner.com als komplett getrennte Umgebungen. Wenn Laramate ein Kunde würde, würde der Zugriff auf laramate.schlegleixner.com eine vollständig gebrandete Willkommensseite mit der Corporate Identity von Laramate zeigen – so entsteht ein White-Label-Erlebnis, bei dem jeder Kunde die Plattform als maßgeschneidert für sich wahrnimmt.

3. Single-Database-Ansatz

In dieser speziellen Umgebung haben wir uns für eine einzelne Datenbank statt einer Multi-Database-Architektur entschieden. Der Aufwand, mehrere Datenbanken zu verwalten, erhöht die Komplexität, ohne die Sicherheit zu verbessern. Man könnte trotzdem Zugriff auf den Database Driver erlangen und auf alle Datenbanken zugreifen. Mehrere Datenbanken sind keine zusätzliche Sicherheitsebene. Physische Datenbanktrennung wird erst bei Enterprise-Scale mit strengen Compliance-Anforderungen notwendig. Für diese Projektgröße war dieser Aufwand nicht gerechtfertigt.

4. Datenbankstruktur

Die Datentrennung erfolgt durch Tenant-Scoping auf Anwendungsebene. Mit Stencils Tenancy-Package haben wir eine tenant_id Spalte in allen relevanten Tabellen implementiert. Jede Zeile trägt ihren Tenant-Identifier: Daten von Tenant A haben tenant_id = 1, die von Tenant B haben tenant_id = 2, und so weiter. Eine dedizierte tenants Tabelle ordnet Subdomains den Tenant-IDs zu und speichert tenant-spezifische Konfiguration (Namen, Branding-Einstellungen, etc.). Der Rest ist Programmierung: sicherstellen, dass jede Query, jede Dateioperationen, jeder Asset-Abruf die Tenant-Grenzen respektiert.

5. Sicherheit durch saubere Programmierung

Die Datensicherheit zwischen Tenants wird durch rigoroses Scoping erreicht – jede Datenbankabfrage gefiltert nach tenant_id, jeder Dateipfad mit Tenant-Namespace versehen, jede Authentifizierungsprüfung auf den aktuellen Tenant beschränkt. Wir haben dies durch umfassende Tests validiert, um sicherzustellen, dass keine Daten zwischen Tenants durchsickern.

6. Entwicklungsumgebung

Wir haben DDEV verwendet, um die Multi-Subdomain-Struktur der Produktionsumgebung lokal zu replizieren. Die Entwicklungsumgebung lief mit vollem Subdomain-Support: clientA.ddev.site, clientB.ddev.site, clientC.ddev.site. So konnten wir die Tenant-Isolation gründlich testen, bevor das Deployment erfolgte. Diese Parität zwischen lokaler und Produktionsumgebung war entscheidend für das Debugging von Grenzfällen beim Tenant-Wechsel und Data-Scoping.

7. Testing

Wir haben eine PHPUnit Test-Suite bereitgestellt, die Tenant-Trennung, Authentication-Scoping und Asset-Isolation abdeckt. Diese Tests validieren, dass Tenant A unter keinen Umständen auf die Daten, Benutzer oder Dateien von Tenant B zugreifen kann. Die Test-Suite dient sowohl als Validierung als auch als Dokumentation, beweist die Robustheit der Multi-Tenancy-Implementierung und bietet ein Sicherheitsnetz für die zukünftige Entwicklung.

WIE FUNKTIONIERT ES?

Wir haben eine leere Statamic-Installation ohne Starter-Kits und ohne vorgefertigte Themes ausgeliefert. Statamic bietet zwar Starter-Kits zur Beschleunigung der Entwicklung (Design-Systeme, Page Builder, Boilerplate-Content), aber wir haben bewusst ohne diese gebaut.

Das Fundament nutzt Statemics Eloquent Driver, um alle Inhalte und Konfigurationen in der Datenbank zu persistieren und so echte Multi-Tenancy auf der Datenebene zu ermöglichen. Dieser Ansatz gab SchleeGleixner die volle Kontrolle, ihre Design-Delivery-Workflows zu bauen, ohne unnötige Strukturen zu erben.

Tenant-Auflösung bei SchleeGleixner: Die Tenant-Identifikation erfolgt automatisch über die Subdomain. Wenn eine Anfrage bei clientA.schlegleixner.com eingeht, fängt eine Middleware die Subdomain ab, fragt die Tenants-Tabelle ab, ermittelt die Tenant-ID und injiziert sie in den Application Container. Jede nachfolgende Operation: Datenbankabfragen, Dateispeicherung, Authentifizierungsprüfungen – erbt diesen Tenant-Kontext.

Auf die technische Implementierung folgt das Root-Domain-Routing. Dieses wird in Laravels routes/web.php konfiguriert. Die Root-Domain (schlegleixner.com) dient als Landing Page oder Administrative Interface, während Subdomains zu tenant-spezifischen Umgebungen routen. In unserem Fall zur Content- und Benutzerverwaltung, die vollständig datenbankgestützt ist. Alle Content-Einträge, Benutzerkonten und Berechtigungen liegen in der Datenbank mit tenant_id Foreign Keys. Das ermöglicht dynamischen, tenant-spezifischen Content ohne Filesystem-Kopplung.

Dann gibt es den Super User Zugang. Der Statamic Super User kann sich in jede Tenant-Umgebung einloggen – eine bewusste Design-Entscheidung von SchleeGleixner für die administrative Übersicht. Dieser Cross-Tenant-Zugriff ist nur für Super User vorgesehen; reguläre Tenant-Benutzer bleiben isoliert. Ebenso verhält es sich mit E-Mail- und Queue-Isolation. E-Mails, Queues und Jobs sind tenant-beschränkt. Wenn ein Job dispatched wird, trägt er die tenant_id in seinem Payload, was sicherstellt, dass Hintergrundprozesse (E-Mail-Benachrichtigungen, Asset-Verarbeitung) im korrekten Tenant-Kontext ausgeführt werden. Stencils Tenant-Aware Job Traits erledigen das automatisch.

Zusätzlich zur E-Mail- und Queue-Isolation gibt es Asset-Isolation. Hier werden Assets (Logos, Markenmaterialien, Deliverables) pro Tenant gekapselt. Dateipfade sind nach tenant_id mit Namespace versehen, was Cross-Tenant-Zugriff verhindert. Ein Kunde, der auf clientA.schlegleixner.com zugreift, kann nur Assets abrufen, die im Verzeichnis von Tenant A gespeichert sind. Statemics Content-Strukturen (Blueprints, Field Sets) werden tenant-übergreifend geteilt. Diese Zentralisierung ist beabsichtigt für SchleeGleixners Design-Delivery-Prozess, der einem standardisierten Workflow folgt. Das Teilen dieser Strukturen bedeutet, dass Updates am Content-Modell sofort an alle Tenants weitergegeben werden und Konsistenz ohne manuelle Synchronisation gewährleistet ist.

Rollen und Gruppen werden im Filesystem mit Statemics Standard-File-Driver gespeichert. Während Content und Benutzer datenbankgestützt sind, bleiben Berechtigungsstrukturen dateibasiert. Dieser hybride Ansatz balanciert Flexibilität (tenant-spezifische Benutzer) mit Einfachheit (global definierte Rollen). Diese Berechtigungen gewähren Authentifizierung und Asset-Zugriff. Der Bild-Abruf erfordert Authentifizierung. Wir haben eine authentifizierte Route implementiert, die drei Bedingungen prüft, bevor ein Bild ausgeliefert wird:

(1) Der Benutzer ist im aktuellen Tenant eingeloggt und hat eine aktive Session

(2) Das angeforderte Bild gehört zum Asset-Verzeichnis dieses Tenants

Wenn eine dieser Bedingungen fehlschlägt, wird die Anfrage abgelehnt. So wird sichergestellt, dass Benutzer von Tenant A keine URLs konstruieren können, um auf Assets von Tenant B zuzugreifen. Authentifizierung und Asset-Eigentümerschaft werden auf Anwendungsebene durchgesetzt, nicht nur durch Filesystem-Berechtigungen. Wenn ein Kunde clientA.schlegleixner.com besucht, wird er zum Login aufgefordert.

Nach der Authentifizierung ist seine Session auf Tenant A beschränkt. Er kann den Content von Tenant A durchsuchen, Assets in den Storage von Tenant A hochladen und die Deliverables von Tenant A ansehen. Aber er kann keine Ressourcen von Tenant B sehen oder auch nur anfragen. Die Tenant-Grenze ist absolut.

DIE HERAUSFORDERUNG

Stencils Multi-Tenancy-Package kümmerte sich um Tenant-Identifikation und Datenbank-Scoping, aber Statemics Eloquent Driver war nicht vollständig tenant-aware out of the box. Bestimmte Operationen: Global Variable Management, Asset-Handling und spezifische User-Management-Flows, wurden nicht automatisch auf den aktiven Tenant beschränkt. Der Driver wurde geschrieben, ohne Multi-Tenancy als erstrangige Anforderung zu berücksichtigen, was bedeutete, dass einige Methoden den Tenant-Kontext beim Lesen oder Schreiben von Daten komplett umgingen. Um vollständige Isolation zu erreichen, verwendeten wir XDebug, um zu verfolgen, wo der Tenant-Kontext verloren ging.

XDebug ist ein Step-Debugging-Tool für PHP-Anwendungen. Durch das Setzen von Breakpoints an mehreren Stellen – Datenschreibvorgänge, Global-Variable-Zugriff, Asset-Storage-Operationen – unterbrachen wir die Ausführung zur Laufzeit und untersuchten den Call Stack. Das enthüllte exakt, welche Driver-Methoden den Tenant-Scope beim Speichern oder Abrufen von Globals nicht respektierten. Einmal identifiziert, überschrieben wir diese Methoden, um Tenant-Filterung zu erzwingen, und machten so das Statamic Control Panel vollständig tenant-aware. Mit dem korrigierten Driver fiel alles andere an seinen Platz: authentifizierte Asset-Routen, beschränkte Authentifizierung, isolierte Queues – alles Standard-Implementierungen, sobald das grundlegende Driver-Problem behoben war.

Eine wichtige Erkenntnis dieser Fallstudie ist, dass Multi-Tenancy-Fehler oft in Framework-Drivern versteckt sind, nicht im Anwendungscode. XDebugs Runtime-Inspektion ermöglichte es uns, die Lücke in Stunden statt in Tagen von Trial-and-Error-Debugging zu finden. Das ist genau die Expertise-Lücke, vor der das Team von SchleeGleixner stand: zu wissen, wo man suchen muss, wenn Tenant-Isolation zusammenbricht.

Nichtsdestotrotz hätten wir im Rückblick auf unsere technische Implementierung und als potenziellen Open-Source-Beitrag diese Driver-Overrides als Pull Request (PR) zum Statamic-Repository beitragen sollen. Die Tatsache, dass kleine Änderungen nötig waren, um den Eloquent Driver vollständig tenant-aware zu machen, deutet auf eine Lücke in der offiziellen Implementierung hin; eine, die wahrscheinlich andere betrifft, die Multi-Tenant-Systeme auf Statamic aufbauen. Ein PR hätte das Core-Package verbessert und es der breiteren Community erleichtert, Multi-Tenancy zu implementieren, ohne auf dieselben Hindernisse zu stoßen. Künftig priorisieren wir Beiträge zu Open-Source-Projekten, wenn wir Framework-Limitierungen entdecken. Diese Beiträge stärken das Ökosystem und reduzieren Reibungsverluste für zukünftige Entwickler, die ähnliche architektonische Herausforderungen angehen.

Warum Statamic für eine Multi-Tenancy-Architektur?

SchleeGleixner wählte Statamic wegen der überlegenen Developer Experience. Es bietet moderne Architektur, saubere Codebasis und intuitive APIs, die die Arbeit deutlich angenehmer machen und zu einer besseren Developer Experience führen, oft abgekürzt als DX. Das umfasst alles von API-Design über Dokumentationsqualität bis hin zu lokalen Entwicklungsworkflows, und Statamic glänzt hier.

Als Multi-Tenancy-Fundament: Statemics Architektur basiert primär auf dateibasiertem Storage. Es bietet einen First-Party Eloquent Driver für die Datenbanknutzung, was es perfekt für eine Multi-Tenancy-Umgebung geeignet macht. SchleeGleixner wusste, dass Multi-Tenancy mit Statamic möglich ist (es ist ein bewährter Anwendungsfall).

Zusätzlich wurde Statamic wegen der Plattformkontinuität gewählt. SchleeGleixner nutzte Statamic bereits für interne Workflows. Ein Wechsel hätte bedeutet, das Team neu zu schulen, bestehende Tools neu zu schreiben und institutionelles Wissen aufzugeben. Daher war die Erweiterung des bestehenden Statamic-Fundaments die pragmatische Wahl.

VORTEILE DES GEWÄHLTEN TECH STACKS

Stencils Tenancy-Package

Wir haben Stencil gegenüber Spaties Tenancy-Package wegen der überlegenen Subdomain-Routing-Anpassung gewählt. Stencils Tenant-Aware Job Traits kümmerten sich automatisch um Background-Process-Scoping. Wenn ein Queue-Job dispatched wird, trägt er den Tenant-Kontext ohne manuellen Eingriff.
Die Konfigurierbarkeit des Packages ermöglichte es uns, Tenant-Identifikation, Datenbank-Scoping und Asset-Isolation an die spezifischen Workflows von SchleeGleixner anzupassen.

Statamic CMS

Native datenbankgestützte Architektur für Multi-Tenancy ausgelegt; vielseitiger Form Builder ermöglichte Operations-Platform-Design mit tenant-aware Control Panel und korrekter Tenant-Isolation.

Laravel

Statemics zugrundeliegendes Framework lieferte das architektonische Fundament mit Eloquent ORM für tenant-beschränkte Datenbankoperationen via Global Scopes und Model Observers; Subdomain-Routing übernahm die Tenant-Identifikation mit einem ausgereiften Ökosystem, das Middleware Chains, Service Container und Request Lifecycle Management unterstützt.

DDEV (Lokale Entwicklungsumgebung)

DDEVs Docker-Containerisierung replizierte die Multi-Subdomain-Struktur der Produktionsumgebung lokal – clientA.ddev.site, clientB.ddev.site, clientC.ddev.site boten Parität zwischen lokaler und Produktionsumgebung, essenziell für das Debugging von Grenzfällen beim Tenant-Wechsel und die Validierung der Isolation vor dem Deployment.

XDebug (Step Debugging)

XDebug erwies sich als entscheidend für die Fehlerbehebung von Tenant-Awareness-Lücken im Eloquent Driver. Runtime-Breakpoints analysierten Komplexitäten, debuggten Probleme, Limitierungen oder fehlende Implementierungen zusammen mit Code-Inspektion. XDebug eliminierte das Rätselraten.

Statamic Eloquent Driver

Der Eloquent Driver ermöglichte datenbankgestützte Content-Speicherung, bot Object-Relational Mapping für saubere Datenhandhabung und integrierte sich nahtlos in Laravels Ökosystem.

Insgesamt war die Synergie des Tech Stacks ein unkomplizierter Prozess. Erstens gab es bereits ein Bewusstsein für die Aufgabe und alle Wege, die nötig waren, um die Aufgabe bestmöglich zu erfüllen. Die Kombination aus DDEV für die lokale Umgebung, XDebug fürs Debugging, Statamic für die CMS-Schicht, Laravel als Fundament und Stencils Tenancy-Package für Multi-Tenancy schuf eine solide, effiziente Entwicklungserfahrung. Statamic war für das gegebene Ziel des Kunden eine gute Option. Das Projekt bestätigte, dass Stencils Tenancy-Package die richtige Wahl war, weil es Konfigurationsoptionen bot, die die Anpassung an den Anwendungsfall erleichterten.

Für SchleeGleixner (zum Zeitpunkt der Projektauslieferung): dutzende Tenants, moderater Traffic – eine einzelne Datenbank mit Scoping auf Anwendungsebene war optimal. Aber die architektonische Erweiterbarkeit wird nicht zusammenbrechen, wenn sich die Anforderungen ändern. Das ist der Wert der Wahl von Tools, die zu Ihrem Anwendungsfall passen, anstatt Ihren Anwendungsfall in Tools zu pressen.

Warum uns als Laravel-Experten wählen?

Wenn Kunden sich an uns wenden, tun sie das oft gezielt, weil wir die Antworten auf ihre Probleme haben.

Wir beherrschen das Laravel Framework in- und auswendig und wissen, wie man es einsetzt.

Wir verstehen, wie man Laravel-Anwendungen für komplexe Projekte strukturiert: bidirektionale Systemintegration, Wartbarkeit, Performance-Optimierung, korrekte Sicherheitsmaßnahmen, Website-Accessibility und wie man Laravel mit anderen und älteren Systemen integriert.

Für unsere zukünftigen Kunden, die Custom Software Development in Betracht ziehen: Laravel ist eine ausgezeichnete Wahl, und die Partnerschaft mit uns als Laravel-Experten stellt sicher, dass sich diese Wahl auszahlt.