This is the direct, practical version of an idea introduced in the static-hosting lesson: a React app, once built, is just static files — HTML, CSS, and JavaScript — which is why it deploys through the Git-based cloud workflow covered earlier in this category, not through FTP.
npm run build
# produces a folder (commonly "build" or "dist") full of
# plain HTML, CSS, and JS — no React-specific server needed to serve itThat output folder is a fully static site in every sense covered in the static-hosting lesson — it could, in principle, be uploaded via plain FTP like any other static project. In practice, almost nobody does that by hand.
npm run build automatically, and serves the output.From this point on, every push to your repository's main branch redeploys automatically — exactly the Git-based deployment workflow covered earlier, with nothing React-specific about the mechanism itself.
A React app using client-side routing (moving between pages without a full reload) needs one specific server configuration to work correctly once deployed: every URL path needs to serve the same index.html file, letting React's own router handle which content to show based on the URL, rather than the server looking for a matching physical file at each path and returning a 404 when it doesn't find one.
Client-side routing needs a specific server rule
Without this configuration, the homepage works fine, but refreshing the browser on any other page — or sharing a direct link to one — produces a 404 error, because the server looked for a file at that exact path and found nothing. Most cloud hosting platforms handle this automatically for a recognised React project; if using plain static hosting without that detection, this needs to be configured explicitly, usually through a small redirect or rewrite rule the platform's documentation will name directly.
A React app often needs configuration that differs between local development and production — an API URL, for instance. These are set through the hosting platform's dashboard rather than hardcoded, covered properly in the environment-variables-and-secrets lesson later in this category — the same underlying idea as a database password, just for a different kind of value.
Beyond checking the homepage, specifically test navigating to an inner route and then refreshing the browser on it — that single action is the most reliable way to catch the routing wrinkle before a real visitor does.