How to Deploy a React App on Vercel: Step-by-Step Guide

A React project that works on your computer is not yet available to other people. Learning how to deploy a React app on Vercel closes that gap: Vercel builds the project in the cloud, publishes the production files, and gives you a public URL.

For a standard npm-based project, the quickest reliable route is to push the code to GitHub, import the repository into Vercel, confirm the detected build settings, add any environment variables, and select Deploy. A Vite project normally uses npm run build and produces a dist directory. An older Create React App project normally produces a build directory.

Once the repository is connected, future pushes can create new deployments automatically. Vercel also gives non-production branches their own preview URLs, so you can test changes before they reach the main site.

The initial deployment often takes only a few minutes. The parts that deserve more attention are production builds, client-side routing, environment variables, API access, and choosing the correct root directory.

Table of contents

1. Before you deploy: know what Vercel will build

2. How to deploy a React app on Vercel with GitHub

3. Confirm the React Vercel build settings

4. Add environment variables safely

5. Make client-side routes survive a page refresh

6. Verify the deployment before sharing it

7. How updates and redeployments work

8. Troubleshoot common Vercel React deployment errors

9. Details that become important after the first deployment

10. Frequently asked questions (FAQ)

11. When plain Vercel React hosting is not the right fit

Before you deploy: know what Vercel will build

React itself does not define how a project must be built. That job belongs to the framework or build tool used by the project.

Open your project’s package.json file and inspect the scripts and dependencies sections. A typical Vite project contains a build script similar to this:

{
  "scripts": {
    "dev": "vite",
    "build": "vite build",
    "preview": "vite preview"
  }
}

An existing Create React App project usually contains react-scripts:

{
  "scripts": {
    "start": "react-scripts start",
    "build": "react-scripts build",
    "test": "react-scripts test"
  }
}

This distinction controls the output directory and environment-variable syntax used later.

Vite is the main example in this guide because it is common for client-side React projects. Create React App can still be deployed, but React has officially deprecated it for new projects and recommends using a framework or a current build tool instead. Existing CRA applications continue to work in maintenance mode, so you do not need to migrate an otherwise stable project solely to deploy it. See React’s explanation of the Create React App deprecation.

Check the project locally first

Open a terminal in the folder containing package.json and install the dependencies:

npm install

Start the development server:

npm run dev

For a Create React App project, use:

npm start

Confirm that the application opens without obvious browser-console errors. Then test the production build:

npm run build

This command is more important than the development server test. Development mode can tolerate situations that stop a production build, including unresolved imports, filename-case mistakes, missing dependencies, and certain type-checking errors.

For Vite, a successful build normally creates dist. You can inspect that build locally with:

npm run preview

If npm run build fails on your computer, fix it before attempting deployment. Vercel will run essentially the same build process, and moving it to the cloud will not correct an application-level error.

Prepare the repository

Your repository should contain package.json, application source files, public assets, and a lock file such as package-lock.json. The lock file helps Vercel install the same dependency versions you tested locally.

Files that contain local secrets or generated output should not be committed. A basic .gitignore for a Vite React project might include:

node_modules
dist
.env
.env.local
.env.*.local

For Create React App, replace dist with build if it is not already ignored.

Do not assume that ignoring .env automatically places its values in Vercel. You will add required variables separately in the project settings.

How to deploy a React app on Vercel with GitHub

Vercel supports Git-based deployment workflows. Its Git integration can build connected repositories after branch pushes and create preview deployments for proposed changes. The official Vercel Git deployment documentation covers supported providers and the wider workflow.

The instructions below use GitHub, but the main process is similar for GitLab and Bitbucket.

1. Push the React project to GitHub

If your code is not yet in a Git repository, open the project folder and run:

git init
git add .
git commit -m "Prepare React app for deployment"
git branch -M main

Create an empty repository on GitHub. Do not initialize it with another README or .gitignore if those files already exist locally.

Connect your local project to the new repository:

git remote add origin https://github.com/your-username/your-repository.git
git push -u origin main

Replace the example URL with the URL of your GitHub repository.

If the project is already connected to GitHub, commit your latest changes and push them normally:

git add .
git commit -m "Update app before deployment"
git push

Open the repository on GitHub and confirm that package.json and the source files are present. Also make sure no .env file or private credential was accidentally committed.

2. Sign in to Vercel

