Learn ReactJS - Deployment & Hosting

#Introduction

Good code means nothing if the world can't access it. Deployment is the process of bringing an app from local to server, and for React the options are many: static hosting, serverless functions, even containers. Episode 20 makes you understand when to use which.

We cover the difference between SSG and SPA, hosting options like Vercel, Netlify, AWS, and Firebase, CI/CD pipelines for automation, and environment variables and build-time configuration that keep secrets secret.

#Static Site Generation and SPA Deployment

#The Build Result: A Static Folder

A React app that's built becomes static files: HTML, CSS, and JavaScript that any server can serve. Run a production build and check the result:

npm run build
ls -la dist

The dist folder contains the optimized bundle from episode 19. To test it locally, run the preview server from that build:

npm run preview

#SSG vs SPA

An SPA (single page application) serves one empty HTML file, then runs JavaScript to render the whole page. SSG (static site generation) builds complete HTML at build time. SSG is faster for content that rarely changes; SPA is easier for very dynamic apps.

#Hosting Options for React Apps

#Vercel and Netlify

Vercel and Netlify are built specifically for frontends. Both auto-detect the framework, build the project, and provide a global CDN. The first deploy is just connecting your Git repository:

npm install -g vercel
vercel

vercel guides the first configuration: choose a scope, the dist folder, then get a staging URL. Subsequent commands automatically create production deployments. Netlify offers a nearly identical flow via drag-and-drop of the folder or Git.

#AWS and Firebase Hosting

AWS gives full control: upload the dist folder to S3, serve it behind CloudFront, and add CI/CD via CodePipeline. Firebase Hosting is a quick choice with a single CLI and Cloud Functions integration for the server side:

npm install -g firebase-tools
firebase login
firebase init hosting
firebase deploy

firebase init hosting creates the firebase.json file and asks for the public folder. Fill it with dist and the project is ready to deploy. Choose AWS when you need full control, Firebase when you want fast setup.

#CI/CD for React Apps

#An Automatic Build and Deploy Pipeline

CI/CD runs build, test, and deploy automatically every time code is pushed. Example of a simple flow with GitHub Actions:

name: Deploy
 
on:
  push:
    branches: [main]
 
jobs:
  deploy:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - uses: actions/setup-node@v4
        with:
          node-version: 20
      - run: npm ci
      - run: npm run build
      - run: npx vercel --prod --token $VERCEL_TOKEN

This workflow checks out the code, installs dependencies with npm ci, builds the app, then deploys to Vercel using a token stored in the repository secrets.

#Why CI/CD Matters

Manual deploys are easy to forget and inconsistent. With a pipeline, every change to the main branch goes through the same gates: clean dependency install, a green build, then deploy. This is the same flow your own repository uses with GitHub Actions.

#Environment Variables and Build-Time Configuration

#The VITE Prefix in Vite

Variables accessed by React code must start with VITE_ so Vite exposes them to the code. Other variables are only available to the build tooling. Example .env file:

VITE_API_URL=https://api.example.com/v1
VITE_APP_NAME=BelajarReact

In code, values are read via import.meta.env:

Reading env in code

const apiUrl = import.meta.env.VITE_API_URL

import.meta.env.VITE_API_URL is replaced by Vite at build time with the value from the environment. Important: this value is baked into the bundle, so never put secrets like API keys here — use server-side secrets instead.

#Build-Time Configuration

Because env vars are read at build time, different values mean different builds. For staging and production, provide .env.staging and .env.production files, then specify the mode at build:

npm run build -- --mode staging

--mode staging loads .env.staging and replaces the default production mode. This pattern ensures different API URLs between staging and production without changing code.

#Conclusion

Episode 20 closed the gap between code and the world: understanding the build output, choosing the right hosting, building an automatic CI/CD pipeline, and managing environment variables safely according to the build context.

Key takeaways:

• A React build produces a static dist folder ready to be served anywhere.
• SPA serves one HTML file; SSG renders complete HTML at build time.
• Vercel and Netlify are fast for frontends; AWS and Firebase for specific needs.
• CI/CD runs build, test, and deploy automatically on every push.
• React environment variables use the VITE_ prefix and are read via import.meta.env.
• Don't put secrets in the frontend bundle; env vars are read at build time.

In the next episode, episode 21, we'll cover server-side rendering & frameworks — SSR concepts with Next.js, hybrid rendering and static generation, data fetching patterns in Next.js, and when to choose SSR, SSG, or SPA. Your app will start rendering on the server.