Advanced15-20 minDeploymentLesson 1

Deployment module

Deployment Is Publishing, Not Just Uploading

Learn what deployment means, why local success is not live evidence, and how browsers, servers, domains, DNS, and files work together.

Learning Objectives

By the end of this lesson, you'll be able to:

Explain deployment as publishing rather than uploading
Describe local development versus a live website
Identify browser, hosting, DNS and domain roles
Compare source files and production-ready files
Inspect paths, filenames, index.html and console errors before deployment

Why This Matters:

A live site has to work from a server for someone else, not just from your own project folder.

Before You Start:

You should be familiar with:

Files, Folders and Project Structure Review here
Test and Validate Your Site Review here

Local Development Versus a Live Website

Local development is where you build and test on your own computer. A live website is stored on a hosting service and requested by visitors' browsers over the web. It works on my laptop is a starting point, not deployment evidence.

When a page opens locally, the browser can often see files through your computer's file system or a local development server. That environment is more forgiving than the public web in some ways and completely different in others. It may hide case mismatches, allow local-only file references, or serve files from a development tool that will not exist on the host. A live visitor does not have your desktop, your folder structure, or your terminal running in the background.

Deployment asks a stricter question: can a browser on another device request the public URL and receive every file the page needs? That includes HTML, CSS, JavaScript, images, fonts, icons and any generated build assets.

The Roles in the System

Part	What it does
Browser	Requests files, runs JavaScript and displays the page.
Hosting server	Stores and serves website files.
DNS	Points names to the right hosting location.
Domain	The readable address people use.
Production-ready files	The files that should be served to visitors, such as static files or a Vite `dist` build.

Paths, Filenames and `index.html`

Absolute local paths fail online because visitors cannot access your computer. This path only works on one student's machine:

<img src="/Users/student/Desktop/project/images/logo.png" alt="Company logo">

Use a project-relative path instead:

<img src="./images/logo.png" alt="Company logo">

Case-sensitive servers also care about exact filenames. If the file is Logo.PNG but the HTML asks for logo.png, the live site may fail even if your local computer was forgiving.

Most static hosts look for index.html first. The server should not need a treasure map to find it.

Worked example: if your CSS says background-image: url('../Images/Hero.JPG') but the folder on the server is images/hero.jpg, the live site can lose its hero image. Fix the reference and the filename so they match exactly, then redeploy the changed file.

Learner Activity: Inspect a Project

Choose a small project before trying to deploy it. This activity is a pre-flight check. It is much easier to fix paths and filenames before the project is mixed with hosting, DNS and caching questions.

Confirm index.html exists.
Confirm files use relative paths.
Confirm filenames are consistently lowercase.
Confirm images and stylesheets load.
Confirm no files are referenced from outside the project folder.
Confirm the browser console has no obvious errors.

Publishing Knowledge Check

Before moving forward, can you answer these?

Why can an absolute path to /Users/student/Desktop fail online?
Why does index.html matter on many static hosts?
What is one reason a file can work locally but fail online?

Check Your Answers

The visitor and hosting server cannot access the student computer path.
It is the default homepage file the server looks for inside the public web root.
Case-sensitive filename mismatch, missing upload, local-only path, or a build output difference.

How confident are you with this concept?

Still confused | Getting there | Got it | Could explain it to a friend

Ready for the Next Deployment Step

Key Takeaways:

Deployment is a publishing workflow, not just a button.
The live URL is where deployment evidence is gathered.
The right hosting path depends on files, update workflow, support needs and ownership.
Troubleshooting starts with the first meaningful error.

Learning Objectives Review:

Look back at what you set out to learn. Can you now:

Learn what deployment means, why local success is not live evidence, and how browsers, servers, domains, DNS, and files work together. Check!

If you can name which part of the system you are changing, test the live result and record the outcome, deployment is becoming a repeatable workflow.

Think & Reflect:

Deployment evidence

What would prove this site works for someone else?

Next action

What should be recorded so this deployment can be repeated later?

Looking Ahead:

Next: continue with Understanding Hosting.

Overview Hosting Types

Recommended Next Steps

Continue Learning

Ready to move forward? Continue with the next tutorial in this series:

Understanding Hosting