Go to Vercel and create an account or sign in. Using your GitHub account is convenient because Vercel will need permission to access the repository.

When GitHub asks which repositories Vercel may access, you can permit all repositories or select only the project you intend to deploy. For a private repository, Vercel must have explicit access before it can import the code.

3. Import the GitHub repository

From the Vercel dashboard, create a new project and choose the repository from the import list.

If it does not appear, check that:

1. You are viewing the correct GitHub account or organization.

2. The Vercel GitHub integration has access to the repository.

3. The repository has been pushed successfully and is not empty.

After selecting the repository, Vercel opens the project configuration screen.

4. Choose the correct root directory

For a repository containing only one React app, leave the root directory at its default.

The choice changes when the repository contains several applications. Consider this structure:

company-project/
├── api/
├── documentation/
└── web/
    ├── package.json
    ├── src/
    └── vite.config.js

Here, web is the React project. Set the Vercel root directory to web, because that is where Vercel should install dependencies and run the build command.

A wrong root directory commonly produces messages about a missing package.json, an unavailable build command, or an output directory that cannot be found.

5. Review the detected framework

Vercel normally detects Vite or Create React App from the project dependencies. For a regular Vite application, the framework preset should be Vite.

Automatic detection is useful, but verify it instead of treating it as proof that every setting is correct. A custom build script, unusual folder structure, or migrated legacy project may require an override.

The expected settings for a standard Vite React project are:

Framework Preset: Vite
Install Command: Automatically detected
Build Command: npm run build
Output Directory: dist

For Create React App, the normal output directory is:

build

Vercel’s build configuration guide explains how framework presets, build commands, root directories, and output directories interact.

6. Add required environment variables

If the app depends on values such as an API base URL, add them before deploying. Expand the Environment Variables section, enter each name and value, and choose the environments where it should apply.

Do not add a variable just because a local .env file exists. First confirm that the application actually reads it and that the name uses the syntax required by the build tool. The environment-variable section later in this guide explains this in detail.

A basic static portfolio or practice project may not need any variables.

7. Start the deployment

Select Deploy. Vercel will clone the repository, install its packages, run the build command, and publish the generated output.

You can watch the build log while the deployment is running. A successful result includes a generated Vercel URL similar to:

your-project-name.vercel.app

Open that URL. Your React website is now publicly accessible, but it still needs a proper production check before you share it.

A simple deployment example

Suppose a beginner has a Vite portfolio with three components, local images, and no API. Its npm run build command succeeds and creates dist.

Vercel detects Vite, runs the existing build script, and publishes dist. No environment variables or custom configuration are required. This is the ideal zero-configuration case.

The example demonstrates an important point: a straightforward React website should not need deployment-specific JavaScript changes. If a tutorial asks you to rebuild the application structure merely to host a basic Vite project, pause and verify whether that extra configuration is actually necessary.

Confirm the React Vercel build settings

A build setting tells Vercel how to transform source code into files that browsers can use. Four settings account for most deployment successes and failures.

Framework preset

The framework preset supplies sensible defaults for the detected tool. Select Vite for an ordinary Vite project. Select Create React App only for an existing CRA application.

If the preset is wrong, Vercel may use an unsuitable build command or look in the wrong output directory.

Install command

For a normal npm project, the automatic setting is usually appropriate. Vercel can identify package managers from repository lock files, so retain the lock file that belongs to your chosen package manager. Its current package-manager documentation explains the detection and override options.

Avoid committing several conflicting lock files, such as package-lock.json and yarn.lock, unless the repository structure intentionally contains separate projects. Conflicting files make it harder for both people and deployment tools to understand which package manager owns the project.

Build command

The usual command is:

npm run build

That command executes the build script in package.json. If your project needs a different command, confirm that it works locally before entering it as a Vercel override.

Do not enter npm run dev. A development server is designed for local coding, not for generating optimized production files.

Output directory

Vercel publishes the files created by the build. For a default Vite app, that directory is:

dist

For a default Create React App project, it is:

build

If vite.config.js changes the build output, the Vercel setting must match it. For example:

import { defineConfig } from 'vite'
import react from '@vitejs/plugin-react'

export default defineConfig({
  plugins: [react()],
  build: {
    outDir: 'public-app'
  }
})

This project produces public-app, not dist. Vercel must publish public-app or it will report that the expected output directory does not exist.

