Building a Multi-Tenant Architecture to Scale SchleeGleixner’ Brand Asset Delivery

SchleeGleixner needed a scalable solution to manage and deliver design work to multiple clients at once. The challenge: maintaining separate, branded environments for each client within a single Statamic installation.

As a solution, we implemented a subdomain-based multi-tenancy architecture on Statamic CMS, that enabled SchleeGleixner to operate one centralized Statamic installation where each client exists as an isolated tenant with their own branded subdomain (e.g., clientname.schlegleixner.com).

The deliverable was a production-ready, tested multi-tenancy foundation that the client could build upon independently.

PS: No front-end customization was done in this project as the client wanted to do this themselves.

SchleeGleixner needed a centralized Statamic installation serving multiple clients, each in their own isolated environment. They had already committed to Statamic for good reasons: modern architecture, proven multi-tenancy capabilities, and database-backed flexibility.

Switching platforms was not an option. The solution: building a subdomain-based multi-tenancy architecture suited to their internal workflow.

However, they had hit an implementation roadblock. There was a gap between theory and execution – critical pieces were not connecting:

1. Tenant isolation was not complete - Data was leaking between tenants

2. Authentication was not properly scoped to tenant

3. Assets were not isolating correctly

4. The debugging trail had gone cold

SchleeGleixner needed an expert who could identify where tenant-awareness was breaking down, debug through the Statamic Eloquent driver, and implement the missing pieces – without rewriting everything. Not a new platform, but the infrastructure expertise to unlock the multi-tenancy foundation they had already chosen.

There can be different approaches to the implementation. One could add more complexity to the architecture if needed to handle a lot of load. It's an extensible approach and for the given use case it worked just fine.

Instead of using Statamic as a traditional website CMS, SchleeGleixner turned it into a design delivery system. Their designers upload assets (logos, brand materials, colour schemes) and present them as interactive deliverables to clients. Each client gets a branded mood board experience within their own isolated tenant environment.

Multi-tenancy eliminated the overhead of managing multiple Statamic installations while maintaining strict data isolation.
Each tenant maintained:

1. Separate user management and authentication;

2. Isolate asset storage;

3. Custom branding in the control panel;

4. Tenant specific configurations.

We set up a private repository and granted SchleeGleixner collaborative access. Their team could download the codebase, review changes through small commits, and extend the multi-tenancy foundation independently.

For this project, we solely delivered an infrastructure handoff other than code deployment, plus, demonstrated functional tenant isolation and identification (Tenant A from Tenant B). Each tenant is distinct and cannot access another tenant's data, assets, or users.

We built an empty Statamic installation configured for subdomain-driven multi-tenancy with a single centralized database. The subdomain acts as the tenant identifier. For instance, when a request comes in at clientA.schlegleixner.com, the system automatically resolves which tenant is being accessed and scopes all subsequent operations to that tenant's data. 

Each client receives their own branded subdomain under SchleeGleixner's domain. For example, clientA.schlegleixner.com and clientB.schlegleixner.com operate as completely separate environments. If Laramate became a client, accessing laramate.schlegleixner.com would present a fully branded welcome page with their corporate identity thus creating a white-label experience where each client perceives the platform as custom-built for them. 

We chose a single database over multi-database architecture. Multiple databases add complexity without improving security – you can still access all databases through the driver. Physical database separation only becomes necessary at enterprise scale with strict compliance requirements. For this project, that overhead was not justified.

Data separation happens through tenant scoping at the application level. Using Stencil's tenancy package, we added a tenant_id column across all relevant tables. Every row carries its tenant identifier: Tenant A's data has tenant_id = 1, Tenant B's has tenant_id = 2, and so on. A dedicated tenants table maps subdomains to tenant IDs and stores tenant-specific configuration. The rest is programming: ensuring every query, file operation, and asset retrieval respects tenant boundaries.

Data security between tenants is achieved through rigorous scoping - every database query filtered by tenant_id, every file path namespaced by tenant, every authentication check scoped to the current tenant. We validated this through comprehensive testing to ensure no cross-tenant data leakage.

We used DDEV to replicate the production multi-subdomain structure locally. The development environment ran with full subdomain support: clientA.ddev.site, clientB.ddev.site, clientC.ddev.site, allowing us to test tenant isolation thoroughly before deployment. This local-production parity was critical for debugging edge cases in tenant switching and data scoping. 

We provided a PHP Unit test suite covering tenant separation, authentication scoping, and asset isolation. These tests validate that Tenant A cannot access Tenant B's data, users, or files under any circumstance. The test suite serves as both validation and documentation, proving the multi-tenancy implementation is robust and provides a safety net for future development.

