Laravel Filament: Admin-Panels in Tagen statt Wochen

Jede Geschäftsanwendung hat zwei Gesichter: das, was Kunden sehen, und das Backoffice, in dem dein Team Daten pflegt, Bestellungen prüft und Nutzer verwaltet. Das zweite Gesicht hat jahrelang absurd viel Budget gefressen. CRUD-Masken von Hand zu bauen ist aufwendig und begeistert am Ende niemanden. Filament hat dieses Problem in der Laravel-Welt weitgehend gelöst und verschiebt damit, wofür Projektbudget sinnvoll ausgegeben wird.

Was Filament ist

Filament ist ein Open-Source-Framework (MIT-Lizenz) für Verwaltungsoberflächen in Laravel-Anwendungen, technisch auf Livewire, Alpine.js und Tailwind CSS gebaut. Das Prinzip: Aus deinen Eloquent-Models werden per Konfiguration sogenannte Resources, also komplette Verwaltungsbereiche mit Listenansicht, Filtern, Suche, Formularen, Validierung und Detailseiten.

Version 4 (August 2025) hat den Kern deutlich erweitert: Multi-Faktor-Authentifizierung ist eingebaut, Tabellen laufen bei großen Datenmengen spürbar schneller, und ein Schema-System mischt Formulare, Tabellen und eigene Ansichten auf einer Seite. Version 5 folgte im Januar 2026 und bringt vor allem die Unterstützung für Livewire 4. Funktional ist sie mit v4 identisch, beide Linien bekommen weiter neue Features. Mit über 32.000 GitHub-Sternen und einem breiten Plugin-Ökosystem ist Filament die meistempfohlene Antwort auf die Frage nach dem Laravel-Admin-Panel und damit de facto der Community-Standard.

So wenig Code steckt dahinter

„Wenig Code“ klingt nach Marketing, deshalb ein konkretes Beispiel. Das hier ist der Kern einer Bestellverwaltung mit Formular, durchsuchbarer Liste, Status-Badges und Filter:

use App\Enums\OrderStatus;
use Filament\Forms\Components\Select;
use Filament\Forms\Components\TextInput;
use Filament\Schemas\Schema;
use Filament\Tables\Columns\TextColumn;
use Filament\Tables\Filters\SelectFilter;
use Filament\Tables\Table;

public static function form(Schema $schema): Schema
{
    return $schema->components([
        TextInput::make('number')->required(),
        Select::make('customer_id')
            ->relationship('customer', 'name')
            ->searchable(),
        Select::make('status')->options(OrderStatus::class)->required(),
    ]);
}

public static function table(Table $table): Table
{
    return $table
        ->columns([
            TextColumn::make('number')->searchable(),
            TextColumn::make('customer.name')->sortable(),
            TextColumn::make('status')->badge(),
            TextColumn::make('total')->money('EUR'),
        ])
        ->filters([
            SelectFilter::make('status')->options(OrderStatus::class),
        ]);
}

Paginierung, Sortierung, Anlegen, Bearbeiten, Löschen und die Validierung der Pflichtfelder kommen ohne weitere Zeile dazu. Rechte laufen über ganz normale Laravel-Policies: Darf ein Nutzer laut OrderPolicy keine Bestellungen löschen, verschwindet der Button, und die Aktion wird auch serverseitig blockiert. Wer Laravel kennt, muss also kaum umlernen und schreibt einfach weniger.

Was das fürs Budget bedeutet

Der Vergleich aus der Projektpraxis:

Aufgabe	Von Hand (Blade/Vue)	Mit Filament
CRUD für ein Datenmodell (Liste, Filter, Formular, Validierung)	Tage	Stunden
Rechte- und Rollenverwaltung	Tage	Stunden bis ein Tag
Dashboard mit Kennzahlen-Widgets	Tage	Stunden
Export, Bulk-Aktionen, Suche	je Feature ein Posten	weitgehend eingebaut

Bei einer typischen Geschäftsanwendung macht das Backoffice schnell ein Drittel des Aufwands aus. Filament drückt diesen Anteil stark, allerdings nicht auf null, denn Datenmodell, Geschäftslogik und saubere Rechte bleiben echte Arbeit. Der Unterschied liegt zwischen „das Admin-Panel ist ein eigenes Teilprojekt“ und „das Admin-Panel ist in der ersten Woche nebenbei entstanden“.

Für unsere Laravel-Projekte (ab 10.000 €, typisch 15.000–⁠60.000 €) heißt das: Das Budget wandert dorthin, wo dein Geschäft sich von anderen unterscheidet. Also in die Prozesslogik, in die Schnittstellen zu ERP und Drittsystemen und in die Datenqualität, statt in die dreißigste handgebaute Tabellen-Ansicht.

Filament oder Nova?

Die Frage kommt in fast jedem Erstgespräch, deshalb hier kompakt:

	Filament	Laravel Nova
Herkunft	Community-Projekt, Open Source	Offizielles Produkt des Laravel-Teams
Lizenz	MIT, kostenlos	Kostenpflichtige Lizenz pro Projekt
Technik	Livewire, Alpine.js, Tailwind	Vue und Inertia
Ökosystem	Hunderte Community-Plugins	Kleiner, stärker kuratiert
Anpassbarkeit	Eigene Seiten und Komponenten in PHP	Eigene Felder und Tools meist in Vue

Nova ist kein schlechtes Produkt. Für ein Team, das ohnehin in Vue arbeitet und ein offizielles Produkt mit Lizenzvertrag bevorzugt, kann es passen. In der Laravel-Community hat sich Filament aber klar durchgesetzt, und das merkt man bei Plugins, Tutorials und Antworten auf konkrete Probleme. Für uns gibt außerdem den Ausschlag, dass Anpassungen in PHP bleiben und kein zweiter Frontend-Stack nötig ist.