In practice, unnecessary overrides cause many failures. If Vercel correctly recognizes an ordinary Vite project, keep the defaults unless you have a specific reason to change them.

Add environment variables safely

Environment variables let the same code use different configuration values in local, preview, and production environments. A typical example is an API URL.

For a Vite app, a browser-accessible variable might be:

VITE_API_BASE_URL=https://api.example.com

The React code reads it through import.meta.env:

const apiBaseUrl = import.meta.env.VITE_API_BASE_URL

fetch(`${apiBaseUrl}/products`)
  .then((response) => response.json())
  .then((products) => console.log(products))

Add the same name, without changing its spelling or capitalization, in the Vercel project’s Environment Variables settings.

Vite exposes variables beginning with VITE_ to client-side code. That also means their values are included in the browser bundle and can be inspected by users. The Vite environment-variable documentation explicitly warns that VITE_* values must not contain private secrets.

An API base URL or public analytics identifier may be suitable. A database password, private API key, service-account credential, or payment secret is not.

Sensitive operations belong on a trusted backend or server-side function. Hiding a secret behind an environment-variable name does not secure it when the value is compiled into JavaScript delivered to the browser.

An older Create React App project uses a different convention:

REACT_APP_API_BASE_URL=https://api.example.com

It reads the value like this:

const apiBaseUrl = process.env.REACT_APP_API_BASE_URL

Do not mix the two conventions. REACT_APP_API_BASE_URL will not automatically become import.meta.env.VITE_API_BASE_URL after migrating to Vite.

Production and preview values are separate decisions

Vercel allows environment variables to target different deployment environments. Your production application might use:

https://api.example.com

A preview branch might use:

https://staging-api.example.com

This separation prevents experimental code from changing real customer data. It is especially important for dashboards, payment flows, authentication, email services, and administrative tools.

Changes to an environment variable do not retroactively change an existing build. Create a new deployment or redeploy after editing a value. Vercel confirms this behavior in its environment-variable documentation.

Make client-side routes survive a page refresh

A single-page application can appear to work correctly until someone refreshes a nested URL.

Suppose React Router defines these pages:

/
/about
/dashboard

Clicking from / to /dashboard works because React handles the navigation inside the browser. But entering /dashboard directly causes the hosting platform to request a physical file at that path. A static Vite build does not normally contain a /dashboard file, so the request may return a 404.

Vercel’s Vite deployment documentation identifies this deep-linking issue for Vite single-page applications.

For a static SPA that uses browser-based client routing, add vercel.json in the project root:

{
  "$schema": "https://openapi.vercel.sh/vercel.json",
  "rewrites": [
    {
      "source": "/(.*)",
      "destination": "/index.html"
    }
  ]
}

Commit and push the file. Vercel will create a new deployment.

The rewrite serves index.html for application routes, after which React Router reads the URL and renders the correct page.

Test the behavior by opening a nested page directly in a new tab and refreshing it. Clicking links from the homepage is not enough to verify deep linking.

Do not copy this catch-all rule blindly into a full-stack framework project or a project with more complex server routes. Next.js, React Router framework mode, and applications using Vercel Functions can have different routing requirements. The configuration above is intended for a static React SPA whose routes are handled in the browser.

Verify the deployment before sharing it

A green deployment status means the platform completed its build and publishing process. It does not prove that every feature works in a user’s browser.

Open the production URL in a private or incognito window. This reduces the chance that a local login session, browser cache, or extension hides a problem. Then complete this short check:

• Load the homepage and inspect the browser console for errors.

• Open every important route directly and refresh it.

• Test forms, authentication, API requests, and file uploads.

• Confirm that images, fonts, icons, and favicons load.

• Check the layout on both desktop and mobile widths.

• Verify that production data and environment variables are correct.

• Test a fresh session instead of relying only on an existing login.

The browser’s Network panel is particularly useful. A page may render while an API call quietly fails with a 401, 404, CORS error, or mixed-content warning.

Add a custom domain after the Vercel URL works

Do not introduce DNS configuration while the application itself is still failing. First verify the generated .vercel.app address.

Then open the project’s domain settings and add the domain or subdomain you want to use. Vercel will show the DNS record required for the domain’s current configuration. Add that record at the provider responsible for your DNS, then return to Vercel to check verification.

Follow Vercel’s current custom-domain setup documentation because the correct DNS values depend on whether you are connecting an apex domain, a subdomain, or Vercel-managed DNS.

