---
title: 'Deployment checks'
description: 'Keep URLs correct across dev, preview, and production, so canonicals, sitemap entries, and links never leak localhost to the live site.'
slug: 'deployment-checks'
type: 'article'
date: 2026-01-25T00:00:00.000Z
lang: 'en'
url: 'https://www.eleventy-baseline.dev/docs/how-to/deployment-checks/'
---
Keep your URLs correct across dev, preview, and production, so canonicals, sitemap entries, and links never leak `localhost` to the live site. The mechanics are mostly Eleventy and environment variables; this chapter is the small set of habits that keep them honest.
Three terms used below:
- **Canonical.** The `` URL Baseline writes into every page's head.
- **pathPrefix.** Eleventy's option for deploying under a subpath (e.g. `/docs/`). It reaches the links inside your pages and the sitemap. It does not reach the absolute URLs the head emits; see [[deploy-under-a-subpath | deploying under a subpath]].
- **Preview build.** A non-production deploy (a Netlify deploy preview, for instance) where the origin differs from production.
---
## Prerequisites
Somewhere to deploy the site to.
---
## Set settings.url (and, separately, pathPrefix)
Use the `src/_data/settings.js` you already have from the previous tutorials. The field that matters for this chapter is `url`, the canonical origin:
```js
url: process.env.BASELINE_URL; // one value, supplied per environment
```
If you're deploying under a subpath, set `pathPrefix` in `eleventy.config.js` (e.g. `/my-site/`) – it lives on the Eleventy config, not in `settings`. Eleventy rewrites the links in your pages with it, and the sitemap picks it up too. The head's absolute URLs are the exception, and [[deploy-under-a-subpath | deploying under a subpath]] has that caveat in full.
---
## Set environment URLs (local and CI)
- Dev or local preview: create a local `.env` (don't commit it):
```txt
ELEVENTY_ENV="development"
BASELINE_URL="http://localhost:8080/"
```
- Production: set `BASELINE_URL` to the live origin (e.g. `https://www.example.com`) in your hosting or CI environment.
- Hosted previews (optional, e.g. Netlify): the host sets its own variables. `URL` points at production while `DEPLOY_PRIME_URL` points at the preview. Baseline reads neither. Pick whichever one you want the build to claim and assign it to `settings.url` yourself.
`ELEVENTY_ENV` is the development-versus-production switch. What it changes is on [[project-structure | project structure]], next to the Eleventy variable it is easy to confuse it with.
A `.env` file is optional. Plenty of projects never have one and set their variables in npm scripts or in the host, which works with no extra packages. If you do keep one, loading it is yours to do: install `dotenv` and import it at the top of the file that reads the value, normally `_data/settings.js`:
```js
import 'dotenv/config';
```
Keep that import in the same file as the read. Put it somewhere else, in `eleventy.config.js` say, and whether it has run by the time `settings.js` is evaluated depends on the order the import lines happen to be in, which fails silently. Leaving it in on a host that has no `.env` costs nothing; dotenv finds no file and moves on.
The variable name is yours: Baseline only reads `settings.url`, so whatever your host calls it, put it there.
{% alertBlock "warning" %}
Pick a name nothing else has claimed. `URL` is defined by Netlify, and on a deploy preview it stays pointed at production, so a preview build would quietly claim the live domain. `BASE_URL` is reserved by Vite, which defaults it to `/`, so anything running through Vite or Vitest reads a relative value instead of yours. Both failures are silent, which is what makes them expensive. `BASELINE_URL` is the name these docs use because it is specific enough that nothing else wants it.
{% endalertBlock %}
Everything absolute in the build comes from that single value, and leaving it unset makes Baseline warn at startup rather than guess an origin. [[site-settings | Site settings]] lists what it anchors and what goes missing without it.
---
## Run with the right URL per environment
Dev: confirm your `.env` is loaded (e.g. `BASELINE_URL="http://localhost:8080/"`), then:
```bash
npm start
```
Production: set `BASELINE_URL` in hosting or CI to the live origin (not an inline shell export), then:
```bash
npm run build
```
Spot-check the rendered pages: canonical and sitemap entries should use the origin you expect.
---
## Preview builds (optional)
- On Netlify, `DEPLOY_URL` and `DEPLOY_PRIME_URL` provide the preview origin. Feed one of them to your own variable on the build command, since `netlify.toml` does not expand variables inside an `[environment]` block:
```toml
[context.branch-deploy]
command = "BASELINE_URL=$DEPLOY_PRIME_URL npm run build"
```
- Other hosts differ; set an equivalent preview origin for whichever staging environment you have.
- Confirm the rendered canonical and the sitemap root both match the preview domain.
---
## Verify outputs
- View source on a rendered page. The `` and every absolute link in the head should use the right origin. If `BASELINE_URL` is set in CI or production, none of them should say `localhost`.
- Inspect `dist/sitemap.xml` (and the per-language sitemaps if multilingual is on). URLs should start with the expected origin, plus `pathPrefix` if you've set one.
---
## PathPrefix checklist (if applicable)
For the full subpath setup, see [[deploy-under-a-subpath | Deploy Under a Subpath]].
---
## Next steps
- Add a CI check that fails the build if `BASELINE_URL` is missing in production. One small step, lots of headaches saved.
- Pair with the [[multilingual-baseline-site | multilingual site tutorial]] to confirm hreflang URLs use the correct origin once multilingual is on.
---
## See also
- [[site-settings | Site settings]] - `settings.url` in full.
- [[deploy-under-a-subpath | Deploy under a subpath]] - what `pathPrefix` changes, and what it does not reach.
- [[build-scripts-and-cleanup | Build scripts and cleanup]] - where the environment variables get set.