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.
Real project proof
Use this section to decide whether the page produced a working artifact, not just more reading.
What you will build
A static site served from a release folder on a VPS, reachable from a domain, with a short deploy note and rollback path.
Final artifact example
project-site/ with index.html, assets/, a generated release folder, an Nginx server block, a live-check note, and a rollback note that names the previous release.
Finished-state checklist
- Local page opens before any server work starts.
- Release folder contains only the files intended for public serving.
- Nginx document root points at the current release or current symlink.
- nginx -t passes before reload.
- Domain A or CNAME records match the intended host.
- HTTP and HTTPS checks are recorded separately.
- A rollback release is named in the project note.
- The final note lists the next improvement instead of a vague rewrite.
Practice extension
Run the VPS Debugging Lab after the first deploy. Treat every failed status code as a clue: DNS, HTTP, HTTPS, Nginx config, release path, or file permissions.
Related notes
Related deck
Related practice task
Related reference page
Download bundle preview
These downloads give the project a portable note or card set before any account-based feature exists.
- 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.
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.
Source videos for this project ladder
Watch one source only after the written path is clear. Use the video to make better notes, cards, and practice checks.
Use the source as a companion, not as a replacement for the written ladder.
Featured tutorial
Primary source
How to Deploy a Web App to a VPS
Video by Metics Media · Open on YouTube
Shows the shape of a real VPS deployment flow so the learner can compare project files, server setup, DNS, and verification checks against the written ladder.
First watch: Watch for the point where local files become a server release, then compare that with the TopicLadder deploy checklist.
- Project files and server goal
- VPS setup choices
- Domain and web server checks
- Final browser verification
Practice after watching: Write one release checklist for your own static page, then prove HTTP reaches the expected server before touching HTTPS.
Source note saves on this device.
Suggest a better source video
If another tutorial explains this topic more clearly, send the title and YouTube URL. Suggestions should help the ladder, not replace it.
Topic: Deploy a Static Site on a VPS
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.
Video-note lesson path
Use the matching video-note page when a tutorial or workshop video helps explain one step in this project. Keep the written project path as the source of truth, then capture timestamps, warnings, cards, and a practice task from the video.
Practice this project
Use the matching practice lab when you want to prove the project path with a small hands-on run instead of only reading the steps.
Related ladders and references
Before moving on
Close the loop before starting the next lesson. 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 cup of coffee
TopicLadder is free to read. Coffee support helps turn rough maker ladders into clearer project paths, notes, cards, and practice labs.