How updates and redeployments work

After Git integration is configured, deployment becomes part of the normal development workflow.

A push to the configured production branch creates a production deployment. A push to another branch generally creates a preview deployment with a separate URL. Pull requests can therefore be reviewed in a live environment before they are merged.

A typical update looks like this:

git add .
git commit -m "Improve contact form validation"
git push

Vercel receives the new commit and starts another build. When the production deployment succeeds, the project’s production domain points to the new version.

This workflow is safer than uploading files manually because each deployment is associated with a particular commit. If a change breaks the site, you can identify which revision introduced the problem and use Vercel’s deployment history to inspect or restore a previously working deployment.

Preview URLs need realistic configuration

A preview deployment is most useful when it can actually run the feature being reviewed. If the app requires an API URL but that variable exists only in Production, the preview may load a blank page or fail on every request.

At the same time, copying all production credentials into Preview can be risky. A visual test branch should not accidentally send real emails, charge real payment methods, or modify production records.

Treat Preview as a genuine environment. Give it the variables and services it needs, but point sensitive workflows to staging or test systems where possible.

Deploy from the command line when Git is not appropriate

Git-based deployment is the better default for beginners because it creates a clear change history and automatic redeployment workflow. Vercel also provides a command-line interface for manual and scripted deployments.

From the project directory, you can run:

npx vercel

Follow the prompts to link or create a project. To request a production deployment, use:

npx vercel --prod

The CLI is useful for testing deployment configuration or integrating Vercel into a custom release process. It should not become a substitute for committing important source changes to version control.

Troubleshoot common Vercel React deployment errors

Most failed React deployments can be traced to one of three stages: dependency installation, the production build, or the application’s browser runtime. Identifying the stage prevents random configuration changes.

Vercel’s build troubleshooting guide recommends using build logs as the primary evidence when a deployment fails.

The build command exits with an error

The clearest warning sign is a failed deployment accompanied by a stack trace in the build log.

Run the same command locally:

npm run build

Read the first meaningful error rather than the final generic “build failed” line. Common causes include an imported file that was not committed, a dependency missing from package.json, incompatible package versions, or a TypeScript error.

Filename capitalization deserves special attention. A component imported as:

import Header from './components/header'

will fail if the actual file is Header.jsx and the build environment treats capitalization strictly. The same project may appear to work on a case-insensitive local filesystem.

Correct the import or filename, commit the change, and push again.

Vercel cannot find the output directory

This error means the build either failed to create output or created it somewhere other than Vercel expected.

Check the end of the local build output. For Vite, confirm that dist appears. Then inspect vite.config.js for a custom build.outDir value.

If the build produces dist but the dashboard expects build, correct the Output Directory setting. If it produces nothing, the output-directory message may be a secondary symptom of an earlier build failure.

The deployment succeeds but displays a blank page

A blank page is usually a browser runtime problem, not a hosting failure. Open Developer Tools and inspect both Console and Network.

Common causes include an undefined environment variable, a JavaScript exception during startup, missing assets, or a base path copied from another hosting platform. For example, a Vite project previously configured for a repository subpath may contain:

export default defineConfig({
  base: '/repository-name/'
})

A Vercel site served from the domain root generally does not need that repository-specific prefix. An incorrect base can make JavaScript and CSS requests point to nonexistent paths.

Nested routes return 404 after refreshing

If navigation works inside the app but refreshing /dashboard returns 404, the issue is server-side route resolution. Add the SPA rewrite described earlier, commit it, and deploy again.

If the project uses a full-stack React framework rather than a static Vite SPA, follow that framework’s Vercel routing instructions instead.

Environment variables are undefined

First verify the variable name and syntax.

A Vite browser variable requires the permitted client prefix and must be read from import.meta.env:

import.meta.env.VITE_API_BASE_URL

Next, confirm that the variable was assigned to the environment being deployed. A value added only to Production will not necessarily be available to a Preview deployment.

Finally, redeploy. Changing the dashboard value without producing a new deployment leaves the existing JavaScript bundle unchanged.

The API works locally but fails on Vercel

Inspect the actual request URL in the browser. A frequent mistake is deploying code that still calls:

http://localhost:3000

For a visitor, localhost means the visitor’s own device, not your development computer.

Use a deployed HTTPS API URL through an environment variable. If the address is correct but the browser reports a cross-origin error, the API server must allow requests from the Vercel production and preview origins. This guide to fixing CORS errors in React explains how to distinguish an API access-policy problem from a React or hosting problem.

