A React app is not public when it works on localhost. It becomes public when a host receives your production files, connects a domain, and returns the right page for every URL.
When you host React website files, the quickest path is usually Vite, a Git repository, and a static hosting platform. Build the app, deploy the dist folder, add routing rules, then test the live site like a visitor would.
Start with a small deployment. Get one route working before you add a domain, analytics, API connections, and team access.
PREPARE YOUR REACT APP FOR HOSTING
React source files are not what a browser needs in production. Your host needs the compiled HTML, JavaScript, CSS, images, and fonts created by a production build.
Use Vite for new React projects
Create React App still exists in older codebases, but it is not the default starting point for a new project. Use Vite for a lightweight local server and production build process.
Create a basic JavaScript React project with npm create vite@latest my-site -- --template react. For TypeScript, use --template react-ts.
Then install packages and start the app:
cd my-site
npm install
npm run dev
Before deployment, run:
npm run build
Vite writes the production files to dist by default. Run npm run preview after the build. This opens the built version locally and catches missing files before you upload anything.
Vite’s static deployment guide includes current platform settings and GitHub Pages guidance. Check it before changing build settings, because platform defaults can change.
Keep the repository clean
Push the source code, package.json, lockfile, and configuration files to Git. Do not commit node_modules. Most hosting platforms install dependencies and run your build command on their own servers.
Use a basic first commit:
git init
git add .
git commit -m "First React deploy"
Add a .gitignore file if your starter did not add one. It should exclude node_modules, dist, local .env files, and editor files.
A successful build is not the final result. The live homepage, direct URLs, mobile layout, images, and forms are the result that matters.
CHOOSE WHERE TO HOST A REACT WEBSITE
The right provider depends on how your app is built and who will maintain it. A portfolio and a customer dashboard do not need the same setup.
| Option | Best fit | Main strength | Watch for |
|---|---|---|---|
| Vercel | Vite apps, React frameworks, preview workflows | Git-based deployments and pull request previews | Add a rewrite for client-side routes |
| Netlify | Static sites, forms, Git-based teams | Simple deploy controls and redirect rules | Configure SPA redirects |
| GitHub Pages | Documentation, demos, open-source projects | Works directly with a GitHub repository | Deep links and project base paths need extra work |
| Traditional static hosting | Existing hosting accounts or custom infrastructure | Full server control | You manage builds, uploads, and rewrites |
Use Vercel for fast Git deployments
Vercel is a strong default when your code is already on GitHub, GitLab, or Bitbucket. Import the repository, confirm the framework settings, and deploy.
For a Vite app, Vercel usually detects the project. The build command is npm run build, and the output directory is dist. Each pushed branch or pull request can receive its own preview URL.
Read Vercel’s current Vite deployment settings before overriding detected values. Manual settings often create problems when the platform already recognizes the framework.
Use Netlify when you want simple static-site controls
Netlify also connects to Git and builds your project after each push. Set the build command to npm run build and the publish directory to dist if Netlify does not detect them.
It is a practical choice for marketing sites, documentation hubs, portfolios, and small internal tools. Netlify also gives you direct control over redirects and build environment variables.
The current Vite setup guide for Netlify covers its recommended build and routing configuration.
Use GitHub Pages for public project sites
GitHub Pages works well for a public demo, documentation site, or small site linked to an open-source repository. It is less flexible than Vercel or Netlify for a React single-page app.
You can publish from a branch or deploy through GitHub Actions. GitHub documents both options in its guide to configuring a Pages publishing source.
GitHub Pages is static hosting. It does not give you a server rule that rewrites every unknown URL to your React app.
Use traditional static hosting when you control the server
Traditional static hosting fits when your business already pays for cPanel hosting, an Nginx server, Amazon S3 with a CDN, or a managed web server.
Run npm run build, then upload the contents inside dist. Do not upload the dist folder as a nested directory unless your host expects it. Your domain root should contain index.html and the assets folder.
This option gives you control. It also makes you responsible for routing, headers, cache rules, TLS, deployment logs, and rollback files.
Hosting plans, included usage, dashboards, and free-tier limits change. Check the provider’s live pricing and product pages before you commit a production app to a plan.
DEPLOY FROM GIT OR THE COMMAND LINE
Git-based deployment gives your team a repeatable path. Every live version points back to a commit. That makes rollback simple.
Deploy a Vite app on Vercel
Start by pushing the repository to GitHub, GitLab, or Bitbucket. In Vercel, select “Add New Project,” import the repository, and confirm the detected Vite settings.
Click Deploy. Vercel installs dependencies, runs the build, and gives you a temporary domain such as your-project.vercel.app.
You can also deploy through the command line. Install the CLI with npm i -g vercel, then run vercel from the project folder. Use vercel --prod when you are ready to publish the production version.
Open the deployment URL and test the homepage before connecting a custom domain.
Deploy a Vite app on Netlify
In Netlify, choose “Add new site” and import your Git repository. Select the branch that should publish, usually main.
Confirm these values:
- Build command:
npm run build - Publish directory:
dist - Node version: match the version used by your team and build tools
After the first deployment, Netlify gives you a temporary netlify.app address. Treat it as a test environment. Check the production build before you share it with customers or add it to your navigation.
Keep a deployment record with the commit hash, deployment URL, owner, date, and known issues. Your hosting dashboard shows the current state. Your change record shows what changed and why.
FIX REACT ROUTING BEFORE USERS FIND 404 PAGES
React Router can show routes such as /pricing, /dashboard, or /about after the app loads. A browser refresh is different.
When someone opens /pricing directly, the host receives a request for /pricing. A static host may look for a physical file with that name, fail to find one, and return a 404 page.
Add an index.html fallback
A React single-page app needs unknown page requests to return index.html. React Router then reads the URL and shows the correct screen.
For Vercel, add a vercel.json file in the project root with this rule:
{"rewrites":[{"source":"/(.*)","destination":"/index.html"}]}
For Netlify, add a file named _redirects inside public with this line:
/* /index.html 200
Vite copies the public folder into dist during the build. Netlify’s documentation states that SPAs need a rewrite rule that returns index.html for requested URLs.
Test deep links directly. Paste
https://yourdomain.com/pricinginto a private browser window, then refresh it. Clicking a menu item is not enough.
Handle GitHub Pages differently
GitHub Pages does not provide the same catch-all rewrite behavior. The simple option is HashRouter, which creates URLs such as yourname.github.io/project/#/pricing.
The browser sends the server only the part before #. React receives the route after the page loads.
Also set Vite’s base option when you publish under a repository path. If the repository is named project, use base: '/project/' in vite.config.js. Without it, your built asset links may point to the wrong location and load a blank page.
CONNECT A CUSTOM DOMAIN AND PROTECT CONFIGURATION
A provider subdomain is fine for testing. A business site needs a domain you control.
Connect the domain in the right order
Add the domain inside Vercel, Netlify, GitHub Pages, or your hosting panel first. The host will show the DNS records it expects.
Then open your domain registrar and add the required record. This is usually an A, AAAA, or CNAME record. Remove conflicting records only when you understand what they control. Email records such as MX and SPF are separate from website records.
GitHub’s guide to managing a Pages custom domain shows the DNS and repository steps.
Test both example.com and www.example.com. Pick one as the canonical address and redirect the other. Confirm HTTPS works before you announce the site.
Never put secrets in a React environment variable
Anything available to browser-side React code is public. Vite exposes variables that begin with VITE_, such as VITE_PUBLIC_API_URL. That prefix does not make a value safe. It marks the value for inclusion in the built JavaScript.
Do not place database passwords, Stripe secret keys, private API tokens, service-account JSON, or admin credentials in .env files used by the frontend.
Store secrets in a server-side API, serverless function, or approved secret store. The frontend should call your backend. Your backend uses the private credential and returns only the data the browser needs.
Netlify explains where build environment variables are available. The same rule applies on every host: a value compiled into public JavaScript is not a secret.
CONFIGURE TRADITIONAL STATIC HOSTING CORRECTLY
Traditional hosting works well when the React app is fully static. It does not need a Node server after Vite builds it.
Upload the right files
Run npm run build. Upload the contents of dist to the web root, often named public_html, www, or htdocs.
Your root directory should contain index.html. The hashed JavaScript and CSS files should stay inside the generated assets directory. Do not rename generated files. Vite references them by exact path.
For repeatable releases, keep each deployed dist archive with its commit hash. If a new release breaks checkout, routing, or a form, you can restore the last trusted build.
Add server rewrites without breaking assets
On Nginx, a typical SPA fallback is try_files $uri $uri/ /index.html;. On Apache, add a rewrite that sends requests for missing files and folders to index.html.
Do not send API paths to the React fallback. A request to /api/orders should reach your API service or return an API error. It should not return your homepage HTML.
If your host uses cPanel, ask the provider where rewrite rules belong before editing .htaccess. A bad rewrite can cause login loops, broken images, or API failures.
TROUBLESHOOT THE DEPLOYMENT IN A FIXED ORDER
Most React deployment failures are small configuration mistakes. Check the live result in the same order every time.
- A blank page often means the Vite
basepath is wrong, a JavaScript file failed to load, or the browser found an old cached asset. - A build failure usually points to a missing dependency, an unsupported Node version, a TypeScript error, or an environment variable that exists locally but not on the host.
- A 404 after refresh means the single-page app fallback is missing.
- An exposed credential means it was included in frontend code or a public build variable. Rotate it immediately, then move it server-side.
- A domain that does not resolve usually has an incorrect DNS record, a conflicting record, or DNS propagation still in progress.
Change one part at a time. Do not change the domain, build command, routing rule, and environment settings in one attempt. You will not know which change fixed the issue.
For a small team, assign one person to own the domain, one to approve production deployments, and one place to record the last working release. If you need help setting that process up, Book A Call.
FINAL DEPLOYMENT CHECK
To host React website files well, build with Vite, deploy the dist output, and verify direct route requests before launch. A temporary host URL gives you a safe place to find problems.
The hosting provider is only one part of the setup. Routing rules, domain ownership, and secret handling decide whether the site stays reliable after the first deployment.
