Statamic Sentinel 3.0

Sentinel 3 is a major version update because it makes some breaking changes. It drops Statamic 3 and 4, and versions 8.0 and 8.1 of PHP, the language Statamic and Laravel run on. If your site runs Statamic 5 or 6 on PHP 8.2 or later, update with:

composer require d3creative/statamic-sentinel:^3.0

composer update on its own won't move you from 2.x to 3.0, because Composer stays within the major version your composer.json allows.

If you haven't used it, Sentinel is a free addon that checks the software your Statamic site is built from.

It compares your installed versions against Packagist, the npm registry and the Open Source Vulnerabilities (OSV) database, then shows what is outdated or unsafe in the Statamic Control Panel (CP) instead of using the Terminal. It can also email your clients a status report.

A failed check no longer reads as all clear

Sentinel relies on outside services, and outside services go down. In 2.x, some of those failures didn't register within the addon:

• If Packagist or npm was down or rate-limiting during a scan, Sentinel reported 0 updates available. Doh.

• A package-lock.json that npm could read but PHP couldn't counted as missing. The next update report then said every open npm vulnerability was resolved. Whoops.

• A response from the vulnerability database that wasn't a real answer, such as a network error page, read as no vulnerabilities. Argh.

Each of these now shows as a failed check in the CP and in any email reports. The history keeps the previous figures, and php artisan sentinel:scan exits with an error, so a scheduled job or deploy script notices too.

A scan that couldn't check shouldn't look the same as a scan that found nothing.

Status reports that lead with the urgent problem

The status email opens with Statamic's version. In 2.x, if Statamic was up to date, the opening said so and stopped there, even when Laravel had a security update waiting or PHP had reached end of life. Those problems now follow the opening line, each one named:

A security update is available for Laravel. PHP 8.1 has reached end of life.

Reports are easier to read. Each Statamic, Laravel and PHP update is now labelled Patch, Minor or Major, so a routine patch no longer looks the same as a feature release. A security update overrides the label and shows on its own.

Who should stay on Sentinel 2?

Sentinel 3.0 needs Statamic 5 or 6 on PHP 8.2 or later. Support for Statamic 3 and 4, PHP 8.0 and 8.1, and Laravel 8 and 9 is gone.

Statamic 3 and 4 no longer get security fixes. None of the 2026 Statamic security advisories has a fix for either, so a site on them is exposed whatever else it runs. PHP 8.1 lost security support from php.net at the end of 2025.

Sites on those versions stay on Sentinel 2.x. Composer won't offer them 3.0, and 2.x keeps working, but it gets no further releases. Statamic 5 is next in line: its security fixes stop in December 2026.

An older site needs an upgrade before anything else. I handle those as part of Statamic maintenance, or as a new Statamic website when the site has outgrown its design.

Sentinel 3.0 is more secure

Seven of the 24 fixes in 3.0 are about security. Three stop Sentinel hiding a vulnerability it should report, and the other four make Sentinel itself harder to misuse:

1. Packages from a private repository are no longer compared with public packages of the same name. Before, whoever owned that name on Packagist or npm decided the "latest version" Sentinel showed, and could flag a fake security update. A new private_packages config setting covers Private Packagist, Satis and private npm registries, and keeps those names out of the vulnerability lookup.

2. Sites that store users in a database can use Sentinel again. In 2.x, every report, schedule and freeze action returned an error for them, and if the user model had an isSuper query scope, any CP user passed the super admin check instead. Sentinel now checks through Statamic's own users, so only real super admins get through.

3. Emails to your clients always name your site correctly. The update-scheduled email took the site's name from whichever address the CP was opened on, so someone using a faked address could get it into an email to your client. It now always uses the site's configured address.

4. Email previews open in a sandbox where no script can run. Nothing exploitable was found; it's a safeguard.

Lighter and faster

Scans, the dashboard and the Sentinel page all do less work. On a site with a year of daily changes and 100 vulnerable packages, the Sentinel page drops from about 2.5 MB to 0.7 MB. Vulnerability checks for a project with 3,000 npm packages take about 1 second instead of 5.

The Users tab now lists only CP users, which matters on membership sites with thousands of front-end accounts. Content Freeze checks no longer start a background process every minute when nothing is scheduled.

• A full disk can no longer wipe Sentinel's history, notes or schedules. A failed save leaves the previous file in place and reports the error.

• Content Freeze, the feature that tells editors and clients when an update is coming, sends each email once. Sentinel records that it's sending before it sends, so a failed save or a slow mail server can't trigger a repeat.

• On Statamic 6, the freeze banner now updates as editors move between pages, and shows on large pages where it used to go missing.

The full list

There are 24 fixes in this release, and every one is in the changelog. Sentinel shows what needs updating. If you'd rather someone else did the updating, my website maintenance plan covers it. I run the updates, test the site and send you the report.