Prepare & operate
Update with a plan for the whole hosting environment.
Prepare the transition, protect the current state and verify the services your customers depend on after an update.
Release-specific update guidance
- Prepare
- Protect
- Apply
- Verify
- Recover if needed
Use the update path for your installed release.
Use the controlled update mechanism and release-specific instructions for an existing installation. The fresh installer is for a clean supported server and must not replace the update process.
Record the state you need to protect.
Identify the current release, hosted workloads, important service configuration and the maintenance window. Keep independent server access available. Review the proposed changes and the recovery material required before applying the update.
A staged change with validation before activation.
The update mechanism prepares the candidate, retains transition information and uses validation around activation. It includes recovery handling for an interrupted or failed update.
These controls reduce ambiguity about what ran, but they do not promise that every workload remains uninterrupted. Use the approved procedure for the exact release and investigate failures before calling the update complete.
Check the panel and the customer services.
After the transition, confirm administrator access, intended release and service health. Review background workers, monitoring and any warnings. Verify representative websites and the PHP/database combinations they use.
Check the services you actually offer, including DNS, SSL, mail and scheduled work where relevant. A successful panel page load does not prove every hosted application or mail path has recovered.
Rollback depends on the state you retained.
The recovery mechanism can identify a previous release and, when a matching pre-update snapshot exists, offer restoration of related configuration and panel state. A code-only switch is not equivalent to a compatible database/configuration rollback.
Restoring earlier state may discard changes made since the update. If matching recovery material is missing or the transition is unclear, retain the failure details and use support rather than assuming rollback is safe.
Clear next steps
Questions before your next change.
Understand the current scope before planning your next step.
Are updates guaranteed to have no downtime?
No. Plan for possible service impact and verify the workloads after the transition.
Can rollback always recover the previous environment?
No. It depends on the recorded previous release, compatible state and available recovery material. Restoring earlier data may discard subsequent changes.
Do I need separate customer backups?
Yes. Transition snapshots are not a substitute for a tested recovery plan for your hosted data and services.
Does a successful panel login prove the update is complete?
No. Verify the hosting services and representative customer workloads as well as panel access and worker health.
Continue with EzePanel