HOSTING / LESSON 07
Railway Environment Variables.
Managing secrets and configuration
Loading the lesson…
Loading activities…
Browse lessons
HOSTING / LESSON 07
Managing secrets and configuration
Loading the lesson…
Loading activities…
Your app needs some private info to work. Database passwords, API keys, secret tokens, that kind of stuff. None of it should EVER be typed straight into your code. It lives in environment variables instead.
Environment variables are settings that live outside your code. They fill in the blanks for your app. Your code says "connect to the database at _____" and the environment variable fills in that blank.
Think of a form letter.
The letter is the same for everybody, but the blanks get filled in differently for each person. Environment variables do the exact same thing for your app.
You might be wondering why you can't just type the password right into the code. Here's why that's dangerous.
When you push to GitHub, your code might be public. Or you might share it with teammates. Anybody who sees the code sees your secrets too.
Your local development database has one password, and your production database has another. You don't want to edit your code every time you switch.
Security folks all agree on this one. Secrets stay separate from code. If someone breaks into your GitHub, they shouldn't get your database password as a bonus prize.
So what counts as a secret? Anything you wouldn't want a stranger to see.
If it would cause damage in the wrong hands, it's a secret.
Railway keeps this part simple.
In your Railway project, click the service (your app) you want to set up.
Click the "Variables" tab. Any variables you already have will be listed here.
Click "New Variable" or "+ Add." You'll see two fields.
DATABASE_URL)Type in the name and the value, then click "Add" to save.
Add whatever other environment variables your app needs.
After you add or change variables, Railway doesn't apply them right away. It stages them as changes, and you'll see a banner on your project canvas. Click "Deploy" on that banner and Railway redeploys your app with the new values. (Forget this step and you'll be scratching your head wondering why nothing changed.)
Here are the ones you'll run into a lot.
The connection string for your database. Railway can set this for you when you add a database.
Tells Node.js apps whether they're in development or production.
The network port your app should listen on. Railway sets this one automatically.
Credentials for third-party services.
Secret values that belong to your own app.
Here's how you grab environment variables in a few different languages.
In Next.js, any variable the browser needs to see has to start with NEXT_PUBLIC_.
Variables without that prefix only exist on the server (which is usually exactly what you want for secrets).
Railway has a really handy feature called reference variables. They let one service pull values from another service automatically.
So your app can grab your database's connection string without any copying and pasting. Here's how.
In your app's Variables tab, click to add a new variable.
Instead of typing a regular value, you point at another service.
That tells Railway to pull the value from your Postgres service.
Railway keeps this variable in sync for you. If your database URL changes, your app picks up the new value automatically.
When you're working on your own computer, you need environment variables too. The usual move is a .env file.
In your project folder, make a file named .env.
Use a library like dotenv (for Node.js) to load those variables. Install it first.
Then load it at the very top of your app's main file.
Add .env to your .gitignore file.
That way you can't accidentally push your secrets to GitHub.
A few habits worth building now.
Make a file that lists which variables are needed, minus the real values.
That way other developers know exactly what they need to set up.
For stuff like JWT_SECRET, use long random strings. Online generators can help.
Change your important secrets every few months. If one ever leaks, that limits the damage.
Use different API keys and passwords for development and production. If your dev key leaks, production is still safe and sound.
.env files for local development (but never commit them!)NEXT_PUBLIC_ are exposed to the browser in Next.jsYour app is deployed, it has a database, and it's set up with environment variables. It's still sitting on a Railway-generated URL though. Next lesson, you'll connect your own domain name so it looks legit.