Spotlight FilamentPHP Version 4 — What to Expect

Note: Most of this information is taken from the official FilamentPHP "Bright Ideas" podcast, in order to work with as much official information as possible. As version 4 is not released yet, things can still change!

Unified Architecture with the New “Schema” Core

One of the biggest changes in v4 is a unified architecture for Filament’s packages. The core team is introducing a new internal package called Schema that will act as a foundation for forms, tables, widgets, and other components. In Filament v3, similar UI elements (like layout components for forms vs. info lists) were implemented separately; in v4 these are being consolidated into single classes for better consistency and maintainability. This means you can mix and match components (forms, info lists, tables, widgets, etc.) more freely on the same page without the old hurdles. As Filament creator Dan Harrin explains:

the whole idea is that we are trying to unify all of the packages so that they can be combined in ways that were much more difficult to do before

Developers will be able to include a form, an info list, a widget, and a table all in one view and arrange them as needed, which previously required hacking around the panel’s default layouts.

Flexible Page Layouts and Schema Components

Filament v4 will make it much easier to customize page layouts in your panel. Currently, if you want to change how a built-in resource page is structured, you often have to publish Blade view files and tweak HTML (which you really shouldn't do!). In v4, you can override a page’s structure through a schema content method right in the PHP page class, without manually copying view files. Essentially, Filament is introducing a page schema that works similarly to how form layouts are defined (using sections, grids, tabs, etc.), but at the page level. You could, for example, move a relation manager or reorder panels on a resource’s edit page just by adjusting the schema in code. This approach keeps layout customization in PHP and avoids having to maintain separate Blade templates.

Filament’s set of layout components (such as Section, Grid, Tabs, Wizard, etc.) will also live in the new Schema package and be usable across all areas of the admin panel. In practice, this means the same section or grid component can wrap fields in a form or items in an info list or a custom page. Actions are also being unified: instead of separate action classes for forms, tables, and widgets (which was a pain point in v3), v4 aims to provide a single action class that works everywhere. This should eliminate the confusion of importing “5,000,000 different” action classes from various namespaces and make it easier to reuse actions across Filament features.

Streamlined Resource Structure and CLI Improvements

FilamentPHP v4 brings a more organized structure for resources and a smarter CLI to boost developer productivity. In v3, a resource (like UserResource) lives in a file separate from its folder of page classes. V4 restructures this so that each resource gets its own directory (e.g. a Users/ folder containing UserResource.php, plus subfolders for pages, form schemas, table schemas, etc.). The resource class will reside alongside its related classes, making the codebase more intuitive to navigate. For example, you might have Filament/Resources/Users/UserResource.php, with Users/Pages/EditUser.php and Users/Schemas/UserForm.php in the same folder tree. This co-locates all parts of a resource and makes them feel “close together and portable”.

To encourage reuse and cleaner code, v4’s generator (artisan make:filament commands) will by default extract form and table definitions into their own classes. When you generate a new resource, Filament can create a Form schema class and Table class under a Schemas directory for that resource, each with a simple configure() method that returns the schema definition. Your resource’s page classes then just import and use those schemas in one line. This optional separation means you can define a form once and easily share it between a resource’s create page, edit page, or even other resources and relation managers. It’s an opinionated approach to structure that the core team believes is the “right way” to handle shared forms/tables going forward. However, if you prefer the old inline style (defining fields in each page class), you can disable this new structure via configuration. Dan emphasizes that these changes are backwards-compatible and intended to make upgrades easier, not harder:

If people [upgrading] from version 3 to version 4 won’t want to use the new location at least initially… I don’t want that to be a blocker. This is completely backwards compatible… you can use a mixture if you wanted to.

Nested Resources

Another requested capability landing in Filament v4 is nested resources (having resource pages nested under a parent resource’s context, like /projects/{project}/tasks). In the past this required community workarounds or a plugin, but Filament v4 will support nested resource definitions out of the box. You’ll be able to declare a resource as “nested” under another, and the framework will handle routing and breadcrumbs accordingly. This feature was under active development through 2024 and is expected to greatly simplify building master-detail interfaces in Filament apps.

Major Performance Boosts and Semantic CSS

Performance has been a focal point in v4’s development, especially for data-heavy panels. One headline improvement is faster table rendering. Filament’s table builder in v3 was elegant but could bog down with large datasets or many columns, due to deeply nested Blade components. In v4, the team aggressively refactored tables to render with far fewer Blade components. Many of the per-cell Blade view files have been replaced by PHP logic that generates raw HTML, eliminating overhead without altering functionality. As a result, “tables are now rendering about twice as fast” in v4 according to Dan’s measurements. This is a big win for apps that need to display hundreds of rows or dozens of columns. Even actions and selection checkboxes within tables have been optimized to minimize extra rendering cost. While this approach sacrifices a bit of Blade “best practice,” the payoff is snappier UIs when dealing with large tables.

Performance is further boosted by Livewire partial rendering support. Filament v4 takes advantage of a concept called “partial component rendering,” meaning only parts of the page update when something changes, instead of a full re-render. The Filament team worked on a Livewire proposal to allow this and have baked a solution into v4’s new schema system. For example, if updating one form field needs to refresh another component on the page, v4 can re-render just that specific component rather than the entire page. This granular update capability will make interactions feel faster, especially on pages with lots of fields or when using features like deferred searches and filters. Combined with the table optimizations, partial rendering means filtering or paginating a table in v4 sends a lot less HTML over the network. All these enhancements add up:

hopefully you’ll see a large improvement, especially if you opt in to a lot of these new settings… to help with those large data sets and the clients that want to see 200 records on one page

Another behind-the-scenes enhancement is a revamped CSS strategy. Filament v4 is moving away from outputting lengthy Tailwind utility classes in every HTML element. Instead, Filament will ship with its own compiled CSS classes (using Tailwind’s [@apply]) for common component styles. This means the HTML sent over the wire is leaner (fewer repetitive class strings) and you won’t need to include Filament’s views in your Tailwind configuration for purging. The team has been systematically “removing Tailwind classes from the views and actually putting them in CSS files under semantic class names”. Not only does this slightly reduce payload size, it also lays groundwork for easier theming and ensures consistent styling across components. In fact, once refactoring is complete, Filament v4 will not require your app to scan its views for Tailwind classes at all – making installation and builds a bit faster. Modern CSS features are embraced too: Filament is using OKLCH color space to derive accessible color variants and has begun adopting CSS Container Queries to improve responsive behaviors in the UI.

New Features

Email Change Notification

Beyond architecture and speed, FilamentPHP v4 introduces several quality-of-life features. A great example is improved built-in authentication workflows. Filament has its own auth system, and v4 is making it more secure and user-friendly without extra coding on your part. One new option is email change verification for users. If enabled, when a user updates their email address, Filament will not immediately change it in the database. Instead, it will send a confirmation link to the new email and a notification with a cancellation link to the old email. Only when the new address is verified (and the old one hasn’t blocked it) will the change go through. This feature — inspired by how big apps handle email changes — adds a layer of security against account takeover. Importantly, Filament implemented this without requiring any extra database tables; it uses signed URLs and temporary cache storage to track pending changes. It’s a perfect example of Filament doing the tedious work for you.

Two-factor authentication

Developers will be able to require users to set up at least one 2FA method by default, but users won’t be forced through all possible methods during login. If multiple 2FA providers are enabled (e.g. authenticator app, SMS, etc.), the user can choose their preferred method when signing in. On the implementation side, the 2FA setup interface has been built using the new schema components. Dan says

Now I’ve refactored it so that there are only schema components and everything in that [2FA setup] modal is now a schema component

The UI for two-factor setup can leverage forms, lists, and even new pre-built components (like a nicely formatted recovery codes list with one-click “copy” actions). This not only provides a smoother setup flow out of the box, but it also serves as a reference for developers on how to build custom modals and flows with the schema system.

Static Data Tables

Yes, you can (finally!) use the Table Builder with static data sources. For example, you can call any API and display its data without having to implement it with an eloquent model. Dan said that not all features of the Table Builder will be available, since some rely heavily on being in the database with eloquent models, but all the basic features should be possible.

Preparing for Filament v4

The team is overhauling documentation to cover all these new paradigms and ensure developers can transition to v4 smoothly. Notably, Filament’s creators have expressed that v4’s design is intended to be a long-term foundation. It’s such a thorough rework that Dan half-jokingly said they might “not ever need a Filament v5 after these changes”, calling v4 “an ultimate implementation” of their vision. While software always evolves, it’s clear the goal is to make Filament v4 a stable, future-proof framework.

FilamentPHP v4 is slated to launch soon (the team targeted mid-2025). Thanks to the backward-compatible design of new features, you won’t be forced to rewrite your entire application to get started on v4. The philosophy has been “minimal breaking changes” wherever feasible. In other words, your Filament v3 app should mostly work on v4 (espacially if you haven't published and edited the filament core blade views).
There will also be an upgrade script again, just like the one from v2 to v3.

If you havn't tried Filament yet and want to know why I think it's awesome, you can do that right here. Finally, I'm very excited about v4 and will have more to say about it on my blog soon.