Guidelines for Deploying React
Figuring out how and where to deploy React can be pretty confusing. A common question for newcomers from other frameworks is "where does React run?", while others wonder what the best practices for deploying React to production are.
Let's clear up some of that confusion.Table of Contents
When using create-react-app, you trigger a React build by running
npm run build or
yarn build. The output you'd see looks like this:
We call these static files. When building client-side rendered apps (such as when using create-react-app), we only need to worry about where to host these files. Server-side rendering or SSR (running a server that generates the HTML the users see as they request it) also uses these files, but that's for a future article to cover.
Static files are awesome because you technically only need a file host to upload them to, in order to deploy your app. I say technically, because when we deploy to production, we typically also want a CDN and HTTPS to make our app fast and secure around the world.
In short, if you're using create-react-app, React runs in your user's browser. Your static files get sent to them when they visit your app's URL.
There are two routes to deploying a React app on the internet:
Having worked for some old-school engineers who wanted to be able to see all of the magic before they trusted it, I basically learned how to build React apps while DIYing all of the infrastructure, and CI/CD.
Scaling the client-side part of React isn't particularly challenging: the key to not going offline during high load is a decent CDN, and good caching settings.
To DIY your React production setup, you'll want to:
- Choose a web host
- Choose a CDN provider (particularly one that provides free HTTPS)
- Choose a DNS provider
- Set up CI/CD
- (not mandatory, I've worked with very small teams that would just use package.json scripts to test and deploy their apps)
These days, I wouldn't particularly recommend small teams use the DIY approach. Your engineers' time is better spent building features or writing tests. God help you if you decide to deploy to Kubernetes before achieving product-market fit.
In my case with the old-school engineers, we had to support government clients, so we wanted to configure every part of the system by hand (via terraform), and to know exactly where our code was being deployed to. We ended up going with AWS to handle hosting (S3), CDN (CloudFront), DNS (Route 53), and CI/CD (Self-hosted Jenkins on AWS).
Setting up a project with them is as simple as logging into the platform, authenticating to GitHub, picking a repo, double checking the default settings are correct, and hitting "Done".
For that, you automatically get:
- CDN with free HTTPS
All that's left to do is point your DNS records to the platform.
You also get access to serverless functions, though limited compared to running directly on AWS.
The other day I setup useEffectByExample.com on Vercel. It took me about two hours total from completely new Next.js app to deployed production-grade React app. Roughly two minutes of which were spent setting up Vercel.
(Shameless plug for the React app I'm working on below)
Knowing your React app is still online can be a pain
The React apps we build are the engines that run businesses, so it's a pretty big deal if they break. OnlineOrNot automatically checks your React app as often as every 60 seconds to see if everything is still working as expected.
OnlineOrNot isn't just for React though - it lets you keep track of your whole web presence, from your marketing website, to the React frontend, all the way back to the API sending it data.
You get sent alerts via Slack, Discord, Email, or SMS when things break, before your users notice - start monitoring for free.