# dashboard.spatie.be is one office dashboard published as open source > The dashboard.spatie.be repository is the source of a real-time company dashboard built with Laravel, Livewire-era Vue and websockets, with tiles for a Twitter stream, the clock and weather, the team, Packagist downloads, internet throughput and a local bike sharing service. It is tailormade for a wall mounted television, it does not follow semantic versioning, and it is offered as-is. **spatie/dashboard.spatie.be** — The source code of dashboard.spatie.be - Repository: https://github.com/spatie/dashboard.spatie.be - Website: https://freek.dev/1645-building-a-realtime-dashboard-powered-by-laravel-livewire-and-tailwind-2020-edition - Stars: 1,955 · Forks: 410 - Language: PHP - License: MIT - Published: 2026-10-16 · Updated: 2026-10-16 · Language: en - Canonical page: https://hysenlabs.com/projects/spatie-dashboard-spatie-be ## A specific dashboard for one wall This repo contains the source code of our dashboard, and the readme is unusually clear about what that means. This dashboard is tailormade to be displayed on the wall mounted tv in our office. We do not follow semver for this project and do not provide support whatsoever. However if you're a bit familiar with Laravel and Vue you should easily find your way. That is a refreshing thing to read in a repository readme. There is no pretence that this is a framework, a starter kit or a product. It is one dashboard, in one office, published so that other people can look at it, copy the interesting parts and run their own. The two warnings are both real. Without semantic versioning, a pull request against it is a request to work with a codebase that may change under you. And without support, if you fork it you are on your own, which is a reasonable position for an internal tool and an unusual one for something with this much attention in the readme. The implementation is PHP with a Laravel application, the front end is Vue, and the topics list laravel, laravel-echo, pusher, websockets and vue, which describes the realtime path: the server pushes events over websockets and the browser updates without polling. The licence is MIT, and the project and the Laravel framework are both open-sourced software licensed under the MIT licence. The last push was on 2026-10-12 and the repository has no GitHub releases, which is consistent with the no-semver policy. ## The tiles are a portrait of a small company The example section lists the tiles the configured dashboard has, and the list is more revealing than a feature list would be. There is a Twitter stream with all tweets mentioning and quoting the company's handle, so the wall shows what people are saying about it in real time. There is a clock, date and weather tile. There is a team tile with to dos via GitHub files, remote status via Slack, and current tracks via Last.fm, so the wall shows who is working on what and what they are listening to. Then there is a Packagist downloads tile, which shows the download counts of the open source packages the company publishes, and an internet up and down tile measured over websockets, which is the classic office bandwidth graph. The last one is a Velo status tile, a local bike sharing service in Antwerp. So the dashboard is not a monitoring console. It is a status board for a small software company, showing how the day is going, and the tiles are chosen for things that are worth looking at from across a room. That is the design constraint behind everything else, and it explains why the project was worth writing about at all. A wall display is read at a distance, in passing, so the information density and the contrast of the tiles matter more than the density of the data. ## How the realtime path works The How it works section points at a talk rather than at a diagram. Freek Van der Herten gave a talk on the dashboard at Laracon EU where he explained how the dashboard works behind the screens. The talk was recorded and published on Youtube. That is a useful pointer for anybody taking this apart, because the interesting part of a dashboard like this is the wiring. The environment file shows the shape of it. There is a BROADCAST_DRIVER of pusher, a CACHE_DRIVER of file, a SESSION_DRIVER of file and a QUEUE_DRIVER of sync, and there are PUSHER_APP_ID, PUSHER_APP_KEY and PUSHER_APP_SECRET for the websocket service, plus a REDIS_HOST, REDIS_PASSWORD and REDIS_PORT that suggest a cache and a queue in front of the application. The installation instructions confirm the shape. You start your queue listener and set up the Laravel scheduler, and then you open the dashboard in your browser, log in and wait for the update events to fill the dashboard. So the tiles are filled by scheduled jobs that push events, and the browser is a passive display. That is a different architecture from a dashboard that queries on load, and it is the one that makes a wall display cheap: the expensive work happens on a schedule, and the browser just renders what was pushed to it. ## Installing it is a normal Laravel setup Install this package by running cloning this repository and install like you normally install Laravel, and the steps are the ones you would expect for a Laravel application with a front end build. ```bash composer install npm install yarn ``` Then run yarn and yarn run dev to generate the assets, copy the .env.example to .env and fill in your values, which means the application key with php artisan key:generate, the database, and the Pusher values. Then run php artisan migrate --seed, which seeds a user based on your BASIC_AUTH .env values, so the login is created for you. Finally, start your queue listener and set up the Laravel scheduler, then open the dashboard in your browser, log in and wait for the update events to fill it. The front end build has moved on since the original article this project is based on. The package manifest shows Vite as the bundler, with the laravel-vite-plugin, and Tailwind CSS at version 4 with the Tailwind Vite plugin, and the two runtime dependencies are stringz and twemoji, the latter being the emoji rendering for the Twitter tile. The article the readme links, building a realtime dashboard powered by Laravel, Livewire and Tailwind from 2020, is the original write-up, and it is where the design reasoning lives. The homepage field of the repository points at the same article. ## Deployment, and the automation around it The site runs on Laravel Cloud and deploys automatically when pushing to main, which is a very short deployment section, and it says more about the project than a longer one would. The push-to-deploy model is possible because the repository is a complete application rather than a library, so there is nothing to publish to a package registry and nothing to version. The main branch is the deployment. The repository shows a modern Laravel application layout, with the app/ directory, bootstrap/, config/, database/, resources/ for the views, routes/, storage/, tests/ and public/, plus the artisan file, composer.json and composer.lock, a vite.config.js and a package.json, and a phpunit.xml for the tests. There are a few files that suggest the project is worked on with tooling rather than only by hand. There is a boost.json, a .mcp.json, a CLAUDE.md, an .idea-free but present .vscode-style set of editor configs with .eslintrc, .prettierrc, .prettierignore and .styleci.yml, a .php_cs file for the PHP code style, and a .editorconfig. The docs/ directory is there for the project documentation, and the LICENSE file and readme.md sit at the top alongside the .env.example, which lists the whole set of credentials the tiles need. ## The environment file is the real specification The .env.example is the most revealing file in the repository, because it lists everything the dashboard talks to. The application settings are the standard Laravel ones, with APP_ENV, APP_KEY, APP_DEBUG, APP_LOG_LEVEL and APP_URL. The infrastructure is SQLite for the database by default, pusher for broadcasts, file for cache and sessions, and sync for the queue, which is a sensible default for a local run and a queue driver you would change in production. Then there are the credentials, grouped by the tile they serve. The Twitter tile needs a consumer key, a consumer secret, an access token and an access token secret. The GitHub tile needs a token, a webhook secret and a username. The Slack tile needs an app token. The weather tile needs an OpenWeatherMap key, and a second one for the climate API. The team tile needs a Last.fm API key, a Google Calendar ID, a Packagist vendor name, a Spatie API token, a Flare key, an access token, and a pair of latitude and longitude for the Bui en radar location. The Velo tile needs a list of station identifiers, and the now playing webhook needs a secret. Two things follow. The number of external services a dashboard like this depends on is large, and every one of them is a place where a change of API can break a tile. And the file itself is a good checklist of what a similar project would need to obtain before it works. ## Postcards, sponsors and a small company being visible Two sections of the readme are about the company rather than the software, and they are worth a paragraph because they tell you who maintains this and why it exists. The Support us section asks you to buy one of their paid products, and it is honest about the reasoning. We invest a lot of resources into creating best in class open source packages, and the dashboard is where some of that money comes from. The postcard section is the famous one. They highly appreciate you sending us a postcard from your hometown, mentioning which of our packages you are using, and they publish all received postcards on their virtual postcard wall. The Postcardware section repeats the request for anyone using the dashboard, gives the address in Antwerp, and links to the wall. So the dashboard is partly a statement. It is a demonstration that the packages the company publishes are used by the company itself, it is the background of a talk at a Laravel conference, and it is the thing on the wall in the office where the postcards come from. For a technical evaluation that context matters, because it explains why a project with no releases and no support is published at all, and why the code is in the shape it is. ## Conclusion Adopt this repository as a reference for a real-time dashboard, since it shows the whole stack of a working example, from the queue workers and the scheduler to the websocket layer and the front end build. Do not adopt it as a dependency, because the readme is explicit that it does not follow semantic versioning and provides no support whatsoever, and it is written for one office and one screen. Verify first which external services the tiles need, since the environment file lists a long list of API keys for Twitter, GitHub, Slack, Pusher, Last.fm, Google Calendar and several weather services. ## FAQ ### What is the dashboard.spatie.be repository? It contains the source code of the Spatie dashboard, a real-time company dashboard built with Laravel and Vue, showing tiles for a Twitter stream, clock, date, weather, team status, Packagist downloads, internet throughput and a local bike sharing service. The licence is MIT. ### Does the project follow semantic versioning? No. The readme says the dashboard is tailormade to be displayed on the wall mounted tv in their office, that they do not follow semver for this project, and that they do not provide support whatsoever. ### How do I install the dashboard? Clone the repository and install it like a normal Laravel application: run composer install and npm install yarn, generate the assets with yarn and yarn run dev, copy .env.example to .env and fill in the values including the application key, the database and the Pusher values, then run php artisan migrate --seed, which seeds a user from your BASIC_AUTH values. Finally start the queue listener and set up the Laravel scheduler. ### What does the dashboard need from external services? The .env.example lists credentials for Twitter, GitHub, Slack, Pusher, Last.fm, Google Calendar, Packagist, Spatie, Flare, an access token, OpenWeatherMap, a climate API, a now playing webhook and coordinates for a weather radar service. ### How is the dashboard deployed? It runs on Laravel Cloud and deploys automatically when pushing to main, so the main branch is the deployment and there is no package to publish or version. ### What front end stack does the dashboard use? Vite as the bundler with the laravel-vite-plugin, Tailwind CSS version 4 with the Tailwind Vite plugin, and two runtime dependencies, stringz and twemoji for the emoji rendering in the Twitter tile. The original article it was built from is the 2020 edition of a Laravel Livewire and Tailwind write-up. ## Sources - [Issues](https://github.com/spatie/dashboard.spatie.be/issues) - [License: MIT](https://github.com/spatie/dashboard.spatie.be/blob/main/LICENSE) - [Project website](https://freek.dev/1645-building-a-realtime-dashboard-powered-by-laravel-livewire-and-tailwind-2020-edition) - [README](https://github.com/spatie/dashboard.spatie.be/blob/main/README.md) - [spatie/dashboard.spatie.be on GitHub](https://github.com/spatie/dashboard.spatie.be) --- Hysen Labs editorial analysis, written from the project's own repository and release notes. Cite the canonical page: https://hysenlabs.com/projects/spatie-dashboard-spatie-be