Also check for mixed content. A page loaded over HTTPS may be prevented from requesting an insecure HTTP endpoint.

Details that become important after the first deployment

The first successful URL can make deployment seem finished. In reality, several choices determine whether the setup remains predictable.

A successful build is not the same as a healthy application

Vercel can publish a valid bundle even when the application cannot authenticate, reach its API, or load required configuration. Build logs explain build-time failures; browser tools expose client runtime failures.

Use both. Repeatedly changing the Vercel framework preset will not fix a CORS policy or an invalid production API response.

Environment values belong to the deployment that used them

For a client-side Vite app, browser-visible environment values are inserted during the build. They are not fetched afresh from the Vercel dashboard every time someone opens the site.

This explains why redeployment is required after a variable changes. It also means an old preview URL may retain an older configuration even after the project settings have been edited.

Repository structure becomes part of deployment configuration

Moving a React app from the repository root into frontend/ changes where Vercel must find package.json. If the Vercel root directory remains unchanged, the next deployment can fail even though the application code itself is correct.

When reorganizing a repository, review the root directory, build command, output directory, ignored files, and any configuration paths together.

Preview deployments can expose unfinished features

Preview URLs are convenient, but they are still reachable web deployments subject to the project’s access settings. Do not treat a difficult-to-guess URL as a security boundary.

Avoid embedding secrets in the client bundle. Require authentication for sensitive application screens and review Vercel’s deployment-protection options when a preview contains confidential business functionality.

Deployment does not automatically solve discoverability

A client-rendered React SPA can be appropriate for dashboards, internal tools, authenticated applications, and interactive utilities. Public content sites have different needs, including crawlable page output, metadata management, routing, and rendering performance.

React now recommends frameworks for many new applications because they integrate concerns such as routing, data loading, and code splitting. If the project is becoming a content-heavy or search-dependent website, a framework may be a better architectural choice than adding more patches to a basic SPA.

When plain Vercel React hosting is not the right fit

Vercel is a strong match for static React websites, Vite applications, frontend dashboards, prototypes, and projects designed around supported frameworks or serverless functions.

The approach in this guide is not a complete deployment plan for every repository.

A React frontend does not automatically deploy a traditional Express server that expects to run continuously in the same way as it does on a virtual machine. If the repository contains a separate backend, inspect its runtime, database connections, background jobs, file storage, WebSocket requirements, and deployment model independently. You may need to deploy the API separately or adapt suitable endpoints to Vercel Functions.

A plain client-side React SPA may also be a weak starting point for a large public content site that depends heavily on server rendering, per-page metadata, or static generation. In that situation, consider a React framework before the application structure becomes expensive to change. This Next.js guide for React developers provides useful context for evaluating that move.

Finally, Vercel cannot publish a project that does not produce a valid production build. When the application has unresolved dependency conflicts, missing configuration, or environment-specific assumptions, fixing those issues locally is faster than repeatedly pressing Redeploy.

Frequently asked questions (FAQ)

Do I need to upload the dist folder when deploying a React app to Vercel?

No. For a Git-based deployment, push the source code, package.json, and lock file to the repository. Vercel installs the dependencies, runs npm run build, and publishes the generated output automatically.

You normally should not commit dist, build, or node_modules. Add generated directories to .gitignore. Uploading prebuilt files is possible in specialized workflows, but it removes much of the benefit of repeatable cloud builds.

Can I deploy a React app on Vercel without GitHub?

Yes. Vercel also integrates with other supported Git providers, and you can deploy from your project directory using the Vercel command-line interface. Running npx vercel creates a preview deployment, while npx vercel --prod requests a production deployment.

GitHub remains convenient for beginners because commits, preview deployments, production releases, and rollback history stay connected. A command-line deployment is more suitable when Git integration is unavailable or you need a custom release process.

Does Vercel run npm start for a Vite React application?

Not for a standard static Vite deployment. Vercel normally runs the production build command, such as npm run build, and publishes the files created in dist.

The npm run dev command starts Vite’s local development server, while npm start is commonly associated with Create React App or a custom Node.js server. Neither should replace the production build command unless the project’s framework and deployment architecture specifically require it.

Can an older Create React App project still be deployed to Vercel?

Yes. Existing Create React App projects can still be built and deployed, normally using npm run build with build as the output directory.

