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

## Outcome
Understand the path from a local HTML file to a live HTTPS page on a VPS.

## Safe first step
nginx -t proves configuration syntax before reload.

## Ladder steps
### 1. Separate releases from current
Use timestamped release folders and a current symlink to make rollback possible.

Check: readlink -f current shows the active release.

### 2. Know the document root
The root directive tells Nginx which folder becomes the web root.

Check: The requested URL maps to a file under root.

### 3. Test before reload
Nginx can validate syntax before traffic changes.

Check: nginx -t must pass before systemctl reload nginx.

### 4. Verify from outside
curl checks the public path, not just local files.

Check: HTTP 200 and expected text confirm the page served.

## Examples
### Test Nginx configuration
```sh
sudo nginx -t
```
Expected signal: syntax is ok and test is successful

### Show the active release folder
```sh
readlink -f /srv/www/site/current
```
Expected signal: A timestamped release path

### Check public response headers
```sh
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.

## Related
- [Nginx 502 repair path](https://linuxoneliners.com/problems/nginx-502-bad-gateway/)