A Step-by-Step Guide to Deploying a React App to Heroku

Heroku is a platform as a service that's been around since 2007, and it supports the deployment of several programming languages, such as Ruby, Java, Node, Closure, Python, etc. Traditionally established to help applications be deployed, Heroku now offers multiple different products, such as their platform tool, their data services tool, which consists of Heroku allowing us to use a Post gres database on the cloud, Redis and Kafka, which are more targeted data- related management tools, there's also their Enterprise tool, which is a targeted solution for enterprises and larger scale companies, and there's even more things Heroku offers as well. And this is to essentially show that Heroku has grown as a more versatile platform to help developers not only deploy code, but help build code as well. We're particularly interested in their platform product, which is to help us deploy and run our application on Heroku's platform as a service solution. This diagram here is a really good, simple, but decent illustration on how deployment within platform actually works. Initially, the developers, and in this example, this means us, will actually deploy the code onto Heroku. When an app is deployed, Heroku runs the app in containers that they call "D inos". These "Dinos" or "Containers" are essentially isolated environments that provide memory, an operating system, a file system, etc, and are the areas that package the applications code and dependencies. The Heroku dashboard gives us information on how our app is running, the number of Dinos that are being used, etc. And with add-ons, we're able to scale our application within the platform by scaling things like the number of Dinos, the number of processes being used, etc. When the user makes a request to the endpoint that Heroku serves for application, the user is then able to actually use the app. Heroku offers a pretty simple to understand pricing plan, and their most primitive plan is free, which is perfect for testing and experimentation. Now, there's a lot of differences between these plans, however, some of the main differences are the number of Dinos and the Dino hours available to us. There's web and worker Dinos, web Dinos are focused more on actually receiving the request from a user, while the worker Dinos within Heroku are focused more on background and time jobs. Heroku offers different Dinos within these plans that each have more different capabilities as the pricing plan increases, and the number of process types available to us also increase. One key thing to remember is that in the free plan, our application would always go to sleep after 30 minutes of inactivity, and it would awake as soon as a user tries to access it again, which takes about 15 seconds or so. And with the free plan, we can only use a set amount of free Dinos hours. Obviously, not perfectly ideal for apps that are to retrieve or receive a large number of requests, but it's perfect for experimenting the deployment of our app onto Heroku. We'll be sticking with the free plan for this lesson, but however, remember, Heroku does provide very simple capabilities to move from one pricing plan to the next when the need is ever there. To use Heroku, you'll need to sign up for an actual account, and you can head over to any of the links that prompt you to sign up or signup.heroku.com. And this is where you can provide your basic information, such as your name, your email address, the role of what you actually intend to do, the country you 're in, and your primary development language. And the good news is, since you're getting started for free, you have to provide no payment information in the very beginning. When you've created your account, you'll get an email verification or verification email, confirm that email sent to you from Heroku, and when you finally log back into your newly created Heroku account, you would most likely land in a page that looks something similar to this, where you're prompted to either create a new app or create a team. Create a new app, which is what we'll be doing in this lesson. And when you begin the app creation process, you land in a page that looks like this. Here, you're able to provide the name of your Heroku app, which is essentially the name of the app you want to give within your Heroku platform, provide any name that you please. It just can't conflict with an existing name, so we'll go ahead and name our Heroku app, TinyHouse Application. We're then asked if you want to choose a region, there's only two regions available, the United States or Europe, we'll stick with the United States region. And though not required, we're told that we can add this app to a pipeline. Now, this pipeline is essentially referring to a continuous deployment workflow . Now, in this context, a pipeline is essentially just a collection of Heroku apps that are the same code base. And the idea behind this is you can set up a continuous delivery workflow, such as having a development stage, a review stage, a staging stage, and a production stage, which is very helpful to manage different environments within an application. Now, this is usually more appropriate when you actually want to scale your application into a larger setup, but in this context, we won't introduce a pipeline and we won't add this app to our pipeline, we'll just continue. Here's where we land on our actual dashboard for our Heroku application. And in this dashboard is where we can see information and statistics of our actual application, such as the overview of the app, the resources, the dyno process types, the add-ons that we may have added, the cost of each of these add-ons, the metrics associated with our TinyHouse deployed application, any activity that's been done, and so far, the only thing it tells us that's been done is we have just an initial release, and Heroku has done something for us, labeled enable log plaques. And there's other things as well, such as providing collaborator access and settings. In the deploy tab, we're given some information on the different deployment methods that we can actually undergo. There's essentially three main methods that we can do. We can use the Heroku CLI or the Heroku command line interface. We can connect directly to a GitHub project, and we can use the container registry option. The Heroku Git or Heroku CLI option is pretty straightforward and essentially involves downloading and installing the Heroku command line interface, logging into your Heroku account within your terminal, creating a new public key, and then basically just having a new Git repository set up and pushing that repository with the Heroku command line onto your actual Heroku application. But connect to GitHub option is very similar, but instead of actually using the command line interface, we can essentially tell the dashboard here to simply connect to a certain repository. And then there's the container registry option, which is a little bit more detailed. However, you can use the Heroku CLI here, and you can simply push or deploy a Docker based app. We're going to go with the approach of trying to connect our Heroku app onto an actual GitHub repository, which is now probably a good time to talk about how are we going to prepare our application, or in other words, how are we going to prepare our client and server applications to have it ready for deployment. In development, we actually have two separate applications. We have the server, which is the node express and TypeScript application, and we have the client, which is the React Webpack TypeScript app. So there's a few things we need to think about, but the very first thing that's important is that both our server and our client are TypeScript projects. TypeScript is unrecognizable, whether within node or within the actual browser. So the first thing we'll have to do, or one of the things we'll have to do, is ensure that both our server and client code are written in plain JavaScript. If we recall, in the very beginning within part one of our course, we've mentioned how both the server and the client have build scripts, which allow us to build the projects into their actual JavaScript formats. So we essentially need to build our apps to have them both be in JavaScript. The other thing to keep in mind is node can be used within our Heroku deployment setup, but React isn't understood in the browser either. The browser doesn't recognize React's API. The build script within Create React app not only builds the TypeScript code to JavaScript, it builds the React specific code to standard HTML, CSS, and JavaScript. The three pieces that any browser actually recognizes. Assuming we've built both of our projects, we'll have both the server and the client now within their native JavaScript format. At this moment, there's a few things we can do to have both of these deployed. One way, we'll be keeping the way we sort of have it in our development environment as we keep both the server and the client apart. And that would involve simply deploying just the node server application, which will essentially just provide the API, and deploying our compiled React application elsewhere. And we'll simply have our React application interact with the deployed API instance. However, another approach would essentially involve keeping them together. And instead of having our node express server just serving the API, we can have our node express server also serve the actual React client application. Okay, now with this high level game plan in mind, let's now conduct the work we 'll need to do to have our server serve the client and API, and have that project now set up as our actual Heroku application. By the time we finish deploying the app at the very end, we'll summarize all the steps we've taken to get to that point. Here, we have both the client project and the server project available in our code editor. We'll create another project folder called tinyhouse-deploy. And this project folder will be the node application that we'll want to deploy onto our Heroku app. We're creating another project folder to represent the deployed app, since the client and server projects are essentially the development applications that we use. When we build and bundle them and then finally have them in the compiled state, we'll make sure to group all of that together within another project folder that will then deploy. In tinyhouse-deploy, let's create a few files to get us started. We'll create a git-ignore file, which is the file responsible, and telling git to which files in our folder can be ignored. We'll simply copy over what we had in our server projects, which involves hiding the node modules, any of the build processes, environment-variable files , etc. We'll then create a package JSON file. And in this package JSON file, for now, we'll keep things simple. We'll just have a name that says tinyhouse-deploy. For version, we'll say something like 0.1.0. We'll say that it's private and we'll introduce only a single script called start. And this script would essentially use the node command to run the contents of the JavaScript file index.js within a source folder that we'll soon have. Cool. Now with our tinyhouse-deploy folder prepared, before we actually start to build our server and client projects and bring them over, there's a few changes we'll need to make. In our server project, we should tell our actual server application which version of node is being used. And the reason being is that Heroku needs to know what version of node is actually running. To accomplish this, in the package JSON file of our server project, we can add an engine's property and then specify a node property and its value. The Heroku documentation states that it's highly recommended to specify the node version that is the same as the version that's currently running in our development environment. And we can check this when we head to our terminal in our server project, if we say node -v, we can see in my development environment, I'm running at 12.4.0. To ensure that Heroku specifies the same version that I'm using in development, we'll declare a version of 12.4.0. So with whatever version of node you're using to develop and test with, be sure to specify that version here. There's another change we'll need to make to our node server project to have it more ready for deployment. We'll want our server project to serve our React client, which essentially would send a copy of the React client whenever a user loads the app in the browser. Since we're interested in doing this, we should use a compression library to compress the files that are going to be served into a smaller size. Oftentimes within the world of compression, the term gzipping is often used, and it's a form of data compression that is performed optimally on text-based assets like CSS, JavaScript, and HTML. And it's incredibly important for web applications since when gzip is implemented, it can compress all the responses, or in other words, data, which can significantly reduce the bandwidth cost of logic aside. And it helps contribute to the user having to download smaller files to have the web app launched. So at the end of the day, this leads to better performance. However, Heroku does not modify HTTP requests and responses sent by the application, and therefore does not implement HTTP compression. And the reason behind this is Heroku leaves this to the application to perform itself. The Heroku documentation does point to different resources where compression can be applied depending on the languages and environment of code being written . With Node, one of the first recommendations is a compression library. Compression is an HTTP middleware built for Node Express applications, and it's built by the Express team themselves. It supports both Deflate and Gzip. Deflate is an algorithm for compression, and Gzip is another algorithm that's built on top of Deflate, and it adds a few additional changes to it. Now, this library does provide the capability to add some modifications and certain options. However, to use it in the most simplest manner is exactly what we'll need to do . All we'll need to do is simply introduce the library, use Express's middleware, and apply the compression function. And this will compress all the responses in Gzip format. So with that said, let's head over to the terminal and in our server project, let's first install the compression library as an application dependency. And as a development dependency, we'll install the type definitions from the definitely typed repository for the compression library. We'll import the compression function from the compression library, and where we declare all our server middleware, we'll specify another middle ware, and simply run the compression function. Okay, so at this moment, let's see how we can have our Express application serve the client static files. When the client code gets compiled eventually to HTML, CSS, and JavaScript, we 'll assume that we're going to place that client code within a directory called client within our server project. So before we even get to that point, let's see how we can serve that content. And to do so, we can use another Express middleware app that I use, and we can declare the express.static function, which is express method for serving static files. And then here we can say that we want to serve the client folder within the root level directory. To ensure that we're going to reference a client folder that's contained within the root level, we can use the underscore, underscore directory name property and note that essentially references the absolute path of the directory. And the next thing we're going to do is we're going to essentially tell our express server that when any request is made, we want to serve the index HTML file that's going to be contained within the client folder. And to do this, what we can do is say, when I get request is made, and we can specify a wildcard operator to say that for any request, we simply want to send a certain file. So from the response, we can use the send file function. And then we can try and reference the index HTML file within the client project that's kept within our root directory. This line here essentially states that regardless of what route the user hits, the client is going to serve and show the same index file. Why? This is because our tiny house application is a single page application. Regardless of what route the user hits, the client will have the same index file. However, our client will then take the responsibility to determine which content to show with the JavaScript depending on which route the user is in. This is an essence, the definition of a single page application, which is different from server rendered applications. Server rendered React applications would hold the responsibility in serving different index files depending on the route the user hits. Now there's advantages and disadvantages with both approaches. For single page application, things are usually a bit more smoother, while for server rendered application, oftentimes, it's better for search engine optimization, etc. Another thing to quickly note. Remember when we first started to look into how we can have the client make request to our server, what we did is in our package JSON file of our React application, we specified a proxy, which essentially helped allow our client app to proxy requests to our server application. Now keep in mind, this is only for development, particularly for our use case. Why? Because when we actually conduct deployments, we're going to deploy a single application. And when the client starts to make requests to an API path, it's essentially going to reference the path within the application. So that proxy is pretty much useless when we actually deploy it. However, we'll need it for development, and there's no harm in keeping it within the actual client package JSON file. Now next, we don't actually need an environment file in our built server application. The reason being is that Heroku would actually declare all the environment variables at runtime. So with that said, we can remove the require.env.config function at the very top of our server index file. On the topic of environment variables, we've introduced some environment variables in our React client application. And this was the client ID, as well as the publishable key for our actual Stri pe environment setup. Now, it's important to remember this, the environment variables within our React client application is different from the way it's handled in our server application. When we build our React client project, React actually simply takes these values and directly places them in our code. With that being said, this is why the environment variables within our React app should never really be secrets. These are simply values that are sort of environment configuration variables that are given to us. And maybe we might use in many different areas, but they're not necessarily secrets, and we don't necessarily need to keep them private. We'll leave these environment variables as is for now. We just have to keep in mind that when we build our client project, they'll be injected into our compiled client code. However, in our server environment variables, we'll need to think about a way of adding the environment variables from Heracou's end, and we'll do that at the end. Now, with that said, let's begin the build process. We'll head to the terminal, and in our server project, we'll run the npm run build command we have in our application scripts. And this will build the node TypeScript code and compile it into valid JavaScript. If we take a look at our code and we look at the server project, we'll now see a build folder that exists that contains our entire server project code, but now in JavaScript. Great. Next thing we'll do is we'll head back to the terminal, and in our client project, we'll run the npm run build command. And not only will this compile the TypeScript code to JavaScript, it would compile the React development code as well, to get only valid HTML, CSS, and JavaScript. This would take a little bit longer than the build script for our server project for a few different reasons. Our client app is a lot larger. We're actually compiling the React code as well as the TypeScript code as well. If we now take a look at our code and in our client project, there would exist a build folder in the root level directory that create React app has produced for us. And it contains many different things. Service worker information that we don't really take into account in our React application. There's the static assets, which is the media, the JS, the CSS code. And there's the root index HTML file. And this is the root index file that we want our express server application when built to serve on every single request that is made. Okay. So with these build folders now both existing within our client and server projects, what we're going to do is we're going to move this build folder in our client directory into the build folder within our server projects . And we'll rename it to say client within the build of our server. So now within the build of our server when any request is made, it's going to serve and send the index HTML file within the client project in the root level directory. The next thing we're going to do is we're going to move now this build folder within our server project. And we're going to move it over to the deploy directory we've set up earlier. And this build folder will now be called source. This source folder will be the entry point of our actual node deployed application. And when Heroku is to run the start script available in our tiny house deploy directory, it's going to run the index JS file of the source folder, which is the entry point to our express server application. And this is all the compiled code. And in this compiled code, it will not in reference that when any request is made, it will simply interact and return the index HTML file within the built client code. And now a few more things will need to make sure we have in our package JSON file here. We've specified the node version in our actual server directory. But it's more appropriate to do so here, since this is the actual project code that we're going to deploy onto Heroku. So with that said, we'll declare the engines field. And then within, we'll say that the node version is 12.4.0 to match the development node environment I have. Next, we'll need to tell the actual node application that we're going to deploy what dependencies it's going to need. And to do this, we can simply copy over all the dependencies we have in our server project and simply directly place it in the package JSON file of the node app we want deployed. We don't need the development dependencies. Why? Because these are development specific. There are all the type definitions files that we need to use for our TypeScript development code. There's the ESLint.env/nodemon/tas/node-itilities. None of these are actually necessary for production. We're simply going to need the actual dependencies that our deployed code is going to need to access. When we deploy our app onto Heroku, what Heroku actually determines when it needs to start our app is it looks for something known as a proc file. The proc file within Heroku's context is essentially a file that specifies the commands that need to be run by the app on startup. We don't have this proc file, and we won't need to. Because next, if it doesn't exist within a node application, Heroku would attempt to start a web process via the start script in our package JSON file, which is what we have. This is why we specify the start script to run the starting point of our actual source directory, which is the express app, which will then serve our React client application and the actual API requests. And that's it. Our tiny house project directory should now be ready to be deployed. When we head to the Heroku dashboard for our actual Heroku app that we've created, TinyHouse application, in the deploy section, when we select connect to GitHub as a deployment method, we can now try to connect our Heroku app with an actual GitHub repo. Now do keep in mind, when you first see this section connect to GitHub, you may be prompted to actually provide an account where then you have to actually provide the OAuth permissions that Heroku requires, and only then will you actually get to this point where it tells you that you can simply search for a repository within a certain account. With that said, we now need to have the code we prepared now actually pushed up to GitHub. Now Git, well something we didn't talk about in this course, and we've mentioned in the syllabus that it's one of the required or hopefully required skills that people already know. And we only actually need to concern ourselves with Git at this moment in time. There's a very quick explanation. Git is essentially just a version control system that helps control the flow of code being pushed. It can be used for both small and very large projects. There are many different hosting providers that exist, GitHub, Bitbucket, etc. But we're going to be using GitHub, which is primarily what we always tend to use, and is what Heroku supports. So here, we're going to attempt to create a new repository that is essentially connected to the accounts that is connected to our Heroku app. And we'll give this repository the same name that we gave our project directory . Tiny house deploy, we won't do anything for the description. We can have this be kept as a public repository. And we won't initialize it at first and we'll simply just create it. While here, we'll simply head over to the settings for this particular repository. For collaborators, I'll attempt to give my personal GitHub profile collaborator access where they'll be able to push code into this particular repository. By accessing the confirmation email and approving it from my profile side at this moment in time, now this particular GitHub profile is able to push to this tiny house deploy repository. The only reason why I provided my personal account access is because in my terminal setup, I've already authenticated and initialized with Git. So at this moment, what I can do now is simply within the terminal navigate to the new tiny house deploy folder we set up. And we can follow the instructions that GitHub gives us to essentially create a new repository. So we can just essentially create a brand new read me file to just simply say tiny house deploy. We can initialize a new Git repository with Git init. We can add all the contents we have in this repository. So at this moment in time, if I said get status, I'll see the get ignore file, the read me the package is on and the source folder. So I'll add everything, get add dot. And I'll simply commit my work here. So as I get commit first and deployed code and everything will now be committed . And when committed, we can simply add the remote origin and we just simply copy what's given to us here. And finally, once added, we can now push directly to the master branch. Heading back to the actual repository, refreshing it now, we'll see the actual deployed code up on GitHub. Now, the steps we've taken to get to this point is completely up to you. The main takeaway is just to simply get the code you have in your local environment up to GitHub. You can add it as a file navigator, you can use the terminal, you can authent icate with Git, et cetera. It's completely up to you, but we just simply wanted our code now available in GitHub. And we've done so here under the account of tiny house -dev. And now with that said, we'll head back to the actual dashboard for our Heroku app. And we'll search for the repository we've just created in our tiny house, the dev organization, and that is tiny house -deploy. It tells us that if finds a particular repository, we'll click connect. And when connected, it actually gives us options in how we want to conduct our deployment. We can enable automatic deploys. And this is fantastic because now in every push to the branch is made, it will simply automatically conduct and trigger a deployment. So it's automatically triggered to the fact that when a push is made, it would make that change. Obviously, this is important to keep in mind if you actually go with this approach, to always use a branch that has an appropriate process of accepting pull requests from people and finally merging into that branch to avoid the case where a push ever is made, and it breaks the deployed application. In this context, we won't do any automatic deployments, and we'll see a simple manual deployment. And we'll see that the only branch we have available is master at this moment, so we'll simply click the deploy branch button here to deploy the master branch from our GitHub repo onto this Heroku application. And when that's done, it actually gives us logs to see what Heroku is actually doing in this case. It tells us that it's specifying the runtime environment, it detects a node.js app, it's installing the dependencies, pruning the dev dependencies, if they exist, it caches the build, it says build succeeded, it's compressing all the work that we've set up. It's finally launching, and then it tells us it released and it's been successful. When we've deployed our branch, what Heroku has essentially done is taken a copy of the code in our GitHub repo and it's uploaded it onto their servers. And then Heroku then installs the dependencies in the package JSON file of our node application, and then it automatically runs the npm start script to start and deploy our app onto the cloud. And once deployed, we can actually view the deployed application by navigating to the link tinyhouse deploy dot Heroku app dot com, or simply clicking this view button here. Boy, not tinyhouse deployed dot Heroku app, tinyhouse application dot Heroku app, because that piece of the actual URL is the name of the Heroku application we 've given. However, in this case, we see an error and tells us application error. The reason being is Heroku's failed to start our application because it actually crashed during the deployment process. The reason why this error occurs is because we've forgotten a significant piece that we've omitted just yet, and that's because we actually haven't specified the environment variables for our actual server project. To do this in our tinyhouse application, Heroku dashboard, we can go to the settings tab, and then we can click the reveal config vars button within the convict vars section. And this section, according to the documentation here, tells us it changes the way our app behaves. And in this context is where we can specify the actual environment variables during the Heroku runtime process. So here's the environment configuration file for our local server project, and we can primarily copy almost all of these keys and values, except for two. We won't need the port key, which is what we use in development to say that we want our server to run in port 9,000. That will be a value provided by Heroku by default, and we won't need the node_ environment key, which Heroku would also provide a default value for production. But everything else, from the database information to our Google client information, our geocode key, our Cloudinary information will all be copied. One change we'll make, however, is in the public URL key, instead of referencing the local development public URL localhost 3000, we'll be sure to specify our actual deployed URL, which would be https.tiny houseapplication.herokuapp.com. When all the keys we've mentioned have been transferred over and copied within this section of our tinyhouse application dashboard, this will look something like the following. There's one other significant change we're going to need to make. If we recall, when we've retrieved or obtained the credentials for Google OAuth , as well as our Stripe authentication, we've always specified in either of those cases within their dashboards a redirect URL of our local development environment, localhost 3000. This wouldn't work in production. So what we're going to need to do is go to the organization for our Google Cloud Developer Console, as well as our actual Stripe dashboard, and we need to change the redirect URL to reference the actual URL path of our deployed client application, which will be https.tinyhouseapplication. herokuapp.com. We can begin with our Google Cloud Platform. So in our Google Cloud Platform for actual tinyhouse organization, when we head to the client ID within our credential section of APIs and services, this is essentially the client information to actually specify the OAuth setup. Here we have authorized JavaScript origins and the redirect URL that reference the local development environment. We could add extra values here, but what we would do and what we prefer to do is simply remove these values and simply introduce the new ones that we want to specify, such as tinyhouse application.herokuapp.com It gives us a message that says this domain must be added to the authorized domains list before submitting. So we'll go ahead and do that. So it'll take us back to the OAuth consent screen section. We'll scroll down a little bit. Here's the authorized domain section. We'll add this domain. It tells us that it must not specify their protocol, HTTP or HTTPS. We can do that. So we'll just simply say tinyhouseapplication.herokuapp.com. Once that's done and available, we'll click Save. When that's saved, we'll head back to the web client section for the actual ID. And it will update these to reference the new locations. And instead of saying localhost3000/login, we'll update this to say tinyhouse application.herokuapp.com/login. And we'll save our changes here. Next, we'll head over to the Stripe dashboard for actual Stripe Connect account . We'll go over to the Settings section. And in the Settings Connect Settings section, we'll see information about our client ID as well as the redirect URI that we 've specified. Once again, we like to stick with a single URI and not add multiple. So we'll remove the old one we had that said localhost3000/stripe. And simply add a new URI that says HTTPS, tinyhouseapplication.herokuapp.com/ stripe. And now we'll have this URI reference, this credential that we've installed and used within our client as well as server projects elsewhere. Now, before we proceed, there's two important notes to make. The first is pretty recognizable. And you can see that we've updated the redirect URI's for the credentials that we're basically going to use within our deployed application. However, these credentials are also being used in our local development environment. So at this moment in time, if I was to start my node server and React client application and development, and I tried to proceed to log in through Google or authent icate with Stripe, it would error out. The reason being is we've updated the URI's to now reference the production URLs. This is why we as a preference like to actually produce separate credentials for both development and production. And in this context, this can look like having another Stripe organization account, one for development and one for production with their own separate keys. And similarly for Google, we can create another Google client ID and secrets, one for development and one for production. It's completely up to you. In this context, if we stick with this format and you want to keep all these keys in development, you'll have to bring this back into the local setting and point to the local URI's and then change it back to production in multiple times. However, when you're actually ready for your application to be in production, it isn't preferable to be using the same keys. So we'll strongly advise you to make sure you produce new client IDs and secrets and credentials for production settings. That's different for development. The other thing that's important to note here is in Stripe, we're actually using the test credentials, right? This basically means that when we actually deploy our application, if we wanted a user to pay with their Stripe information or pay with their payment information, they 'll provide fake data for actually for it to proceed. If you're ready for your development to actually be ready for production and you want users to start to pay out with their actual payment information, you can no longer use this test credentials given to us. You'll have to disable viewing test data and then now actually introduce all the client ID and credentials that is necessary for production. To do that, you may need to activate your account, complete your platform profile, et cetera, et cetera. In this context, we'll stick with using the test credentials Stripe gives us just so we can verify that it works in production setting. The good news is once we're ready to receive actual payments, apart from actually activating our connected account, et cetera, the only other thing we 'll sort of need to do is just take the secret and publishable key and make sure we update the config variable we pass in in our Heroku dashboard. And that's the straightforward part and that sticks with the Google key as well. The other thing we need to keep in mind is that in our React client, we have two keys that we actually retrieve from the Stripe account, the client ID and the publishable key. And these are primarily used to actually conduct and create the Stripe element as well as to verify that we're going to be redirected to the correct path slash stripe of the authentication. Now keep in mind, this environment configuration variables aren't being passed in from a Heroku dashboard. They're part of our React client application. And when our client app gets compiled, create React app simply just takes these values and places them in the code. So once we're ready to actually conduct and accept real payments, we'll need to update these keys before we build our client project. And then for the secret key, we just simply need to update the environment configuration variable we declare and pass in in Heroku. Amazing. At this moment in time, everything we 've prepared should now be ready for actual deployment. At this moment, if we were to actually open up the Heroku application, it would most likely work. However, just in case we perhaps need some of these environment configuration keys during deployment, though I don't think we do, we'll just do another deployment manually. And the good news is it 's incredibly straightforward and quick. So we'll go back to our actual deploy section. We'll click deploy branch for the master branch. And we'll wait for a minute or two until the deployment is made complete. And now finished. If we were to launch the application, we can do so with this button available to us. Our application is now fully deployed. We did it. We've actually managed to fully build and deploy the tiny house application. Now, for anybody else who wants to see our app, all we need to do is share this URL with them. And they'll be able to log into our app, create listings, and even book listings of their own. Go.