Update notifications for a Laravel CMS

On a WordPress site, a new version announces itself: a number on Dashboard → Updates, a red line under a plugin, an email when a security release went in by itself. A Laravel site has none of it. Its code came in through Composer, and the only way to learn that a newer version exists is to run composer outdated or to read a changelog — which nobody does on a site that works. A release that closes a security hole waits on the shelf until someone happens to look.

kitloom is installed the same way, and it keeps Composer in charge of the code: no button rewrites vendor on a live server. What it adds since 1.16.0 is the part WordPress gets right — the site knows, and says so where its administrators look. That is kitloom/updates, on every site, in both admins.

What the administrators see

• Updates in the admin: the version the site runs, every release since then with its date, a summary and a link to its entry in the changelog, and the command that takes the site there. A release that fixes a security hole is in red, and so is the page's headline: kitloom 1.17.1 is out and fixes a security hole. You run 1.16.0. A new major version says first which constraint to change in composer.json.
• A badge on the menu with the number of releases waiting — red when one of them is a security release. It is read from the cache, so it costs nothing on every page.
• Check now, for the day a release is announced. Otherwise the site asks twice a day on Laravel's schedule, at a minute and an hour of its own; a site without cron asks when an administrator opens the screen and the last answer is a day old.

Who sees all this is a permission, See which kitloom releases are out — WordPress's update_core — which administrators hold. Give it to another role on Users → Roles.

A message in Telegram, Slack or email

With Notifications, kitloom update is a topic of the owner's channels — Telegram, Slack, Discord, Teams, Pushover, browser push or email — ticked on a new channel. Each release is told once: its version, with a security fix in the title when it has one, what changed, and the command. So a security release reaches whoever looks after the site without anyone opening the admin. Untick it on a channel to see releases only on the screen.

In the console, a CI job and an AI agent

php artisan kitloom:updates            # the same as the screen
php artisan kitloom:updates --refresh  # ask now
php artisan kitloom:updates --json     # for a script

The command exits with 1 while a security release waits, so a CI pipeline or a cron mail can fail on it. An AI agent connected over MCP reads the version and what waits in describe_site; it cannot update the site, which needs Composer on your machine.

What the site sends

A check is one request to updates.kitloom.dev, with four values in its headers:

kitloom's version	1.16.0
PHP's version, without the patch	8.4
The edition: the admins the site has	Filament, Nova, Both, None
A random id the site made for itself	3f6c1a0e-…

Nothing else: not the site's address, not its modules, themes, users or content. WordPress's own update check names the site in its user agent and sends the list of its plugins; kitloom's does neither. The id is drawn from nothing about the site, so it says only "the same site as last time" and lets kitloom count sites once rather than twice a day. On our side the server keeps no IP address, and an id not heard from for 90 days is deleted — the privacy policy has the whole of it.

On a closed network, one line in .env turns it off, and the screen links to the changelog instead:

KITLOOM_UPDATE_CHECK=false

A server that may not reach out can ask a mirror: KITLOOM_UPDATE_FEED=https://….

Watch it

The Updates screen: what is out, what changed, and how to update

Try it

Every detail — the switches, the schedule, the mirror, a staging copy with an id of its own — is in the Updates guide. The rest of kitloom is a click away in a sandbox, with no sign-up: Filament or Nova.