I built a Filament plugin for runtime collections, custom fields, dashboards, and APIs

I built Filament Studio because I got tired of the same cycle in Laravel projects.

The admin panel starts simple.

Then requirements change.

A client wants a new content type.

Then custom fields.

Then better filtering.

Then dashboards.

Then API access.

Then tenant-specific data.

Then version history.

Then another special case nobody planned for.

At that point, what looked like a straightforward Filament setup turns into more migrations, more models, more resources, more filters, and more maintenance.

That gets old fast.

So I built a plugin for Filament v5 that lets you create and manage data collections at runtime, define fields through the UI, manage records, build dashboards, and expose API endpoints without creating a new table and Filament resource every time the model changes.

The plugin is called Filament Studio.

The problem I wanted to solve

Filament is excellent when the data model is already clear and relatively stable.

But some projects are not like that at all.

You might be building:

• a flexible internal CMS
• a client-specific admin panel
• an operations dashboard
• a multi-tenant back office
• a content platform where structure changes over time

In those projects, the data model is usually the part that keeps moving.

And every change has a cost.

A new content type is not just "add a few fields."

It usually means:

• another migration
• another model
• another Filament resource
• another set of forms and table columns
• another round of filters and policies
• another layer of maintenance

I wanted a way to stay inside Filament while making the admin side much more flexible.

What Filament Studio does

Filament Studio turns Filament into a runtime-configurable data platform.

With it, you can:

• create collections from the admin UI
• define custom fields without writing migrations for each collection
• manage records with generated forms, tables, and filters
• build dashboards with metrics and chart panels
• expose REST API endpoints with API key authentication
• enable versioning and soft deletes
• scope everything by tenant
• control access with policies and permissions
• extend the system with custom field types, panel types, hooks, and schema modifiers

I was not trying to build a toy form builder.

I wanted something that still feels useful when the project becomes real.

Why I chose an EAV-based approach

The core of Filament Studio is an EAV storage model.

Instead of creating a new database table for every collection, the plugin stores:

• collection definitions
• field definitions
• records
• typed values

That gives the plugin room to support runtime schema changes without forcing a migration every time someone adds or edits a field.

I know EAV has a reputation.

Sometimes that reputation is deserved.

But in this case, the tradeoff made sense because I was not trying to model one stable domain perfectly.

I was trying to give teams a flexible way to build evolving admin-managed data systems inside Filament.

The important part was making it practical:

• typed storage columns
• generated Filament components
• useful filtering
• dashboards
• API support
• extensibility hooks
• production-oriented features like tenancy and authorization

What's built in

Filament Studio already includes a lot of what I usually end up rebuilding by hand.

Dynamic collections

You can create collections in the admin panel and define fields visually.

The plugin currently includes 33 built-in field types across categories like:

• text
• numeric
• boolean
• selection
• date and time
• file
• relational
• structured
• presentation

That makes it useful for more than simple text-entry forms.

Dashboard builder

There is also a dashboard builder with 9 panel types, including metrics, lists, time-series charts, bar charts, pie charts, and more.

That matters because once teams have data, the next thing they ask for is visibility.

Advanced filtering

I also wanted filtering to be good enough for real admin use, not just "search one text column."

So the plugin includes:

• a visual filter builder
• nested AND/OR logic
• dynamic variables
• saved presets
• type-aware operators

REST API

Filament Studio can generate REST API endpoints with:

• API key authentication
• per-collection permissions
• rate limiting
• OpenAPI documentation

Production-oriented features

A lot of packages stop at the demo layer.

I wanted this one to go further, so it also supports:

• multi-tenancy
• authorization
• record versioning
• soft deletes
• lifecycle hooks
• schema modification callbacks
• custom field and panel extensions

Who I think this is useful for

I think Filament Studio is most useful for three groups.

Laravel and Filament developers

If you like building with Filament but do not want every new admin requirement to trigger another round of scaffolding, this gives you a more flexible starting point.

Agencies

If you build custom admin panels for clients, this can reduce the amount of repetitive work involved in creating content structures, dashboards, and internal workflows.

Startup teams

If your internal systems and content models are still evolving, runtime collections can be easier to live with than constantly reshaping your app around new admin requirements.

What I wanted the plugin to feel like

I did not want this to feel like a disconnected "builder product" bolted onto Laravel.

I wanted it to still feel like it belongs in a Filament application.

That meant:

• native-looking forms and tables
• sensible extension points
• support for real authorization models
• room for custom field types and custom panels
• documentation good enough that people can actually adopt it

I also spent time on screenshots and docs because I think open-source packages need to earn trust quickly.

If someone lands on the repository, they should immediately understand what the plugin does, what it looks like, and whether it is serious.

Why I'm sharing it now

I am sharing Filament Studio because I think it fills a real gap in a certain kind of Laravel project.

Not every app needs runtime-defined collections.

But when a project does need flexibility, the usual alternatives are messy:

• keep hardcoding every change
• overbuild a custom internal CMS
• stitch together several tools
• give up on having a clean workflow inside Filament

I wanted a better option.

If this sounds useful, I'd love feedback

If you work with Laravel and Filament and this solves a problem you've run into, take a look:

• GitHub: https://github.com/flexpik/filament-studio
• Packagist: https://packagist.org/packages/flexpik/filament-studio

If it looks useful:

• star the repo
• try it in a project
• tell me what you'd build with it
• tell me what feels missing

The most useful feedback at this stage is not just "looks nice."

It is "this would help me build X" or "I would need Y before using it."

That kind of feedback is what makes open-source tools better.