Prerequisites
- Basic terminal navigation and file inspection.
- A domain, VPS, or local test server to reason about.
- Enough Git vocabulary to understand commits and releases.
- Willingness to verify with read-only checks before changing server config.
Software and Linux project path
Deploy a Static Site on a VPS
Learn the path from local HTML files to a live domain on a VPS with releases, Nginx checks, DNS, HTTPS, and rollback notes.
What good looks like
A good pass through this path leaves a learner with an artifact, a short project note, a list of checks, and enough vocabulary to choose the next TopicLadder page.
Build path
Each step has a concrete proof. If the proof is missing, stay on that step instead of adding more tools.
Build one local page
Start with a tiny static page so the first success is visible and reversible. Keep the page content boring until the deploy path is proven.
Proof: The page opens locally and has one clear title, one link, and one stylesheet.
Put files in a release folder
Use a timestamped release directory so every deploy has a concrete artifact and a rollback target.
Proof: You can point to the exact folder that should be served.
Teach Nginx where the files live
Read the server block, document root, and symlink path before reloading. The goal is to know what Nginx will serve, not to guess.
Proof: A config test passes before reload and the document root path exists.
Point DNS and add HTTPS
DNS and HTTPS failures look similar to beginners. Separate record lookup, HTTP reachability, certificate issuance, and renewal checks.
Proof: The domain resolves to the intended host and HTTPS loads the same content.
Capture live checks
Record the URLs, status codes, current release path, and one rollback note after every deploy.
Proof: A project note lists the live URL, release folder, config test, and next fix if the site fails.
Project checklist
- Local HTML page works before server work starts.
- Release folder has the exact files expected.
- Nginx config test passes before reload.
- DNS is verified separately from HTTPS.
- The deploy note includes rollback and live-check commands.
Downloads to reuse
- Linux foundations note — Terminal basics for inspecting the server.
- Nginx static site note — Release folders, document roots, and reload checks.
- DNS and SSL cards — Review records, certificates, and common failure signals.
- Maker Linux and VPS cards — Review deploy, DNS, Nginx, service, log, and safety checks.
How to work this path
Use the first pass to make the project legible. Write down the current state, the smallest proof you can run, and the result you expect before adding tools or features. If a step feels vague, shrink it until the proof can be checked in one sitting.
Common failure mode
The usual mistake is jumping from the project idea to a full tutorial stack. TopicLadder paths are meant to slow that down: learn one missing concept, inspect one example, capture one note, and only then choose the next dependency.
When to stop and ask
Stop when the next action could damage equipment, expose a system, erase data, create a safety risk, or depend on a manual you have not read. Bring the project note, checks already performed, and the exact question to a qualified person or a focused technical review.
Related ladders and references
Before moving on
Close the loop before starting the next ladder. Save the artifact, write the result in plain language, name the next uncertainty, and delete any step that was copied but not understood. That small cleanup is what turns a project path into reusable learning instead of a browser-tab pile.
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.