# Static Site Release Checklist Lab

Project path: /projects/deploy-static-site-on-vps/
Video-note path: /youtube-notes/deploy-static-site-on-vps/

## Lab purpose

Practice verifying a static-site release before and after it goes live on a VPS.

You have a generated static site and a VPS that should serve it from a timestamped release. The lab asks you to prove the files exist, the current symlink points where you think it points, Nginx accepts the config, DNS reaches the expected host, and the live page returns the expected status before you call the release done.

Use this note as a working sheet. The useful outcome is not a polished paragraph; it is a record that proves what you checked, what result you expected, what happened, and what you will do next. Keep the note next to the project path so the practice stays attached to a real maker outcome.

## Starter state

A local build folder exists, a remote releases directory exists, and you have a domain that should point at the VPS. You have not yet assumed that the browser is showing the new release.

## Target finished state

A written release note names the active release, the expected public pages, the HTTP and HTTPS status, the DNS answer, the www behavior, and the rollback target.

## 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.

## Step-by-step lab

1. Write the intended release name and public root before connecting to the VPS.
2. Use find to confirm the release folder contains index.html and the expected asset directories.
3. Use readlink -f to prove which release the current symlink serves.
4. Run sudo nginx -t before any reload so a syntax error is caught early.
5. Use dig +short on the apex and www hostnames and compare both answers with the intended VPS.
6. Use curl -I on HTTP and HTTPS separately so TLS failure is not confused with DNS failure.
7. Check one page body for expected text instead of trusting only a 200 status.
8. Record www behavior as redirect, same content, or separate failure.
9. Write the rollback command as a note, but do not run it unless verification fails.
10. 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

- 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.

## Answer key

- A strong answer starts with readlink -f and find so the live release and generated files are known before server changes.
- The DNS answer must be recorded before certificate or Nginx work is blamed.
- The safest server command in the path is sudo nginx -t; reload is later and only after the test passes.
- A good release note includes a rollback target and one body-text check, not only a browser screenshot.
- If permissions fail, the next page should be the command-line checklist or LinuxOneLiners permission path, not a broad recursive mode change.

## Commands, artifacts, or checks to inspect

```text
readlink -f /srv/www/example.com/current
find /srv/www/example.com/current -maxdepth 2 -type f | sort | head -50
sudo nginx -t
dig +short example.com A
dig +short www.example.com A
curl -I http://example.com
curl -I https://example.com
sudo certbot certificates
```

## Safety notes

- 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.

## Reflection questions

- What did the first check prove?
- Which output, reading, signal, or artifact changed your next step?
- Which tempting shortcut did you avoid?
- What should you study before expanding the project?
- What should be copied into your long-term project notebook?

## Related TopicLadder links

- [Deploy a Static Site on a VPS](/projects/deploy-static-site-on-vps/)
- [Video notes for Deploy a Static Site on a VPS](/youtube-notes/deploy-static-site-on-vps/)
- [Maker Command-Line Checklist](/reference/maker-command-line-checklist/)
- [Maker Linux and VPS Flashcards](/decks/maker-linux-vps-flashcards/)
- [Run the VPS Debugging Lab](/practice/vps-debugging-lab/)
- [Practice index](/practice/)
- [Start Here](/start-here/)

## Project note template

Question:

Expected result:

Actual result:

Interpretation:

Next safe step:

This lab should leave behind a note that can be reopened later. If the note only says that something worked, it is not enough. Write the proof, the boundary, the thing you did not change, and the next step that would make the project easier to continue.

## How to judge the finished note

A finished note should let a future session restart the work without guessing. It should name the original question, the starting condition, the exact check that was performed, the result that was expected, the result that actually appeared, and the reason the next step follows from that result. If another learner cannot tell whether the project is blocked by knowledge, setup, parts, files, configuration, or safety boundaries, the note needs one more pass before the lab is complete.

The note should also keep scope small. A practice lab is not a full course, repair manual, or build diary. It is a checkpoint that proves one layer of understanding. When the lab exposes a missing prerequisite, link the next TopicLadder page instead of copying large source material. When the lab exposes a safety-sensitive question, write the question and stop before the page turns into instructions for work that requires manuals, supervision, or equipment-specific procedures.

## Repeatable run log

Run date:

Project state before the lab:

Smallest check performed:

Expected signal:

Actual signal:

Mistake avoided:

Related note, deck, or reference opened:

Next project action:

## Obsidian backlinks

Use these wiki links to connect this note inside a local maker vault:

- [[TopicLadder]]
- [[Maker Learning]]
- [[Static Site Release Checklist Lab]]
- [[Deploy a Static Site on a VPS]]
- [[Project Practice]]
- [[Applied VPS release practice]]
- [[Release folder inspection current symlink checks Nginx config validation DNS HTT]]
- [[Obsidian Project Notes]]
- [[Anki Review Cards]]
- [[Practice Tasks]]

## Source and next routes

Source: https://topicladder.com/practice/static-site-release-checklist-lab/

- [Deploy a Static Site on a VPS](/projects/deploy-static-site-on-vps/)
- [Maker Command-Line Checklist](/reference/maker-command-line-checklist/)
- [Run the VPS Debugging Lab](/practice/vps-debugging-lab/)