Wofür Filament die richtige Wahl ist

• Interne Tools und Backoffices: Bestellverwaltung, Redaktions-Workflows, Datenpflege. Das ist der Kernfall, für den Filament gebaut ist.
• Verwaltung hinter Kundenportalen und SaaS: Kunden sehen dein individuelles Frontend, dein Team arbeitet im Filament-Panel dahinter. Der häufigste Zuschnitt in unseren Projekten. Genau so läuft es im Online-Shop der Vulkaneifel Therme: Kunden buchen im individuellen Laravel-Frontend, das Team verwaltet Gutscheine und Reservierungen im Filament-Backoffice.
• MVPs und Pilotphasen: Wenn erst einmal das Team mit echten Daten arbeiten soll, bevor in polierte Oberflächen investiert wird, liefert Filament den Arbeitsstand in Tagen.
• Ablösung von Excel-und-E-Mail-Prozessen: Der klassische Mittelstandsfall. Ein Prozess, der in Tabellen und Postfächern lebt, bekommt eine zentrale, rechtegesteuerte Oberfläche.
• Mandantenfähige Verwaltung: Filament kann ein Panel an ein Tenant-Model binden und Daten automatisch pro Mandant eingrenzen. Wie das mit der restlichen Architektur zusammenspielt, steht in unserem Artikel zu Multi-Tenancy in Laravel.

Wo Filament nicht die Antwort ist

Filament-Oberflächen sind Werkzeuge und sehen auch so aus: aufgeräumt, funktional, erkennbar Panel. Für interne Nutzer ist das genau richtig, für zahlende Endkunden oft zu wenig.

• Kundenseitige Produkt-Oberflächen mit eigenem Design-Anspruch, Marken-Erlebnis und frei gestalteten Abläufen bleiben eine Aufgabe für individuelles Frontend.
• Hochinteraktive Spezial-UIs wie Konfiguratoren, Karten-Anwendungen oder Echtzeit-Boards sprengen das Formular-und-Tabellen-Paradigma.
• Nicht-Laravel-Umgebungen: Filament ist tief mit Laravel verzahnt. Das ist seine Stärke und zugleich seine Grenze.

Die Entscheidung ist selten entweder/oder. Individuelles Frontend für Kunden, Filament für das Team dahinter: So bekommen beide Seiten die Oberfläche, die zu ihnen passt, und keine subventioniert die andere quer.

Worauf wir in Filament-Projekten achten

Filament macht den Einstieg leicht. Ob ein Panel nach zwei Jahren noch gut wartbar ist, entscheidet sich an ein paar Stellen, die in schnellen Demos gern untergehen:

• Rechte von Anfang an über Policies. Filament prüft Policies für alle Standard-Aktionen automatisch. Eigene Seiten, Aktionen und Livewire-Komponenten musst du dagegen selbst absichern. Wer Rechte erst am Ende nachrüstet, sucht Lücken in jeder einzelnen Ansicht.
• Geschäftslogik gehört nicht ins Panel. Eine Statusänderung, die E-Mails verschickt und das ERP informiert, lebt in einer Action-Klasse oder State Machine und wird vom Panel nur aufgerufen. So nutzen API, Queue-Jobs und Backoffice dieselbe Logik. Wie das bei Zahlungsstatus aussieht, zeigt unser VRPay-Praxisbeispiel.
• Plugins prüfen, bevor sie ins Projekt kommen. Das Ökosystem ist groß, die Qualität schwankt. Wir schauen auf Wartungsstand, Kompatibilität mit der aktuellen Major-Version und darauf, ob wir das Plugin im Notfall selbst weiterpflegen könnten.
• Nicht gegen das Framework bauen. Wenn eine Ansicht nur noch mit tiefen Eingriffen in Filament-Interna funktioniert, ist eine eigene Livewire-Seite im Panel meist günstiger. Die fügt sich optisch ein und bleibt trotzdem unabhängig.
• Major-Upgrades einplanen. Der Sprung von v3 auf v4 brachte echte Umbauarbeit, v4 auf v5 dagegen fast keine. Solche Upgrades gehören in die Wartungsplanung und nicht als Überraschung ins Budget.
• Tests für das Panel. Filament-Ressourcen lassen sich mit Pest und den Livewire-Test-Helpern prüfen: Wer darf was sehen, speichert das Formular korrekt, greift der Filter? Diese Tests sind kurz und fangen genau die Fehler, die sonst erst im Betrieb auffallen.

Einordnung: Warum das für Auftraggeber relevant ist

Wenn du Angebote für eine Webanwendung vergleichst, lohnt die Frage, wie der Verwaltungsteil gebaut wird. Ein Anbieter, der das Backoffice von Hand baut, verbrennt dein Budget an einer Stelle, die nie ein Alleinstellungsmerkmal wird. Einer, der behauptet, mit Panel-Frameworks sei „alles in zwei Tagen fertig“, unterschlägt Datenmodell, Rechte und Logik. Die belastbare Mitte sieht so aus: Standardwerkzeug für Standardaufgaben, Individualentwicklung dort, wo dein Prozess besonders ist, und ein Angebot, das diese Trennung transparent macht. Nach diesem Prinzip kalkulieren wir individuelle Webanwendungen. Warum Laravel dafür überhaupt die passende Basis ist, erklärt unser Beitrag Warum Laravel für Unternehmen.