← Back to projects
Not public

Gutz Admin

Central Filament 5 admin that unifies the admin surfaces of Gutz Intern and the club website via a multi-database architecture.

Gutz Admin

Before Gutz Admin, there were two separate admin interfaces — one in Gutz Intern (Filament 5, for members, shifts, finances), one in the club website (Filament 3, for content, events, gallery). That meant duplicated maintenance, inconsistent permission models, and no overall view. Gutz Admin is a single Filament 5 panel that reads from and writes to three separate, independently operated production databases.

Case Study

Situation

An in-place rebuild of one of the existing projects was ruled out, because the two ran different Filament versions (3 and 5) with different, scattered permission checks. Gutz Admin was built as a completely new project instead.

Challenge

A single panel has to read from and write to three separate MySQL databases (the new integration database, plus the production databases of Gutz Intern and the club website). Every Eloquent model gets its database connection set explicitly. A second, related challenge is authentication: login still runs against Gutz Intern’s user data, but Filament needs a local user record for roles and permissions — solved with a “shadow user” that gets mirrored on every login and additionally synchronized in batches via a command, with its own run logging.

Approach

Laravel 13, Filament 5, PHP 8.3, set up as a completely new project rather than a fork. Additional packages for PDF export, image processing, barcode generation, and Sentry monitoring.

Decisions

Separate database connections instead of one shared database

Each domain stays in its own leading data source to avoid unnecessary data duplication; only governance data (roles, module access, sync status, audit logs) lives in the new admin database.

Shadow-user synchronization for auth

Login still runs against the existing user data; a sync mirrors it into the local admin database on every login as well as in batches via a command, logging failed runs.

Granular permission model instead of coarse bundled rights

Fine-grained permissions instead of a few large administrative rights, with alias mapping of old role slugs so existing assignments carry over without manual rework.

No big-bang cutover

The old panels keep running in parallel, modules are migrated step by step, and progress is made measurable via a dedicated audit page.

Domain-based hubs instead of a plain resource list

The main navigation is organized by area of responsibility (members, shifts, finances, content, media); Filament resources now only serve detail maintenance.

My contribution

61 Eloquent models, 33 Filament resources, 26 pages, several dashboard widgets, the sync command for user mirroring, the auth service for cross-database login, and the central permission and navigation logic — all built solo.

Results

Scope
61 models, 33 Filament resources, 26 pages
Data sources
3 separate databases unified in one panel
Status
active, step-by-step rollout — the legacy panels keep running in parallel in the meantime

Search & navigation

Navigate Open Esc Close