Apply and recover a coordinated update
Updates coordinate application files and any required Obelisk database migration through a saved plan. Start from Administration, Updates and the compatible update ZIP supplied for your release. Keep a current full backup and a maintenance window available before authorizing application.
Follow the supplied package order
The complete installation download is for a new site. For an existing site on the supported starting release, the current update is a single compatible ZIP; a new preparatory package is not required. Read the release instructions for your actual starting version before uploading it. Older installations can require an intermediate transition: use a preparatory package only when the provider’s instructions explicitly require it for that starting version, never simply because an old package is still available.
Read the actual file/database plan and its recovery copies before each application, even if the schema version remains unchanged. Different packages have different plans; do not substitute a previous plan command, apply loose PHP files or import SQL separately. If the preview rejects the starting version or detects a customization in a SQL block to be changed, retain the message and obtain the matching instructions. An ordinary supported update retains the existing license; do not delete it or request activation just to update.
Prepare and verify the plan
Read the proposed changes
Upload the compatible update ZIP and inspect the file changes, package SHA-256 and database schema transition. Check the supported starting versions in the supplied release notes and the update preview. Required earlier migrations are checked and are not repeated when already complete.
Use the commands generated for this plan
Where available, run the displayed verification command first. It records a dated check without applying changes or entering maintenance. Then use the exact application command from the same plan in an interactive SSH terminal. Application repeats its checks before proceeding.
Supply SQL authority only when requested
The updater uses a root-only private SQL profile outside the web directory. If missing, normal application asks for administrative credentials and a hidden password before maintenance. Web requests do not use that administrative account. Preserve the saved profile and its restrictive permissions.
Check SQL authority and recovery space
Before a coordinated schema update, the SQL recovery copy needs local free space of at least three times the estimated Obelisk data and index size, with a minimum of 16 MiB, plus space for file copies. This check does not measure free space on a remote SQL server. Review both hosts when SQL is remote. Keep recovery copies until the operation and the resulting reports have been verified; an automatically calculated size is not permission to remove them.
Check an existing private SQL profile
For the default installation path, this command validates the existing profile and SQL access without migrations, data copies or changes to events. It may prepare the private diagnostics directory. Use the installation’s PHP CLI if it differs. A missing profile must be established through the normal application command from the plan; this check does not create one. If the administrative password has changed, ask the DBA to update only the profile belonging to this installation, preserving root ownership and its restrictive permissions.
Commandcd /var/www/html/obelisk && sudo php utility/schema_profile.php --check
Inspect the actual state
Before structural changes, the updater saves the complete Obelisk database and affected files and suspends workers. Keep the prepared plan and recovery copies if it stops. From the default installation directory, the following command displays update status without applying an update. Use the configured PHP CLI if it differs. A prepared plan can be retried after correcting its cause; recovery_required needs the recovery instructions shown for that plan.
cd /var/www/html/obelisk &&
sudo php utility/update.php --statusResume or restore deliberately
Use Show application command to resume the saved plan, or Show restore command when database restoration has already begun. A coordinated rollback that restores the database returns all Obelisk data to the pre-update copy: later changes are lost. Completed rolled_back or failed_rolled_back plans require uploading the ZIP again for a new plan. Never remove maintenance markers or edit progress files to bypass recovery.
After success, run Verify installation and review the web-protection preview offered by the updater. Settings, recordings and telephone sources are preserved. Installations using the current license format retain their license. Older license formats may require reactivation after updating; check the supplied release notes before proceeding. Remove a completed plan’s recovery copies only through its explicit cleanup action when rollback is no longer needed: cleanup permanently removes that recovery option.
Use the controls, understand what changes
After uploading the package, review the generated plan and use its current check/apply commands. An uploaded or checked package is not yet an applied update. Refresh the panel to read the execution result; keep recovery copies until the resulting installation has been verified.
Complete product screenshots
Illustrative data. Open the screenshot to enlarge it and match the controls to the instructions in this chapter.
Open complete screenshot