Lesson 6 of 6 · about 20 minutes

Project configuration: what goes where

The win A vercel.json in your repository changes how Vercel serves the app, you prove it on a Preview deployment before production sees it, and for any setting you can name the one place it belongs.

First, recall

Which Neon variable do your routes use, and why that one?

DATABASE_URL, the pooled connection string, because functions open many short-lived connections. (Lesson 5)

Why did Lesson 4 have you type the key at a prompt instead of using --value?

--value puts the secret in your shell history. (Lesson 4)

What creates a Preview deployment?

Pushing a branch that is not the production branch, or opening a pull request. (Lesson 2)

You have configured almost nothing, and that is correct

Five lessons in, the only configuration you have written is environment variables. Vercel recognised Next.js and chose the build command, the output and the routing itself. Configuration on Vercel means overriding a default, so the skill is knowing where each override lives.

Where does this setting live?
Setting	Its home	On Hobby
API keys, database URLs	Environment variables (dashboard or `vercel env`)	Never in a file in the repository
How long one route may run	`export const maxDuration` in the route file	Default and maximum 300 s
Redirects, headers, rewrites	`vercel.json`
Where functions run	`regions` in `vercel.json`, or project settings	Any single region; default `iad1`
Scheduled jobs	`crons` in `vercel.json`	Once per day at most, within the hour
Build, install, framework preset	Detected; override in project settings or `vercel.json`	`vercel.json` wins over the dashboard
Production branch	Settings → Environments → Production → Branch Tracking
Who may open previews	Settings → Deployment Protection	Password protection is not available

Two rules of thumb fall out of that table. Secrets go in environment variables and nothing else. Everything that should be reviewed, versioned and tested on a Preview goes in a file in the repository.

Do it

You will add a friendly /health address that redirects to the probe, cap the database route's run time, and test both on a Preview before merging.

Start a branch.
```
git switch -c config
```

Create vercel.json in the project root, next to package.json. The $schema line gives your editor autocomplete and validation.

vercel.json

{
  "$schema": "https://openapi.vercel.sh/vercel.json",
  "redirects": [
    { "source": "/health", "destination": "/api/health", "permanent": false }
  ]
}

Cap the database route. Add this as the first line of app/api/db/route.ts. A query that hangs is now cut off after 10 seconds instead of running for the full 300.
```
export const maxDuration = 10; // seconds; Hobby allows up to 300
```

Push the branch.

git add -A
git commit -m "Add vercel.json redirect and cap db route duration"
git push -u origin config

Test on the Preview. Open the new Preview deployment from the dashboard and visit /health. You land on /api/health, and it says "env":"preview" with both keys present. Production has not changed; check /health there and you get a 404.
Merge.
```
git switch main
git merge config
git push
```
After the production deployment finishes, /health works on your production domain. That is the win, and it is also the workflow for every change you make from here on.

Check yourself: the whole course

These mix all six lessons on purpose.

Where does DATABASE_URL belong?

The vercel.json file
The next.config.ts file
Project environment variables

Both files are committed to Git. Vercel is moving people off the old env property of vercel.json for exactly this reason. Source

On Hobby, you add a cron job with the schedule 0 * * * * (every hour). It will…

fail at deploy
run once daily
run every hour

“Hobby accounts are limited to cron jobs that run once per day. Cron expressions that would run more frequently will fail during deployment.” Source

In a Next.js App Router project, what limits how long one route may run?

a vercel.json redirect
a maxDuration export
an environment variable

“The Next.js app router uses a named maxDuration export” in the route file. Source

vercel.json sets buildCommand, and the dashboard's Build Command says something else. Which is used?

The vercel.json value
The dashboard value
Whichever changed last

“This value overrides the Build Command in Project Settings.” The file in the repository is the source of truth. Source

You add a redirect to vercel.json on a branch and push it. Where can you first see it work?

On the Production domain
Only under next dev
On the Preview deployment

A pushed branch becomes a Preview deployment with its own URL, and Vercel applies vercel.json there. Production changes only when you merge. (Lesson 2)

Someone suggests renaming the key to NEXT_PUBLIC_ANTHROPIC_API_KEY so a client component can call the model directly. What follows?

The build rejects the name
The key ships to browsers
The key stays on servers

The prefix tells Next.js to inline the value into the JavaScript bundle at build time. Every visitor could read your key. Call the model from a Route Handler instead. (Lesson 3)

Where to go from here

You have a deployed app with a model key and a database, configured the way Vercel intends. Sensible next sessions, in rough order of value:

Separate development data from production data (the warning at the end of Lesson 5).
Put sign-in or a rate limit in front of anything that calls the model.
Add a custom domain.
Learn the Usage page, so you see a Hobby limit coming.

Read this Project configuration for the map, then skim the property list in vercel.json so you know what exists.

Ask your teacher, and then ask other people Your Claude Code session can explain and debug. Judgement about what works in practice comes from people running real apps. The Vercel Community forum is run by Vercel and has a Help category, and Next.js Discussions on GitHub covers the framework side. Post your vercel.json and ask what people would change.