A React website running on localhost still depends on your computer. If Vite produces static files and the application does not require its own server, you can build and publish those files from Git. You can then switch off the development server.
This walkthrough uses an original MIT-licensed React and Vite example. The live demo has two routes: the home page and /about. It includes an original image, CSS and a public build variable. It does not implement authentication, payments, an API or a database.
If your project uses Astro and Markdown, follow the static Git deployment guide, with real page routes and canonical URLs checked on a live demo.
If your React interface loads but its API requests fail after deployment, follow the frontend and API production diagnostic.
Check what your AI tool produced
Find package.json and read its scripts. In this example, build runs Vite and creates dist. React alone does not determine the hosting requirements: an interface calling Supabase, an API or a server also needs those services and correctly configured credentials.
Do not remove backend dependencies to make an application appear static. Read which hosting an AI-built website needs if you are unsure which parts run in the browser and which require a server. This recipe does not demonstrate support for Next.js server-side rendering either.
Prepare a reproducible repository
Fork or copy the example into your GitHub account and keep its licence. Include package.json, package-lock.json, index.html, src, public and the Vite configuration. The lockfile lets npm ci install the recorded versions; it does not automatically update dependencies.
The example requires Node 22.19.0 or later. Build it on your computer first:
npm ci
npm run build
Check that dist/index.html exists and that CSS and JavaScript files are in dist/assets. npm run dev and npm run preview are local development and testing tools, not the production process for this static deployment.
Configure Projects for this example
Connect your Git provider and choose the repository using the Projects documentation. Review the permissions before granting access. These settings were tested with the example:
| Setting | Value |
|---|---|
| Branch | main |
| Framework | Vite |
| Type | Static |
| Install command | npm ci |
| Build command | npm run build |
| Output directory | dist |
| Repository subfolder | Empty |
These values apply to this repository. A monorepo, a different script or a custom output directory needs its own configuration. Do not publish node_modules or your personal folder.
Prevent a 404 when opening a route directly
When navigating from the home page, React can change the URL to /about without requesting another HTML file. On refresh, the browser requests /about from the host. If that file does not exist and there is no fallback, the request returns 404 even though the link worked earlier.
On Hostbrid, this example enables the fallback with public/.hostbrid-spa. Vite copies this file to the root of dist. For a site containing the marker and an index file, the host serves index.html for browser routes. Sites without the marker keep their existing behaviour. The marker cannot be downloaded over HTTP, and missing assets still return 404.
Check that your export preserves files whose names start with a dot. Creating the marker in a folder that the build never copies is insufficient. An unknown route can return HTML with status 200 and display React’s “Page not found” screen: that does not make it a valid SEO page. Define the real routes and review rendering and indexing before publishing many URLs.
Blank screen: identify the failing request
Open your browser tools, select Network, reload and inspect the failing request. Check its URL, status, content type and response. A homepage returning 200 does not prove that JavaScript loaded.
- The
/aboutdocument returns 404: check the marker and fallback described above. - JavaScript or CSS returns 404: compare the requested URL with the build files. Publish the complete
distdirectory and check that HTML and assets belong to the same build. - JavaScript returns 200 with an HTML response: the server is returning a page, possibly the index or an error, where the browser expects code. Sending every request to
index.htmldoes not fix this; missing assets must still return 404. - Files load but the screen remains blank: inspect the console. Application errors, external APIs and missing variables need a different diagnosis from routing fallback.
Our example is published at its subdomain root. If you prepare a /demo/ installation on another server, Vite’s base option adjusts asset paths during build; configure the router prefix separately. base: './' is not a universal fix for deep-route reloads. This guide does not demonstrate that Projects supports publication under arbitrary prefixes.
You can also use our original MIT-licensed static diagnostic. With Node 22.23.3, download the tested version and run:
git clone https://github.com/ocentelles/hostbrid-static-diagnostics.git
cd hostbrid-static-diagnostics
git checkout 203e71e33e9864f8048dccee3d886fa3c87dcb1c
node --version
node diagnose.mjs https://hostbrid-react-demo.hostbrid.dev/
Replace the demo URL with your public website URL. No dependency installation is required. It checks HTML and direct same-origin JavaScript/CSS references; it does not execute React or verify images, APIs or internal routes. It returns JSON and a nonzero exit code when it detects failures or cannot complete a check. The command’s demo passed three GET requests; the tool has 28 local HTTP tests. A successful result does not replace browser testing.
We also published the original route and asset fixture: six local cases covering incorrect bases, router prefixes and HTML returned as JavaScript. Its README explains how to reproduce them with Node and Chrome; this experiment does not add commercial capabilities to Projects.
Set variables without publishing secrets
The example uses VITE_CONTACT_LABEL, a label embedded in JavaScript during the build. VITE_* variables are public: never put passwords, private keys or administration tokens in them. Changing the variable requires another build; it does not change files already published.
Check why the old value still appears
In our original Vite environment experiment, we built a label with value A and served those same files from a process with value B. The browser still displayed A after reloading, and the JavaScript hash stayed unchanged. Rebuilding with B changed both the label and the hash. Without the variable, the expected fallback text appeared.
If you see an old value, check which variable the build process received and which build you are publishing. Changing only the environment of the server serving static files does not rewrite the bundle. This local experiment verifies one static Vite configuration; it does not demonstrate variable propagation in the Hostbrid panel, SSR behavior or runtime environment configuration.
You can reproduce all three builds with Node 22.23.3 and Chrome on macOS by following the repository README. Use public example values: checking one unprefixed marker in this experiment is not a secrets audit of your project.
When the browser still calls localhost
Reload the published website in Network and inspect the failing request. A URL such as http://localhost:3000/api/contact tells the visitor’s browser to contact their own computer. Publishing React files does not automatically publish that server.
Find where the URL is assembled: application code, configuration or a public build variable. Replace it with the HTTPS endpoint of a backend you have actually deployed. For a VITE_ variable, rebuild and publish again; changing a variable later does not change existing JavaScript. Never put private credentials in that variable.
A relative /api/contact avoids fixing a hostname, but requests the route at the origin serving the website. Use it only when that backend or a configured proxy exists there. A 404 or the homepage HTML means the route still needs inspection; neither proves successful submission.
Do not replace every occurrence of 0.0.0.0: it may be the correct address for a server to listen on. The browser’s request URL needs the public destination. Reload and verify the URL, response and intended action afterwards. Fixing the hostname alone does not verify CORS, login or form receipt.
Test the published website
Open the HTTPS address on another device. Visit the home page, enter /about directly and reload it. Check the image, styles and second route’s content. A request for a missing JavaScript file should return 404, not HTML with status 200.
Tested on 8 October 2026: we published commit db329ae through the Projects build process. The home page and /about returned 200; CSS and JavaScript were served with the correct content types. Chrome executed React on /about and displayed the public build label. Missing assets and the marker returned 404. The routing configuration was tested on both hosting replicas, including sites that do not enable the fallback.
This test uses Hostbrid’s own project. It verifies building and publishing, but not customer signup, customer OAuth authorisation or automatic deployments on push. Visit Projects and current plans to choose capacity. If your website needs a backend, decide where it will run and test it before making the application available to users.
See also the Vite build documentation and its public environment variables.
If your repository contains two applications and a shared package, use the npm workspaces diagnostic before trimming a folder: the installation root and published output serve different purposes.