Using QCTNH on Staging, Development, or Cloned Sites

Staging, development, and cloned sites need deliberate QCTNH identity handling because a copied database also copies the production installation UUID, encrypted credential, registered origin, and service state.

Safe clone behavior by default

If the cloned site loads at a different origin, QCTNH detects the mismatch and refuses automatic re-registration. This protects the original production registration from being silently replaced by the clone.

Choose how the clone should operate

GoalRecommended handling
Clone should not receive QuantaCade wake-upsLeave the service paused/identity mismatch unconfirmed. Joomla’s own Scheduler can still be tested through other appropriate methods.
Clone needs independent QCTNH wake-upsEnsure it is publicly reachable with its own correct canonical URL, then run Test Connection on the clone to create a new identity.
Private/local development hostQCTNH central validation rejects private/reserved targets; use Joomla local/CLI scheduling rather than trying to register a non-public host.

Do not copy secrets manually

Do not transplant WebCron keys or QCTNH encrypted service credentials between unrelated installs. Let each intended public installation generate and synchronize its own identity.

What should remain unchanged

During Using QCTNH on Staging, Development, or Cloned Sites, Joomla Scheduled Task definitions remain owned by Joomla and their extensions. QCTNH identity rotation does not rewrite task recurrence or choose new task IDs. Likewise, a same-domain restore may preserve QCTNH identity while separately changing task next-execution/lock timestamps because those values came from the restored Joomla database.

Review both layers after migration: service identity/connectivity and scheduler queue state.

Set up a clone deliberately

  1. Restore or clone Joomla and finish the clone’s intended hostname, HTTPS, and base-path configuration.
  2. Open QCTNH Dashboard and note the expected origin-mismatch protection inherited from production.
  3. If the clone should not receive QuantaCade wake-ups, leave the production identity unconfirmed and keep the service paused as appropriate.
  4. If the clone is a public independent site that should receive wake-ups, run Check WebCron and then Test Connection on the clone to create its own identity.

Community Discussion

Want to compare scheduler workflows, share practical tips, or discuss how you use this QCTNH feature? Visit the QC Task Nudge & Health Community. For private support, bug reports, account-specific issues, or feature requests, use the QuantaCade support system.