Nginx Static Site Basics for Makers
Learn how Nginx serves a static site from a document root, why release folders help, and how to verify a deploy safely.
Ladder steps
Each step should prove one idea before the project asks for the next one.
Examples to inspect
Use examples to read signals, not as blind recipes.
Test Nginx configuration
sudo nginx -t
Expected signal: syntax is ok and test is successful
Show the active release folder
readlink -f /srv/www/site/current
Expected signal: A timestamped release path
Check public response headers
curl -I https://example.com/
Expected signal: HTTP/2 200 or HTTP/1.1 200
Common traps
- Reloading before nginx -t.
- Editing the live release in place.
- Confusing a local file preview with a public deploy.
Practice task
Sketch a release layout with releases/YYYYMMDDTHHMMSSZ and current. Explain how rollback would work.
Next steps
- Connect DNS.
- Add TLS after HTTP works.
- Use Git to track deploy changes.
Practice ladder
- Near-Copy Rebuild: Recreate one example, decision path, or worked explanation from Nginx Static Site Basics for Makers. Keep most givens the same, then apply, explain, and check while naming each cue you used. Use the lesson's example block when it helps.
- One-Change Transfer: Change exactly one condition, number, input, symptom, material, or constraint from the near-copy case. Then apply, explain, and check again and explain what changed.
- Mixed Review Set: Interleave this topic with one prerequisite or adjacent idea. Write three short prompts: one recall, one application, and one comparison.
- Find And Fix The Error: Invent a plausible wrong answer, unsafe step, invalid assumption, or bad classification. Mark the first point where it goes wrong, then correct it using the lesson's check.
Flashcard preview
Why use a current symlink?
It lets a deploy switch atomically and makes rollback simpler.
What does the 'Separate releases from current' step prove?
Use timestamped release folders and a current symlink to make rollback possible. Check: readlink -f current shows the active release.
What does the 'Know the document root' step prove?
The root directive tells Nginx which folder becomes the web root. Check: The requested URL maps to a file under root.
What does the 'Test before reload' step prove?
Nginx can validate syntax before traffic changes. Check: nginx -t must pass before systemctl reload nginx.
What does the 'Verify from outside' step prove?
curl checks the public path, not just local files. Check: HTTP 200 and expected text confirm the page served.
When would you use `sudo nginx -t`?
Use it to test nginx configuration. Expected signal: syntax is ok and test is successful
Downloadable study pack
Export the same ladder as a plain Markdown note or Anki-compatible TSV. Commands and code blocks stay plain so they work in local notes.
Related paths
Study pack check passed. Notes, cards, examples, and practice tasks are meant to keep the ladder useful outside the page.
Continue learning this topic
Use this page as part of a project path, not as a one-off article. Save the note, review the cards, try the practice task, then choose the next ladder based on what your project exposes.
Study assets
Project context
- Deploy a Static Site on a VPS
- Browse Software and Linux
- Next ladder clue: Connect DNS.
Related references
Buy me a coffee for more maker ladders
TopicLadder is free to read. Support helps turn rough project paths into useful notes, cards, videos, and practice tasks.