Production Environment Variables

[00:00:00]
>> Speaker 1: The next thing is to make sure we configured our port to be dynamic I know we already did this, but just in case someone didn't do it, here's your chance to do it Make sure you do that Go to your index file and make sure this is dynamic Okay, make sure this is based off of process.env.port Which if I click on this, it defaults to 3000, but it definitely reads it from the environment variable first

[00:00:00]
So if you hardcode it down and you never changed it, you're not gonna be able to deploy this app, I promise you You have to make that dynamic because you don't know what port you're gonna get when you deploy it You're assigned a port So make sure that's dynamic Never hardcode the port number in production, always use process.env.port Prepare your environment variables This just means wherever your environment variables may be, you know you're gonna need them in production, start collecting them

[00:00:00]
You can put them in a separate file right quick because a lot of providers now allow you to just add a .env file and they'll add them all for you at once, which is kind of cool, but just get all your environment variables that you need Whether you've got Slack or whatever you have to do, go get your environment variables, get ready We have the database URL Whatever other ones we need, get those ready

[00:00:00]
Always create new secure values for production, never reuse development secrets Never There should never be anything that's a secret that you use for development and also production – that is just asking for trouble, so don't do that Also replace any hardcoded instances where you might have put localhost anywhere I don't think we have that anywhere in our app Nope, just in .env and some docs So if like you were doing a redirect to another route and you put localhost:3000 slash, that's not gonna work anymore

[00:00:00]
You hardcoded that – whatever URL you get in production is not gonna be localhost, I promise you, so you need to make that dynamic That provider, in this case Render, will give you an environment variable that will tell you what your URL is so you can access it in your app You just gotta read Render docs to know what the name of that environment variable is But they will give you one Every hosting provider will inject several environment variables into your app to let you know the state of things, so keep that in mind

[00:00:00]
These are just common places where you might have hardcoded the URL: course configuration, email templates, webhook URLs, documentation, frontend API calls – absolutely This was important because Render defaults to a previous version of Node.js in our package.json, which is just one way to do this, but the easiest way is we need to add this engines field to our package.json with Node and its value set to anything greater than 24.3

[00:00:00]
So you just want to copy this engines part right here And you want to go to your package.json, and anywhere on the root, you just want to paste that in there If you don't do that, Render's gonna default to like version 22 or something like that, which is below the minimum which I said you're gonna need So if you don't do that, this won't work because TypeScript doesn't work on Node at that version

[00:00:00]
Make sure you have that The last thing is prepare your main branch And I realized it doesn't have to be your main branch Obviously, if you're going to production and this is a real thing, yeah, you probably would have this on your main branch, but it doesn't have to be For the sake of this exercise, you can put it on any branch that you want You can tell Render where you want to deploy from, but typically it's like main branch

[00:00:00]
A lot of this comes down to your process Maybe your team has a production branch, maybe your team has something else, but typically it is main But you can put it wherever you want If you've been following along with me and having different branches and you're like, "Oh, I don't want to mess up main," that's fine You can make any branch that you want to be the branch that you want to deploy, and then you can tell Render it's that branch

[00:00:00]
Me, I'm not gonna put it on main because I'm cutting branches all over the place I'm probably gonna pick another branch to deploy what I'm about to deploy now, but just get whatever branch you're about to make ready with the code that you want to be deployed Get that branch ready, get ready to push up to GitHub Open up a pull request or push it directly, however it is, just get it on GitHub.