laravel-dashboard: the base pieces of a dashboard for Laravel

What the package is

The readme's promise is a beautiful dashboard for a Laravel application, and then the second line explains what that means in practice: the dashboard consists of tiles which are, under the hood, Livewire components that can update themselves via polling.

That sentence is the whole design, so it is worth unpacking it before anything else. A tile is not a picture of a chart. It is a live component with its own state, mounted somewhere on a page, that can refresh its own data without the page being reloaded and without the rest of the page being redrawn. The consequence is that a dashboard made of these is not a page that was generated once, it is a set of independently updating regions on a page.

And then the list of what the package actually contains, which is short enough to quote in full because it explains the whole approach.

There is the base CSS. There is a dashboard view component. There is a tile view component whose stated job is to position stuff on the dashboard. And there is a tile model, whose stated job is to persist fetched data that tiles can use to store fetched data.

That is four things, and three of them are infrastructure rather than content. What is not in the list is any particular tile: no server monitoring, no queue depth, no user chart. The package is the frame, and the tiles are yours.

That is a coherent choice, and it is the choice that distinguishes a package from an application. The pieces that every dashboard needs are the pieces that are boring to write and easy to get slightly wrong: the layout, the positioning, the mechanism for a region to refresh itself, and the persistence for the data it fetched so that two tiles showing the same thing do not each fetch it. The content is the part that differs per team, and it is left out on purpose.

The package is MIT licensed, the documentation lives on the vendor's own documentation site, and the release history shows the shape of a project with a major version bump roughly annually and patch releases in between, with the most recent major in the spring of 2026.

Four pieces, and what each one is for

The four pieces are worth separating, because the division of labour between them is the design.

The dashboard view component is the page itself. It is the thing you include once, and it establishes the frame: the page structure, the grid, the containers that tiles are placed into.

The tile view component is the positioning piece, and its description says so in one phrase: to position stuff on the dashboard. So a tile is a box on the page with a place in the layout, and the thing inside it is your own Livewire component. That separation is what lets the package stay small while the tiles get as specific as you like. The vendor owns the geometry and you own the content.

The tile model is the third piece and it is the one that is easiest to overlook. It persists fetched data, and the phrasing is interesting: the model is what tiles use to store fetched data. So a tile that has gone and collected something writes it to this model rather than holding it only in memory, and that stored value is available to other tiles and to later requests.

That is a small feature with a large effect on a dashboard, and the effect is about the polling. Tiles update themselves, so several of them will often want the same underlying number. Without persistence, each tile that wants the count of queued jobs fetches it, and the server does the work once per tile per interval. With a model to hold it, the work is done once and the tiles read the stored value.

The fourth piece is the base CSS, and it is worth noticing that the package ships a stylesheet rather than leaving the appearance entirely to you. A dashboard that every application styles from scratch is a dashboard that looks like every application, and the point of a base stylesheet is that the tiles your team writes look like they belong next to the ones somebody else wrote.

So the four pieces map onto the four things a dashboard does: it has a page, it has places on that page, it has values that outlive a request, and it has a look. The tiles connect them, and the tiles are Livewire components that poll.

The styles, and how they are built

The asset pipeline is described in the package manifest, and it is short enough to be worth reading closely because the versions say something.

The package is marked private, which means the manifest is not published to a registry; it exists to build the styles and to hold the development dependencies for that build. There are two scripts. One formats the stylesheet source with a formatter and writes the result. The other compiles a single stylesheet through a processor and writes a minified version into the distribution directory of the package.

The dependencies behind those two scripts are the current generation of the tooling: a utility framework at version four, its processor plugin, the processor itself with its command line tool, a minifier, and the formatter. The build is therefore a modern utility-first pipeline rather than a hand-written stylesheet, and the output is one minified file that the package ships.

And here is the tension worth naming, because both statements appear in the sources. The readme lists the base CSS as one of the four things the package provides, and the manifest shows that the CSS is compiled from a utility framework through a processor. Those are not contradictory, but they are two different philosophies sitting next to each other, and which one is in force tells you what a using application should expect.

