# Static Site Release Checklist Lab Checklist

Use with Deploy a Static Site on a VPS: /projects/deploy-static-site-on-vps/

## Before starting

- [ ] Know the site root and the release folder naming pattern.
- [ ] Have a domain, server IP, and SSH access already configured outside this lab.
- [ ] Know which paths must return 200 after deployment.
- [ ] Decide the rollback release before changing a live symlink.
- [ ] Keep broad permission changes out of the first pass.

## During the lab

- [ ] Write the intended release name and public root before connecting to the VPS.
- [ ] Use find to confirm the release folder contains index.html and the expected asset directories.
- [ ] Use readlink -f to prove which release the current symlink serves.
- [ ] Run sudo nginx -t before any reload so a syntax error is caught early.
- [ ] Use dig +short on the apex and www hostnames and compare both answers with the intended VPS.
- [ ] Use curl -I on HTTP and HTTPS separately so TLS failure is not confused with DNS failure.
- [ ] Check one page body for expected text instead of trusting only a 200 status.
- [ ] Record www behavior as redirect, same content, or separate failure.
- [ ] Write the rollback command as a note, but do not run it unless verification fails.
- [ ] Summarize the live state in a project notebook with commands and actual output.

## Finished-state checks

- [ ] Release folder exists and contains public files.
- [ ] current resolves to the release you meant to serve.
- [ ] nginx -t passes before reload.
- [ ] Apex DNS returns the expected address or documented target.
- [ ] www DNS behavior is intentional.
- [ ] HTTP and HTTPS are checked separately.
- [ ] At least one public page body contains expected text.
- [ ] Rollback target is named before the next release.

## Common mistakes to avoid

- [ ] Assuming rsync success means the live symlink changed.
- [ ] Fixing browser output before checking DNS and the active release.
- [ ] Running chmod -R 777 instead of inspecting the exact path and service user.
- [ ] Reloading Nginx after a failed config test.
- [ ] Treating HTTPS failure as a site build problem before checking the certificate.

## Safety and boundary checks

- [ ] Do not use chmod -R 777 as a release fix.
- [ ] Do not reload Nginx after a failed config test.
- [ ] Do not request certificates repeatedly while DNS is still wrong.
- [ ] Do not delete old releases until a rollback target is no longer needed.

## Next step

- [ ] Run the VPS Debugging Lab: /practice/vps-debugging-lab/