Create React App has been deprecated for new projects, but that does not make every existing application unusable. A stable project does not need an immediate migration solely for hosting. Consider moving to Vite or a React framework when ongoing maintenance, performance requirements, routing, or future development makes the migration worthwhile.

Can the React frontend and backend API use different hosting providers?

Yes. A React application on Vercel can call an API hosted on another platform, provided the browser can reach the API over HTTPS and the server permits the frontend’s origin.

Store the production API address in an appropriate client-side environment variable instead of hard-coding localhost. The backend may also need Cross-Origin Resource Sharing configuration for the production domain and any preview domains you intend to test. Authentication cookies require additional attention because cross-site cookie rules depend on domain, security, and SameSite settings.

Are Firebase or Supabase keys safe to place in Vercel environment variables?

Only keys designed for browser use should be included in a client-side React build. Firebase web configuration and a Supabase anonymous key can be used in frontend code when the associated security rules or Row Level Security policies are correctly configured.

Administrative credentials are different. Supabase service-role keys, Firebase service-account credentials, database passwords, and other privileged secrets must remain on a trusted server. Giving one of these values a VITE_ prefix exposes it in the compiled browser bundle; Vercel environment-variable storage cannot keep a value secret after the frontend build deliberately publishes it.

Why does a React app work locally but fail on Vercel even when the build succeeds?

A successful build confirms that deployable files were created, not that every browser feature works in production. The deployed application may still use a missing environment variable, an incorrect asset base path, a localhost API address, or an API that rejects the Vercel domain.

Open the deployed site’s browser Console and Network panels. Check the first failed JavaScript or network request, then compare its URL and configuration with local development. This evidence is more useful than repeatedly changing framework presets or rebuilding without identifying the runtime error.

What happens if a new production deployment fails?

A failed build is not promoted as a successful production release. Open its build logs, identify the earliest relevant error, reproduce it locally with npm run build, and push a corrective commit.

Avoid making several unrelated configuration changes at once. For example, if the log reports an unresolved import, changing the output directory will not solve it. Fixing one verified cause at a time preserves the working deployment configuration and makes the failure easier to diagnose.

How should I deploy multiple React apps from one repository?

Create a separate Vercel project for each independently deployed application and set the appropriate root directory for each one. For example, a repository containing customer-app, admin-panel, and website can connect to three Vercel projects, each pointing to its own folder.

Every selected folder should contain the relevant package.json and build configuration. This arrangement allows separate domains, environment variables, deployment histories, and production branches while retaining a shared repository where that structure benefits development.

Should preview deployments connect to the production API?

Usually not when the preview can modify data, send communications, process payments, or trigger other real operations. Connect preview deployments to a staging API or test account whenever practical.

A simple read-only portfolio may safely use the same public data source in both environments. An administrative dashboard needs stronger separation. The decision depends on what the application can do, not merely whether the preview URL is difficult to guess. Preview deployments should be treated as real web environments with deliberate access controls and credentials.

When should a Vite React app be replaced with Next.js or another React framework?

Consider a framework when the project needs server rendering, static generation, route-level data loading, server functions, advanced metadata, or stronger support for public content pages. These requirements are common in content-heavy websites, ecommerce projects, and applications where initial rendering and discoverability matter.

A Vite single-page application remains a sensible choice for many internal tools, authenticated dashboards, interactive utilities, and frontend-only projects. Migration should solve a specific architectural limitation; it should not be performed merely because another framework is popular.

Put the project live, then keep it predictable

To deploy a React project on Vercel correctly, begin with a successful local npm run build. Push the project and its lock file to GitHub, import the repository into Vercel, confirm the root directory and build output, add environment variables to the correct environments, and deploy.

Do not stop at the generated URL. Test direct route refreshes, API requests, browser errors, mobile layout, and a fresh login session. If the application uses client-side routing, configure SPA rewrites where appropriate. If it calls an external service, confirm both its production URL and CORS policy.

After that foundation is working, Git integration makes routine releases straightforward: push a branch for a preview, test the result, and merge approved changes into the production branch. A custom domain can then be added without mixing application problems with DNS troubleshooting.

That gives you more than a live React website. It gives you a repeatable deployment workflow that can be checked, reviewed, and repaired when the project changes. Continue with the site’s DevOps guides when you are ready to improve release checks, hosting configuration, and production maintenance.