The foundation uses Statamic's Eloquent driver to persist all content to the database, enabling true multi-tenancy at the data layer. SchleeGleixner got full control to build their design delivery workflows without inheriting unnecessary structure.

Tenant resolution within SchleeGleixner: Tenant identification happens automatically via subdomain. When a request hits clientA.schlegleixner.com, middleware intercepts the subdomain, queries the tenants table, resolves the tenant ID, and injects it into the application container. Every subsequent operation: database queries, file storage, authentication checks, inherits this tenant context.

Root domain routing is configured in Laravel's routes/web.php. The root domain serves as the landing page, while subdomains route to tenant-specific environments. All content entries, user accounts, and permissions live in the database with tenant_id foreign keys. This allows dynamic, tenant-specific content without filesystem coupling.

Super users can access any tenant environment – a deliberate design choice for administrative oversight. Regular users remain fully isolated. Emails, queues, and jobs are also tenant-scoped. When a job is dispatched, it carries the tenant_id in its payload, ensuring background processes (email notifications, asset processing) execute within the correct tenant context. Stencil's tenant-aware job traits handle this automatically.

Assets (logos, brand materials, deliverables) are also isolated per tenant. File paths are namespaced by tenant_id, preventing cross-tenant access. A client accessing clientA.schlegleixner.com can only retrieve assets stored under Tenant A's directory. Statamic's content structures (blueprints, field sets) are shared across tenants. This centralization is intentional to SchleeGleixner's design delivery process which follows a standardized workflow. Sharing these structures means updates to the content model propagate to all tenants instantly, maintaining consistency without manual synchronization.

Roles and groups are stored in the filesystem using Statamic's default file driver. Content and users are database-backed, but permission structures remain file-based – balancing flexibility with simplicity. Image retrieval requires authentication. We implemented a route that validates two conditions before serving an image:

1. the user is logged into the current tenant and has an active session

2. the requested image belongs to that tenant's asset directory

If either condition fails, the request is denied. Tenant A users cannot access tenant B's assets. When a client visits clientA.schlegleixner.com, they're prompted to log in.

Once authenticated, their session is scoped to Tenant A. They can browse content, upload assets, and view deliverables – but cannot access anything from Tenant B. The tenant boundary is absolute.

Stencyl's package handled tenant identification and database scoping, but Statamic's Eloquent driver was not fully tenant-aware out of the box. Some operations – global variables, asset handling, user management – bypassed tenant context entirely. To find these gaps, we used XDebug to trace where tenant context was being lost.

By setting breakpoints at key junctions – data writes, global variable access, asset storage – we inspected the call stack at runtime. This revealed which driver methods were not respecting tenant scope. Once identified, we overrode those methods to enforce tenant filtering. With the driver corrected, everything else fell into place: authenticated asset routes, scoped authentication, and isolated queues.

Key insight: multi-tenancy failures often hide in framework drivers, not application code. XDebug helped us pinpoint the gap in hours rather than days. That is the expertise SchleeGleixner needed: knowing where to look when tenant isolation breaks down.

In hindsight, we should have contributed these driver overrides back to the Statamic repository as a pull request (PR). The minor changes needed indicate a gap in the official implementation that likely affects others. Going forward, we prioritize contributing back to open-source projects when we find framework limitations.

SchleeGleixner chose Statamic for its superior developer experience: modern architecture, clean codebase, and intuitive APIs. From API design to documentation to local development workflows – Statamic excels.

Statamic's first-party Eloquent driver enables database-backed operation, making it perfectly suited for multi-tenancy. SchleeGleixner knew this was a proven use case.

Platform continuity also mattered. SchleeGleixner was already using Statamic internally. Switching would mean retraining the team and rewriting tools. Extending their existing foundation was the pragmatic choice.

The combination of DDEV, XDebug, Statamic, Laravel, and Stencil's tenancy package created a solid development experience. The project confirmed that Stencil's package was the right choice – its configuration options made it easy to adapt to this specific use case.

For SchleeGleixner's scale – dozens of tenants, moderate traffic – a single database with application-level scoping was optimal. And the architecture can grow when requirements change. That is the value of choosing tools that fit your use case.

When clients reach out to us, they often do so specifically because we have the answers to their pain-points.

We have mastered the Laravel framework intimately, and we know how to use it.

We structure Laravel applications for complex projects: system integration, maintainability, performance, security, accessibility, and integration with legacy systems.