The guardrails

All of these are in the free edition. Six of them, plus two things that are not strictly guardrails but do the same job.

The dry run

Not optional, and not skippable. The control panel previews on every change to the form and again on the server when you fire; the console defaults to --dry-run everywhere and needs it explicitly turned off. See running a strike for what it reports and why it can be trusted.

The typed confirmation

You type the handle of the source being targeted. The point is not that typing is hard — it is that it cannot happen by accident, by a double-click, or by a browser restoring a form on back-navigation.

The phrase is configurable. {scope} in it is replaced with the source’s handle, which is what makes the confirmation specific: typing news is a check that you are deleting the section you think you are, in a way that typing DELETE is not. Set a literal phrase instead if you prefer, or switch confirmation off — but an empty phrase with confirmation on is rejected, because it would arm every strike on a stray Enter.

The backup

Taken immediately before anything is deleted, into storage/backups, named after the run: nuke-run-42-2026-08-17-093000.sql. The path is stored on the run record, and the run screen tells you whether the file is still on disk.

If the backup fails, nothing is deleted. A caller that asked for a backup asked for it because of what was about to happen next; continuing without one would turn a safety feature into a false sense of one.

Sites where the database is too large for this to be practical should turn it off deliberately and rely on their host’s snapshots — and the preview will warn, every time, that no backup is being taken.

Soft delete by default

Elements go to Craft’s trash. Permanent deletion is a separate permission (nuke:hardDelete), not merely a checkbox, so it can be granted to some people and not others.

The ceiling

Ten thousand elements per run out of the box. Past it the preview refuses with an error rather than a warning.

The point is not that ten thousand is dangerous. It is that a mis-scoped strike — a filter that did not apply, a section left unticked — usually matches far more than intended, and failing loudly at the preview is better than succeeding quietly at 200,000 rows. Raise it in settings when you genuinely mean to, or set it to 0 to remove it.

Protected scopes

Handles listed in settings can never be targeted. Checked on the server at preview time, so it covers the control panel, the console and the queue equally.

And two more

The ledger

Every run — strike or sweep — opens a row before the work starts. That is deliberate: a run that crashes half-way still leaves a record saying what it was doing, which is exactly the run somebody will need to reconstruct. The row holds the target, the preview it was approved against, and the outcome.

The log

Nuke writes storage/logs/nuke.log at info by default, unlike the read-only plugins in this family. A successful deletion is precisely the thing worth recording, and the log survives the database it was deleting from — which makes it the authoritative trail and the ledger the convenient copy.

Loosening them

All of it is in Nuke → Settings → Guardrails, or in config/nuke.php. Two things are worth saying about doing so:

• Turning off confirmation and turning on permanent-delete-by-default, together, produces a screen where one click destroys content irrecoverably. That combination is available and it is not recommended.
• Console strikes can be disabled entirely (allowConsoleStrikes) if you want the control panel, with its preview and its confirmation, to be the only route.