What Happens When a Temporary Production Checkpoint Is Selected

Selecting a temporary production checkpoint adds a pre-install protection phase: QCUL captures and validates the update-related live database/file scope before it changes production.

Checkpoint preparation

• Create a run/replay-scoped private checkpoint path.
• Determine protected file/database scope from laboratory evidence; core updates use broader Joomla-prefixed table protection.
• Capture exact table definitions, indexes/foreign keys, row data, protected file hashes, and files that would need removal on rollback.
• Advance capture in restartable batches and validate the checkpoint.

No checkpoint, no push

If the selected checkpoint cannot complete and validate, production installation does not begin. Correct the resource/permission/storage problem or deliberately choose a different verified recovery method before retrying.

Rollback clock

After production work, the checkpoint is eligible only during the configured Undo Production Push window and is later cleaned up automatically.

Production change rule

For What Happens When a Temporary Production Checkpoint Is Selected, the live site should change only through the explicit tested-item production workflow after current readiness checks pass. Do not substitute a new package, skip the review/protection decision, or run a second production action while QCUL already owns an active push/rollback state.

Community Discussion

Want to compare update-testing workflows, share practical tips, or discuss how you use this QCUL feature? Visit the QC Update Laboratory Community. For private support, bug reports, account-specific issues, or feature requests, use the QuantaCade support system.