If the stylesheet is hand-written, then the package's job is to give you a coherent visual language and you adopt it as it is. If the stylesheet is compiled from a utility framework, then the package is giving you a design system's tokens and utilities, and your application's own styles are compiled through the same pipeline, which means the two are in the same system and cannot drift apart.

The second reading fits the rest of the package better. A dashboard is a component library in effect, and a component library whose styles are compiled with the consumer's own styles is one that stays consistent with the application it is embedded in, rather than one that has to be overridden.

And the practical detail for a using team is that the stylesheet has to be built. It is not a file that appears by itself; the build script has to be run and the result published with the package, which means a consuming application has to make sure its own pipeline knows about that file, or it will find the dashboard rendering without its styles.

The repository, and what an upgrade guide implies

The repository layout is that of a well-run package, and a couple of the entries tell you more than the readme does.

There is a source directory and a resources directory, which is where the styles and the views live, and a configuration directory and a database directory, the latter holding the migration for the tile model. There is a tests directory, a static analysis configuration, and a test configuration for the unit test runner. There is a documentation directory, which means the documentation site is built from this tree rather than kept somewhere else.

Two files at the root are worth a paragraph each, and the second one is the interesting one.

The change log is the conventional one, and it is pointed at from the readme with the customary invitation to look at it for what has changed recently.

And then there is a separate upgrade guide. A change log tells you what happened; an upgrade guide tells you what to do. Having both, with the upgrade guide at the root next to the change log rather than buried in the documentation site, is the convention of a package whose users upgrade across a major version boundary and need to be told, in one place, what has to change in their application code.

Given that the release history has a major version this year, that file is going to be read by somebody. Having it as a separate top-level document, rather than as a section of the change log, tells the reader that the difference between the two is deliberate.

The rest of the top level is the toolchain: a configuration for the editor, a file of attributes for line endings, a linting configuration for staged files, and an ignore file. The staged-files linting is the usual pattern, where a commit hook runs a formatter over the files in the commit rather than over the whole project, which is faster and which catches the things that are about to be committed.

And the contributing guide points at a shared repository, so contributions go through the same process as the vendor's other packages, which is a sensible arrangement and explains the presence of a single contributor's name in the credits alongside a link to the full list.

How the project is funded, and how to report a problem

The readme spends a section on support, and it is worth reading as a document about how a small open source project sustains itself.

The framing is that the vendor invests a lot of resources into creating open source packages, and that you can support that by buying one of the paid products. So the package is free and the business is elsewhere. That is a coherent model, and it is worth being clear about what it means for a user: the package itself carries no obligation, and the paid products are the point.

Then there is the postcard request, which is unusual enough to be worth describing exactly. The readme asks for a postcard from the sender's hometown, mentions which of the packages is being used, gives a postal address, and publishes every received postcard on a virtual wall.

It is a small thing, and it is a genuinely nice piece of community building: the wall is public, so a package that is otherwise invisible in a large dependency tree becomes something a person can look at, and the sender gets a physical acknowledgement that they did not have to pay for. For a project whose audience is developers who would never otherwise write a letter, this is an unusually effective way to get a signal that people use the thing.

The security section is short and it is the one every using organisation should read. If you have found a bug regarding security, mail the address rather than using the issue tracker.

That single sentence is a well-judged policy. A public issue tracker is the wrong place for a vulnerability report because the report itself becomes public, and a dashboard package is a component of somebody's application, often with access to operational data. Routing security reports to an address means they are handled privately, and the readme makes it the first thing somebody looks for rather than a footnote.

The credits list the package's author and a link to the full contributor list, and the licence is MIT with the file to read for the details.

Editorial conclusion

laravel-dashboard fits a Laravel team that wants to build an internal operations view for themselves and does not want to invent the layout, the positioning and the polling. It does not fit somebody who expects a finished dashboard with charts, because what is in the package is the base rather than the tiles. Verify first that your Livewire version is the one the tiles are built against, since the polling behaviour lives in those components, that the stylesheet is built as part of your asset pipeline rather than assumed to be published, and that you read the upgrade guide for the major version you are moving to, since the repository keeps one alongside the change log for exactly that purpose.

Frequently asked questions

Official sources

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