Publishing a new version of the site for people. A deploy puts a new version on the hosting where everyone sees it. A commit only saves a version in Git, and a domain is bought separately.

The build failed with an error. What do visitors see?

The old version that worked. A broken build isn't published, so the previous version stays live. You read the build log and fix it.

You want to show a friend a new page without touching the live site. What do you use?

The branch's preview link. A branch gets its own copy of the site at a separate link. A push to main would change the live site right away.

Hosting and deploy

Lesson 11 of 26 in the course “Vibe coding”. Free, with animations and a quiz.

Hosting: a computer that never sleeps

Example: you and AI built a site for your band. Right now it only opens on your laptop. Close the lid and the site is gone. Hosting is a computer in the cloud that stays on around the clock and serves your site to anyone who opens the link. In the figure it's the cloud with the server. You don't need your own server: the hosting service runs it for you.

Deploy: shipping a new version

Deploy means publishing a new version of the site so people can see it. People used to upload files to a server by hand. Now it's simpler: you connect your GitHub repository to the hosting once. After that, every push to main, meaning sending commits to the main branch, starts a deploy on its own. In the figure the arrow goes from GitHub through the build to the live site. Added gig photos, pushed, and soon the site is updated.

Build: from project to ready files

A browser only understands HTML, CSS and JavaScript. But a project made with AI is often written with a framework, a ready-made skeleton with handy rules, and it needs to be processed. That's the build: the hosting runs a build command, for example npm run build, and puts the ready files into an output folder, for example dist. The progress bar in the figure is this step. Usually the hosting guesses these settings by itself.

Build failed? The site is fine

Don't panic. If the build fails with an error, the hosting doesn't publish the broken version. People keep seeing the old, working one: that's the red note in the figure. What to do: open the build log, the journal where the hosting writes down every step. Look for red lines near the end. Copy the whole error and give it to the AI, like in the lesson on giving tasks. Fix it, push, and the build runs again.

A preview for every branch

Remember branches and Pull Requests? A hosting connected to GitHub usually builds each branch separately and gives it a preview link: a copy of the site that doesn't touch the live one. Example: in a branch you try a new page with the gig schedule. You open the preview on your phone and send the link to your drummer. Everyone likes it: you merge into main, and the live site updates by itself.

Static site or one with a server

A static site is only frontend: ready pages that are the same for everyone. A band site with photos and a gig list is exactly that, and it's the easiest kind to host. If you need to do something hidden from the browser, like accepting sign-ups or keeping an AI key, you'll need server functions: small pieces of backend that the hosting runs on request. Many hostings can do both.

Check yourself

What is a deploy?
Correct answer: Publishing a new version of the site for people. A deploy puts a new version on the hosting where everyone sees it. A commit only saves a version in Git, and a domain is bought separately.
The build failed with an error. What do visitors see?
Correct answer: The old version that worked. A broken build isn't published, so the previous version stays live. You read the build log and fix it.
You want to show a friend a new page without touching the live site. What do you use?
Correct answer: The branch's preview link. A branch gets its own copy of the site at a separate link. A push to main would change the live site right away.

← The terminal in 10 minutes Cloudflare: Pages, Workers, protection →