HOSTING / LESSON 14
Vercel Environment Variables.
Managing secrets and configuration
Loading the lesson…
Loading activities…
Browse lessons
HOSTING / LESSON 14
Managing secrets and configuration
Loading the lesson…
Loading activities…
Your app is gonna need secrets at some point. Passwords, API keys, that kind of thing. And you do NOT want those sitting in your code where anybody can read them. That's the whole job of environment variables.
Think of environment variables as hidden settings for your app. They hold information that fits one of these.
If you went through the Railway chapter, this will feel familiar. Vercel uses the same idea with a few extra features bolted on.
Say your app uses a service that needs an API key. You could paste the key right into your code.
Here's why that's a bad idea.
So you use an environment variable instead.
The real value lives safely in Vercel, and your code just points at it.
Vercel knows your app runs in a few different places.
This is your live site, the one real users visit. Production environment variables kick in when somebody goes to your main URL.
These are your preview deployments. Every pull request creates one, and preview environment variables get used for those temporary deployments.
This is your own computer while you're building and testing. Development environment variables help your app run locally.
Here's how to add one to your Vercel project.
Log in to Vercel and click on the project you want to set up.
Click the "Settings" tab at the top of the project page.
In the left sidebar, click "Environment Variables."
You'll see a form with three fields.
API_KEY)Check the boxes for where this variable should show up.
For most variables you'll just check all three.
Click "Save" and the variable is added. Your NEXT deployment can use it (more on that in a sec).
Here are a few you'll probably run into.
See what's happening there? It's the SAME name added twice with different values. Your code always reads process.env.STRIPE_SECRET_KEY, but the real key only goes to production and previews get a test key. That way you never accidentally charge a real customer while you're testing (that's a phone call nobody wants to make).
You might use the same database everywhere, or a different one for each environment.
That lets you test new features in previews before you turn them on in production.
Some variables are touchier than others, so Vercel lets you mark them as "Sensitive."
To mark a variable as sensitive, flip the "Sensitive" toggle when you create it. That toggle only works for Production and Preview, not Development.
Once your variables are in Vercel, your app reads them with process.env.
In Next.js, variables that start with NEXT_PUBLIC_ get exposed to the browser.
Vercel can help keep your local setup in sync too. You've got two options.
Use the Vercel CLI to pull your environment variables down to your machine. Install it once, then link your project folder to your Vercel project (it walks you through logging in the first time).
That creates a .env.local file with your development variables in it.
Or just make your own .env.local file with local settings. Just don't commit it to Git!
Add these lines to your .gitignore.
To change a variable, here's the drill.
DATABASE_URL instead of DB.env files to GitHubYou can deploy, preview and configure your app now. Next up is serverless functions, which let you add backend logic right inside your frontend project...