Hosting a React app in the cloud is more than uploading a build folder. A reliable deployment connects a correctly configured repository to a repeatable build command, safe environment variables, predictable routing, sensible caching, and an operating process for releases and failures. This guide explains how to deploy a React app to the cloud and provides a maintenance checklist you can reuse whenever the application, framework, runtime, or hosting configuration changes.
Overview
A typical React deployment has four stages: develop locally, build the application, publish the generated assets, and operate the hosted site. Your cloud app development platform may provide managed static hosting, a platform as a service workflow, a serverless app platform, or a broader app hosting platform. The provider matters less than whether the workflow is clear and repeatable.
Start by identifying what kind of React project you have. A client-rendered application created with a bundler generally produces static files after a production build. A framework-based project may also require server-side rendering, server functions, image processing, or other runtime services. Do not assume that every React project can be hosted as static files. Confirm the framework's deployment model before choosing the hosting target.
Your repository should contain the application source, package manifest, lockfile, build configuration, and deployment documentation. The deployment system should install dependencies from the lockfile, use a deliberately selected Node.js version, run the production build, and publish the correct output directory. Record these settings in the repository or platform configuration rather than relying on undocumented dashboard values.
A useful release path is:
- Open a pull request or otherwise review the change.
- Run linting, tests, and the production build in continuous integration.
- Create a preview deployment for browser and stakeholder checks.
- Promote the reviewed commit to production.
- Verify the live site and record the release.
For a broader view of deployment preparation, see the production checklist for deploying a Node.js app. Many of the repository, runtime, and rollback practices also apply to React hosting.
What to track
Repository and build configuration
Track the source repository, production branch, package manager, lockfile, Node.js version, build command, and output directory. Common build commands include npm run build, pnpm build, or an equivalent command defined by the project. The correct output directory depends on the toolchain, so confirm it from the build result rather than copying a setting from another project.
Keep the package manager and lockfile consistent. A deployment that works locally but resolves a different dependency tree in the cloud is difficult to diagnose. Check that the build is reproducible from a clean checkout and that no uncommitted local file is required for compilation.
Environment variables
Separate public configuration from secrets. A browser-based React application can expose values embedded into its JavaScript bundle, so anything intended for client-side use should be treated as public. Database passwords, private API keys, signing secrets, and administrative tokens must remain on a server-side service rather than being placed in frontend environment variables.
Document each required variable, its purpose, and whether it is needed during the build or at runtime. Use separate values for local development, preview deployments, and production where appropriate. After changing a variable, trigger a deployment when the platform injects values during the build, because a new bundle may be required.
Routing and asset behavior
Single-page React applications often use client-side routing. The browser can request a path such as /settings directly, while the host may look for a physical file at that path. Configure a fallback so application routes serve the main HTML entry point, while real static assets continue to resolve normally. Test direct navigation, refreshes, bookmarked routes, and unknown paths.
Track the caching rules for HTML, JavaScript, CSS, images, and fonts. Hashed assets can usually be cached more aggressively because their filenames change when their content changes. The HTML entry point needs a strategy that allows new deployments to become discoverable without creating unnecessary repeat downloads. Test cache behavior in a private browser session and with a fresh deployment.
Domains, TLS, and monitoring
Record the production domain, DNS ownership, redirect rules, canonical hostname, and certificate status. Use one intentional public hostname and redirect alternate forms where required by your design. Verify that HTTP requests reach the intended HTTPS address and that API calls use the correct origin.
Monitor deployment failures, client-side errors, failed requests, availability, and basic page performance. A browser error tracker or frontend monitoring service can reveal problems that a successful build cannot, such as a missing runtime variable, an invalid route, or a third-party script failure. For a fuller monitoring plan, review the cloud app observability stack guide.
Cadence and checkpoints
Use a monthly or quarterly review cadence, with additional checks before every significant release. The cadence should reflect the application's risk, not a universal calendar. A public business application with frequent dependency changes deserves more attention than an internal prototype.
Before every production release
- Confirm the commit being deployed and review the changes.
- Run tests, linting, and a clean production build.
- Check that required environment variables exist in the target environment.
- Test the homepage, at least one client-side route, a refresh on that route, forms, authentication boundaries, and key API calls.
- Inspect browser console errors and failed network requests.
- Confirm the preview deployment uses realistic but non-production data.
- Verify that a rollback target is available.
Preview deployments are especially useful for catching route, asset, and configuration errors before promotion. The workflow described in the staging and preview environments guide can help teams define what should be tested before production.
Monthly review
Review build duration, failed deployment frequency, frontend errors, broken links, high-volume API failures, and unexpected usage. Check whether the hosting plan's quotas or limits are approaching the application's normal demand. Do not wait for an outage to discover that build minutes, bandwidth, request volume, or storage has become a constraint. See the quota and rate-limit capacity reference for a structured review.
Quarterly review
Review the supported Node.js version, React and framework requirements, major dependencies, domain configuration, access permissions, deployment secrets, and hosting costs. Confirm that the documented build command and output directory still match the repository. Review whether the current app hosting platform still fits the application's needs or whether a migration would reduce operational complexity.
How to interpret changes
Separate application changes from platform changes. A new JavaScript error immediately after a code release points first to the release, its environment variables, or an altered dependency. A failure that begins after a runtime or build-image change may require checking the platform's supported versions and build logs. Keep the deployed commit, runtime version, dependency lockfile, and configuration snapshot with each release record so these possibilities can be compared.
Watch for patterns rather than isolated numbers. A single slow build may be temporary; a steady increase can indicate a growing dependency tree, an inefficient asset pipeline, or insufficient build resources. A small rise in client errors may be harmless if traffic also increased, but an error rate concentrated on one route suggests a release or routing problem.
When a deployment fails, read the earliest meaningful error in the build log rather than only the final summary. Reproduce the build from a clean checkout, verify the runtime and package manager, and compare the failing commit with the last successful one. If production is affected, restore the last known-good deployment first, then investigate. A rollback is a controlled risk-reduction step, not a substitute for finding the cause.
Track cost as an operational signal, not just a billing value. Unexpected increases may result from traffic, asset delivery, build activity, preview environments, or a connected backend. If the React frontend calls serverless functions, databases, or third-party APIs, inspect those components as part of the same request path. For related hosting decisions, use the cloud app platform pricing guide.
When to revisit
Revisit this guide before every first production launch, major React or framework upgrade, hosting migration, domain change, or change to the build pipeline. Schedule a formal review monthly or quarterly, and perform an immediate review when a provider changes runtime requirements, build behavior, cache defaults, deployment limits, or pricing. Those details vary by platform and should be checked against current provider documentation rather than copied from an old project.
Keep a short release record for each production deployment:
Release date and time:
Application version or commit:
Node.js and package-manager versions:
Build command and output directory:
Changed environment variables:
Routes and integrations tested:
Preview URL:
Production URL:
Monitoring checks completed:
Rollback target:
Known follow-up work:Before closing the release, open the production URL in a fresh session, test a direct application route, confirm the main user action, inspect the browser console, and check monitoring for new errors. Then write down what changed and when the next review is due. This small habit turns React app deployment from a one-time upload into a dependable cloud deployment workflow that can be maintained as the application grows.
