# Going live
> The two addresses to set, the build that runs on its own, and the check that stops a bad publication.
Lesson 3 of 3 — the last one of the course.
The site is a folder of HTML files. Putting it online is copying that folder
somewhere — the work is in the two addresses you set first, and in the check
that runs after.
## The two addresses
They answer different questions, and mixing them up is the most common way to
publish a broken site:
| Field | Answers | Looks like |
| --------- | ----------------------------------- | ------------------------------- |
| `baseUrl` | Where the site sits on its host | `/` or `/my-course/` |
| `siteUrl` | The full public address of the site | `https://example.com/my-course` |
```js
siteUrl: 'https://example.com/my-course',
baseUrl: '/my-course/',
```
`baseUrl` prefixes every internal link. Served from a subfolder without it,
every link points one level too high — the site works on your machine and
breaks the moment it is online. `siteUrl` is what lets the build write a
sitemap, canonical addresses and share previews.
`npx docpensieve dev` serves at the root, so a wrong `baseUrl` never shows there. Build and open
`dist/` the way the host will: that is the only honest rehearsal.
## Your turn: build and read it back
```bash
npx docpensieve build
npx docpensieve check
```
The first writes the site. The second reads it back and **exits with code 1**
if a link leads nowhere — which is what makes it worth running in a pipeline:
a build that succeeds says nothing about a link that does not.
`check` settles the second gauge. The third one is yours — nothing automates
reading your own pages.
## A build that runs on its own
The shape of the pipeline matters more than its dialect. Every host writes it
differently; each does the same four things:
```yaml
- run: npx docpensieve build
# A successful build says nothing of a dead link.
- run: npx docpensieve check
```
A project created by `init` has no `package.json`, so `npx` takes the latest published version —
convenient at first, surprising later. Declare the tool in a `package.json` and run `npm ci`
before the build, and two builds a month apart produce the same site.
## What the reader downloads
One HTML file
Complete on its own, served as it is — no framework to boot.
One stylesheet
Per version, minified, holding only the rules the pages use.
No script
Except the search page, and the light/dark button if you keep it.
## Check yourself
Your site is served from `example.com/docs/` and every link 404s. What did you forget?
`baseUrl: '/docs/'`. Without it, links are written from the root of the domain
and point one level above the site.
Why run `check` in the pipeline when the build already passed?
Because they look at different things. The build compiles pages; `check` reads
the produced site and follows its links. A renamed page compiles perfectly and
leaves every link to it dead.
## Live session
**The live session is today.** Bring your questions.
Next live session: **15 October**. Bring the site you built during the course.
The live session is over — its questions and answers are below.
## You made it
You have finished the course. Your site is built, checked, wearing your
colours, and ready to put online.
Back to the course
Every module, and what each one covers.
The deployment guide
The full pipeline, a scheduled build, and keeping past versions online.