Back up the application and database, prepare a staging destination and identify files that must persist outside releases, such as user uploads and environment credentials. Choose push or pull deployment deliberately because their triggering behaviour differs.

1. Create or clone the cPanel-managed repository and confirm its branch and current commit. Keep its working copy clean.
2. Add a valid .cpanel.yml at the repository root with a deployment section and tasks list. Start with explicit copies of known release files into a verified staging directory.
3. Commit the deployment file. Review every command and path; avoid blanket deletion or copying secrets from the repository into public access.
4. For pull deployment, open Manage > Pull or Deploy, choose Update from Remote, then Deploy HEAD Commit. Push deployment can trigger automatically when code is pushed to the managed repository.
5. Inspect deployment output and test the application before applying the proven process to production. Record the deployed commit and rollback method.

For a test repository containing index.html and styles.css, first create an empty permitted staging directory that the hosting account can write. Replace CPANEL_USER and the destination below with your actual staging path. Commit this file as .cpanel.yml at the repository root:

---
deployment:
  tasks:
    - /bin/cp index.html /home/CPANEL_USER/deploy-preview/index.html
    - /bin/cp styles.css /home/CPANEL_USER/deploy-preview/styles.css

Each task copies one named release file and can replace that file at the destination. Keep uploads and private configuration outside the release-file list. For pull deployment, fetch the reviewed commit with Update from Remote, then use Deploy HEAD Commit. Inspect the output and verify both files at the staging destination before adapting the process for the live application.

The destination should contain the intended release, uploads should remain intact, and application configuration should still reference the correct environment. Verify more than the homepage.

If a task fails, inspect the first error and the actual destination state before rerunning. Tasks executed before the failure may already have changed files. Restore or redeploy a known-good release through the prepared recovery process.

Only if your tasks explicitly run them. Plan database migrations separately and check backward compatibility before a code rollback. Git history does not preserve live orders or uploaded files unless you built a separate backup process.

• Cloning a private Git repository through cPanel
• Rolling back a Git deployment while preserving uploaded data
• Resolving a cPanel Git pull blocked by local changes
• Adding an SSH public key to a cPanel account

• cPanel: Guide To Git Set Up Deployment
• cPanel: Git Version Control