Filament v4 in 2026: Why the Panel Builder Is Worth a Second Look

If your mental model of Filament is still “the admin panel package from a couple of years ago,” it is time to refresh it. Filament v4 has been stable for a while now, and as of this writing the framework sits at 4.11.3 with a steady stream of point releases since launch. That maturity matters. The version that shipped on day one has been sanded down by months of bug fixes and meaningful feature additions, and the result is the most capable version of Filament yet. If you build internal tools, dashboards, or full Laravel applications on top of a panel, here is what changed and why it is worth a second look.

Rendering That Is Genuinely Faster

The headline engineering work in v4 was performance, and the team did not chase it with micro-optimizations. They changed how the framework renders HTML. Table cells, historically the most expensive thing Filament draws because there are so many of them, were reworked to render roughly 2.38x faster than v3. The broader strategy was to stop including so many separate Blade view files and instead render markup directly from existing PHP objects, which cuts the number of files the framework has to load on each request.

For most apps this shows up as snappier tables and lower memory pressure on list pages with lots of columns. If you have ever watched a Filament resource with thirty columns and a few hundred rows crawl, this is the release that addresses it.

A Unified Schema for Forms and Infolists

One of the quieter but more important architectural shifts in v4 is the unified schema concept. Forms, infolists, and other layouts now share a common schema foundation, which means the components and layout primitives you learn in one place transfer to the others. A Section, a Grid, a Tabs container behave consistently whether you are collecting input or displaying read-only data.

use Filament\Schemas\Schema;
use Filament\Forms\Components\TextInput;
use Filament\Forms\Components\Select;

public function form(Schema $schema): Schema
{
    return $schema->components([
        TextInput::make('title')
            ->required()
            ->maxLength(255),

        Select::make('status')
            ->options([
                'draft' => 'Draft',
                'published' => 'Published',
            ])
            ->default('draft'),
    ]);
}

The payoff is fewer concepts to hold in your head. Once you understand how a schema composes components, you understand forms, infolists, and the layout system all at once.

Nested Resources

Nested resources let you operate on a resource within the context of its parent. The classic example is order line items that only make sense inside a specific order, or comments that belong to a post. Instead of a flat, top-level “Comments” resource that forces you to filter by post ID, you edit comments directly inside the post that owns them, with the URL and breadcrumbs reflecting that relationship.

This is the kind of feature you do not realize you were missing until you use it. It maps the admin UI to how your data actually relates, rather than forcing every model into a flat list of its own.

The Rich Editor Switched to TipTap

Filament’s rich text editor moved off Trix and onto TipTap. Trix was always a bit of a black box, hard to extend and awkward when you wanted custom blocks. TipTap is a modern, extensible editor, and the switch unlocks features that were painful before.

The standout addition, which landed in v4.5, is mentions. You can configure a trigger character that opens a searchable dropdown of records, users, tags, issues, whatever you wire up, right inside the editor content.

use Filament\Forms\Components\RichEditor;

RichEditor::make('body')
    ->mergeTags([
        'name',
        'company',
    ])
    ->mentions(
        trigger: '@',
        suggestions: fn (string $query) => User::query()
            ->where('name', 'like', "%{$query}%")
            ->limit(10)
            ->pluck('name', 'id')
            ->all(),
    );

For anything resembling a CMS, a ticketing tool, or internal docs, mentions are the feature that pushes Filament’s editor from “fine” to “actually pleasant.”

Multi-Factor Authentication Without the Boilerplate

Filament v4 ships first-party multi-factor authentication, and v4.5 made it almost trivial to adopt. Earlier you had to implement a handful of contract methods and remember to cast and hide the right columns. Now there are traits that supply sensible defaults: column casting, hidden attributes, and the required interface methods are all handled for you.

use Filament\Models\Contracts\FilamentUser;
use Filament\Auth\MultiFactor\App\Contracts\HasAppAuthentication;
use Filament\Auth\MultiFactor\App\Concerns\InteractsWithAppAuthentication;
use Filament\Auth\MultiFactor\App\Contracts\HasAppAuthenticationRecovery;
use Filament\Auth\MultiFactor\App\Concerns\InteractsWithAppAuthenticationRecovery;
use Illuminate\Foundation\Auth\User as Authenticatable;

class User extends Authenticatable implements
    FilamentUser,
    HasAppAuthentication,
    HasAppAuthenticationRecovery
{
    use InteractsWithAppAuthentication;
    use InteractsWithAppAuthenticationRecovery;
}

Enable it on the panel and you get app-based TOTP authentication with recovery codes out of the box. You can still implement the methods yourself when you need custom storage or behavior, but the common case is now two traits and two contracts.

use Filament\Panel;

public function panel(Panel $panel): Panel
{
    return $panel
        ->multiFactorAuthentication([
            \Filament\Auth\MultiFactor\App\AppAuthentication::make()
                ->recoverable(),
        ]);
}

Given how often “we should add 2FA to the admin” sits at the bottom of a backlog forever, removing the friction here is a real win.

Should You Upgrade From v3?

If you are starting something new, start on v4. There is no reason to begin a project on the previous major. The upgrade story from v3 is handled by an automated upgrade script that ships with the framework, and the official guide walks through the breaking changes. The most common snag is custom Blade views that reached into v3 internals, since the rendering rework changed some of that surface, so budget time to review any heavily customized panels.

For existing v3 apps that are working fine and not under active feature development, there is less urgency. The performance gains and the MFA convenience are the strongest pulls. If you are about to do a meaningful round of admin work anyway, fold the upgrade into that effort rather than treating it as a separate project.

A practical note on the Laravel and PHP floor: Filament v4 targets current Laravel and modern PHP, so make sure your app is on a supported PHP 8.2-or-later runtime before you start. If you have been putting off a PHP version bump, that is the prerequisite to clear first.

The Bigger Picture

Filament has quietly become one of the strongest reasons to reach for Laravel on a project that needs an admin surface. v4 is not a flashy rewrite, it is a maturation: faster where it counts, more consistent in its core abstractions, and more capable in the places teams actually spend time, like rich content and authentication. The point releases through 4.11 mean the rough edges that any major release ships with have largely been filed off. If you bounced off Filament a year or two ago, the version waiting for you today is a different, more polished tool.