Lift turns Eloquent model configuration into PHP attributes

The model configuration moves onto the property it describes

The problem Lift addresses is visible in any Laravel codebase with more than a couple of fields. A model's fillable list lives in one array, its casts live in another array, and its validation rules often live in a third place entirely, sometimes a Form Request class in a different directory. The three lists then have to be kept in sync with each other by hand, and nothing in the type system stops a renamed property from silently dropping out of the fillable array. Lift's answer is to put the configuration next to the property. The project's own description is that it takes your Eloquent Models to the next level, and the mechanism is PHP attributes on typed public properties. The metadata stays in the model class, where a reader editing a property is looking at the same file, and the property keeps a native type declaration.

Three attributes carry the fillable, cast and rules information

The published example shows a model with two properties, a string name and an integer stock, each carrying a Fillable attribute and a Rules attribute, and the stock property carrying a Cast attribute as well. The attributes live in the WendellAdriel\Lift\Attributes namespace, with Cast, Fillable and Rules imported alongside the Lift trait itself. The trait is what wires the attributes into the model, and it is applied with a plain use statement inside the class body. The rules use Laravel's own rule syntax, with a required, string, max:255 list for the name and a required, integer, min:0 list for the stock, so the validation vocabulary is not a new one you have to learn. The Cast attribute takes the cast name as a string, in this case 'integer', which is the same vocabulary Eloquent's own cast array uses. Nothing here invents a parallel configuration format.

Lift applies the configuration through model events

The sentence that explains how it works is short: Lift reads those attributes and applies the matching Eloquent configuration through model events. This matters, because it is the reason Lift can be a trait rather than a replacement model class. A trait is mixed into a model that extends Illuminate\Database\Eloquent\Model, so the model keeps being an ordinary Eloquent model, and the configuration is pushed onto it at the right point in the model lifecycle rather than being described by a separate declaration. The stated benefit of that design is that it keeps model behavior close to the property it describes while still using standard Eloquent models. The practical consequence for an adopter is that nothing about how the model is queried, saved or serialised changes. What changes is where the metadata is written down.

Installing it is one Composer command on an existing Laravel app

The package is installed through Composer, which means it lands in the dependencies of an application that already has a Laravel setup:

composer require wendelladriel/laravel-lift

After that, the work is to add the Lift trait to the models that should use typed public properties and Lift attributes, and to import the attributes you intend to use. The documentation site is at laravel-lift.wendelladriel.com, and the README is explicit that the full documentation lives there rather than in the repository. The documentation itself is a separate concern, built with VitePress, since the repository carries a package.json whose only scripts are docs:dev, docs:build and docs:preview running vitepress against the docs directory. The presence of a separate Node toolchain for a PHP package is a small signal about how the project is organised, and it also means the docs can be read or rebuilt locally without a PHP environment.

The project labels itself experimental, and that label is the first fact

The README opens with a callout that reads This is an experimental package, and that sits above everything else including the banner. It is unusual to see that stated this prominently, and it should shape how you read the rest of the project. The version numbers support the same reading. The recent releases are v0.19.1 on 2026-06-04, v0.19.0 on 2026-06-01 and v0.18.0 on 2026-02-25, so the package is still in the zero series and moving quickly, with two releases three days apart in June. The repository is not archived, and the last push was on 2026-10-16, so the code is being worked on. An experimental package with an active maintainer is a reasonable thing to try on a side branch, and a questionable thing to put at the centre of a production model layer on a release you cannot pin.

The repository shows the tooling expectations around the code

Beyond src/ and tests/, the top level carries the tools that keep a PHP package honest. phpstan.neon is there, so static analysis is configured for the package itself, and pint.json points at Laravel Pint, the formatter that follows the framework's own style conventions. phpunit.xml and the tests directory hold the test suite, and an ide.json file is present, which is the kind of file an editor reads to know where generated or framework-specific classes live. composer.json holds the package metadata, and the docs directory is the source of the documentation site. A .github directory carries the workflow that the README badges point at, along with the SECURITY.md file that the README tells contributors to consult for how to report a security vulnerability, and a CONTRIBUTING.md with the contribution guide. There is also a .editorconfig, so formatting is not left to individual editors.

Where Lift is the wrong tool

The clear case against it is a codebase whose models are already configured, and configured carefully. If your models have a custom base class, or a boot method that sets fillable and casts from an array, or a trait of your own that owns validation, then Lift is a second voice speaking about the same configuration. Because Lift applies its settings through model events, the order of those events relative to your own boot logic determines what actually ends up on the model, and that is the kind of subtlety you want to avoid in a shared model layer. A second limit is scope. The published example demonstrates three attributes, Fillable, Cast and Rules, and the documentation site is where the full set lives, so a feature you need may not exist yet in the version you install. Third, the attributes approach is not a substitute for the framework's own facilities. If your validation is already handled by Form Requests and your casts are already declared, Lift adds a parallel declaration rather than removing one. A reasonable middle path is to use it on new models in a package you own, where the pattern is consistent and the blast radius of a mistake is one class.

Editorial conclusion

Adopt Lift on a Laravel codebase that already uses PHP attributes and wants model configuration to sit beside the properties it describes, and treat it as a prototype because the project labels itself experimental. Skip it if your models rely on a custom base class or a boot method that already owns the fillable, cast and validation wiring, since Lift applies its configuration through model events. Verify first which attributes your installed version supports, because the published example only demonstrates Fillable, Cast and Rules, and read the changelog before upgrading across a minor version.

Frequently asked questions

Official sources

1. License: MIT
2. Project website
3. README
4. Releases
5. WendellAdriel/laravel-lift on GitHub