Project practice lab

Static Site Release Checklist Lab

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

Open related project Open video notes Download checklist

What you will practice

Release folder inspection, current symlink checks, Nginx config validation, DNS, HTTP, HTTPS, www behavior, and rollback notes.

This lab is account-free. Use it in the browser, copy it into a project notebook, or download the note and card files for local review.

What you need 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.

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.

Step-by-step lab

Move through the checks in order. The point is to build evidence before expanding the project.

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.

Checks before moving on

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.

Commands or artifacts to inspect

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

Answer key

Open this after you have written your predicted result. A useful answer explains what the check proves and what should happen next.

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

Downloadable Obsidian notes

The note version includes the lab purpose, starter state, target state, step list, answer key, reflection questions, and related links.

Download Obsidian note

Downloadable Anki cards

The deck tests reasoning, expected signals, wrong moves, safety boundaries, and next steps for this project practice path.

Download Anki cards

Downloadable checklist

Use the checklist beside a real project session. It keeps the before, during, finished-state, mistake, and safety checks visible.

Download checklist

Preview cards

What is the goal of Static Site Release Checklist Lab?

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

Who should use Static Site Release Checklist Lab?

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.

What is the starter state for Static Site Release Checklist Lab?

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.

What is the target finished state for Static Site Release Checklist Lab?

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.

What project does Static Site Release Checklist Lab support?

Deploy a Static Site on a VPS

What does Static Site Release Checklist Lab test?

Release folder inspection, current symlink checks, Nginx config validation, DNS, HTTP, HTTPS, www behavior, and rollback notes.

Static Site Release Checklist Lab before-start check 1

Know the site root and the release folder naming pattern.

Static Site Release Checklist Lab before-start check 2

Have a domain, server IP, and SSH access already configured outside this lab.

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.

Next step

After the lab, write what you proved and what remains uncertain. Then use Run the VPS Debugging Lab rather than opening another disconnected tutorial.

Buy me a cup of coffee

TopicLadder is free to read. Coffee support helps turn rough maker ladders into clearer project paths, notes, cards, and practice labs.

Buy a coffee

Last reviewed: July 5, 2026. TopicLadder pages are curated for practical learning and may be updated as examples improve.