spatie/laravel-backup takes zips of your directories and leaves the restore to you

One zip file of your directories plus a database dump

The unit of work is a single zip file. It contains every file in the directories you specify, together with a dump of your database, and it is written to any of the filesystems you have configured in Laravel. That is the whole mechanism in one sentence, and the command that produces it is one line:

php artisan backup:run

Because the destination is a configured Laravel filesystem rather than a hardcoded path, the package is not tied to local disk. The README also makes the paranoia case explicit: you can back up your application to multiple filesystems at once, which is the documented answer to keeping copies in more than one place. The trade-off follows from that design. The package sees what the application sees, so the set of files in the archive is the set of directories you configured, and a directory you forgot is a directory nobody backs up.

Nothing in the documented flow verifies that the zip can be opened. What you get back from a run is a file, not a tested copy.

PHP 8.4 and Laravel 12.0, or an older package on purpose

The version floor is stated in one line and it is high: this package requires PHP 8.4 and Laravel 12.0 or higher. If you are below either floor, the README does not offer a workaround, it tells you to use an older version of this package. Documentation is kept for version 3, version 4, version 5 and version 6, and the policy for those lines is explicit: no new features will be introduced to v6 and below, but bug fixes continue as necessary.

That makes the upgrade path a fork in the road rather than a ladder. A team still on Laravel 11 can use an older version of the package, or it can move the application up to Laravel 12 and take the current line. What it cannot do is run the current package on an older framework, which is the first thing to check before planning an install.

The current release line is 10.3.3, published on 2026-09-14, after 10.3.2 on 2026-08-20 and 10.3.1 on 2026-07-28. The last push on the repository was on 2026-11-01.

The README never mentions putting a backup back

Read the README as a sequence and something is missing from it. It describes taking a backup, a monitor that checks the health of your backups, notifications when a problem is found, and cleanup of old backups to avoid excessive disk space. Restore appears nowhere in that sequence, and no artisan command for it is given.

The four documentation pages the README links to match the same four topics: taking backups, monitoring the health of all backups, sending notifications, and cleaning up old backups. Full documentation sits behind spatie.be/docs/laravel-backup, so a restore procedure may well be described there. What the package's own front page does not give you is the command, the prerequisites for a restore, or a way to confirm that a zip taken three weeks ago is still readable.

That gap is the practical reason to keep a second copy of your database somewhere the application cannot reach. A backup you have never restored is a hypothesis.

The health monitor and its notifications are one link deep

The monitoring half exists so a broken backup is not discovered during an incident. The package ships a backup monitor to check the health of your backups and can notify you through several channels when a problem with one of them is found. That is the entire description of both features in the README.

Several channels is the part to notice. The README does not name them, so a Slack-only shop and a shop that wants mail both have to open the notifications documentation to find out. The monitor is described the same way: a health check with no documented thresholds, no list of the conditions it inspects, and no statement about what happens on the first run when there is nothing to compare against yet.

Cleanup is the least glamorous and the most concrete of the three. Old backups are removed to avoid excessive disk space, which implies retention settings that decide what survives. Nothing in the README says what the default retention is, so a long-running schedule is a disk-space decision made in a configuration file rather than a documented default.

The README's own doc links still sit under v8

A small detail worth knowing before you file an issue: every feature link at the top of the README points at a v8 path, for example spatie.be/docs/laravel-backup/v8/taking-backups/overview, while the release line is 10.3.3. The README tells you to install and read at the unversioned spatie.be/docs/laravel-backup instead, so the versioned links read as leftovers from an older release rather than as the current entry point.

For a package with a documented compatibility floor of Laravel 12, the difference between what v8 assumed and what 10.3.3 assumes is exactly the kind of thing that costs an afternoon. The repository does carry the two files that would settle it: CHANGELOG.md for what changed recently and UPGRADING.md at the top level of the tree.

So the ordering that saves time is version floor first, changelog second, and the v8 pages third, when you need an example rather than a requirement.

composer test is the only command the README gives contributors

The contributor surface is one line:

composer test

Everything else about working on the package is visible in the tree rather than in the README. There is a `src/` directory for the package code, `config/` for the configuration it ships, `docs/`, `tests/` with a phpunit.xml.dist beside it, `resources/` and `art/`. Static analysis has its own pair of files, phpstan.neon.dist and phpstan-baseline.neon, which is the usual sign that a baseline of existing findings is being carried rather than a clean slate. rector.php sits at the top level, and .github/ sits beside it.

Two closing notes from the README that matter more than they look. Security issues go to [email protected] rather than the issue tracker. And the package is MIT licensed, with an added request: postcardware. If it reaches your production environment, the project asks for a postcard from your hometown, and it publishes the address, Spatie, Kruikstraat 22, 2018 Antwerp, Belgium. Nothing enforces it, but it has its own Postcardware section in the README, so read it before you put it in a product.

An application-level package cannot see the rest of the server

The scope is what decides whether this is enough. The package runs inside your Laravel application with that application's database credentials and that application's configured filesystems. It produces a zip of the directories you named and a dump of the database it can reach.

That is a narrower view than a host-level snapshot or a managed backup service gets, which see the operating system, the mail queue, uploads outside the public directory, and any other database on the same host. The README does not position the package against those alternatives, so the comparison is left to you, and the honest version is simple: this is a convenient way to capture application state on a schedule, not a replacement for a full-server copy.

Where it does have an argument is portability. A zip on a configured filesystem, written to more than one destination at once, moves between hosts more easily than a machine image does. Write to a second filesystem on different hardware if you can, because the documented multi-filesystem option only protects you when the destinations are not the same disk.

Editorial conclusion

Use spatie/laravel-backup when you want scheduled, application-level backups of a Laravel 12 app on PHP 8.4 with the filesystems already configured in the app, and you already have a restore procedure you trust. Do not reach for it as your only copy of anything, because the README documents no restore command, no verification step, and no named notification channels. Before you schedule the first run, check three things: which disks are in `config/filesystems.php`, whether a zip written to the same disk it archives is a copy you would miss after a disk failure, and what the health monitor counts as healthy on a backup it has never restored.

Frequently asked questions

Official sources

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