How to Host a React App with Preview Builds and Custom Domains

Overview

If you want to host a React app well, the goal is not only to get a site online. The goal is to create a deployment workflow that is easy to understand, safe to change, and fast enough that developers will actually use it. A good React hosting setup should answer a few practical questions:

• Where does the production build run?
• How are preview builds created for branches or pull requests?
• Which domain serves production, and how are staging or preview URLs handled?
• How are HTTPS, redirects, cache headers, and single-page app routing configured?
• What happens when environment variables, API endpoints, or authentication callbacks change?

For many React apps, the hosting layer is a frontend-focused app hosting platform or cloud app development platform that connects directly to Git, runs your build command, and deploys the output automatically. That is often the simplest path for static React sites and frontend-heavy apps. If your app also needs API routes, background jobs, or a custom backend, your hosting choice may expand into a broader platform as a service or a cloud native app platform with separate frontend and backend services.

The durable pattern is simple:

1. Keep your app in version control.
2. Connect the repository to a hosting provider.
3. Define build and output settings clearly.
4. Enable preview builds for every meaningful change.
5. Attach a custom domain to production.
6. Test routing, environment variables, asset caching, and rollback behavior.

If you are comparing providers, it helps to think in workflow terms rather than brand terms. The best hosting for a React app is usually the platform that makes your everyday deployment path predictable. Preview URLs, branch environments, simple DNS instructions, and straightforward build logs often matter more than a long feature list.

For a deeper comparison of preview-oriented platforms, see Vercel vs Netlify vs Cloudflare Pages for Preview Deployments.

Checklist by scenario

Use this section as a working checklist. Start with the scenario closest to your app, then adapt the items to your platform.

Scenario 1: Static React app with client-side routing

This is the most common setup for marketing sites, dashboards, internal tools, and frontend apps that talk to APIs elsewhere.

• Confirm the build system. Know whether your app uses Vite, Create React App, Next-style static export, or another build tool. Your build command and output directory must match that tool.
• Set the build command explicitly. Do not rely on guessed defaults if your team may change tooling later.
• Set the publish directory explicitly. Common mistakes start here. If the host expects a build folder but your app outputs to a different directory, deploys may succeed but serve the wrong files.
• Enable SPA fallback routing. If your React app uses client-side routes like /settings or /projects/123, direct page refreshes should return the app shell rather than a 404.
• Turn on preview builds. Every pull request should get its own URL so reviewers can test changes before merge.
• Connect a custom production domain. Use your canonical domain for production and keep preview URLs separate.
• Enable automatic HTTPS. Your host should provision and renew certificates so there is no manual certificate workflow.
• Test asset caching. Fingerprinted JavaScript and CSS files should cache aggressively; your HTML entry document should be refreshed more carefully.
• Add redirect rules. Decide whether www redirects to apex or the other way around and enforce one canonical host.
• Verify environment variables. Frontend-safe variables must be exposed correctly at build time, and secrets must not be embedded in the client bundle.

Scenario 2: React frontend with a separate backend

This is common for SaaS apps and internal business tools. The frontend may live on one app hosting platform while the API lives on a separate backend as a service, platform as a service, or container-based environment.

• Separate frontend and backend environments. Production frontend should point to production API; preview frontend should point to a matching staging or preview API when possible.
• Map environment variables by environment. Avoid a setup where preview builds accidentally call production services.
• Review CORS settings. Preview URLs often introduce new origins. Make sure your backend accepts the right hosts without being overly permissive.
• Check authentication callbacks. OAuth providers and auth services usually require approved redirect URLs for production and preview environments.
• Define a rollback path. If the frontend deploys cleanly but the backend change fails, know whether you can roll back one side independently.
• Monitor API failures after deploy. React app deployment issues often appear as runtime errors caused by backend mismatches, not broken frontend builds.

If your backend is still taking shape, you may also want to compare lightweight backend options in Firebase vs Supabase vs Appwrite for Test and Prototype Backends.

Scenario 3: Team workflow with pull request previews

Preview builds are one of the highest-value improvements in a modern cloud deployment workflow. They shorten review cycles and reduce the gap between code review and product review.

• Trigger previews automatically from pull requests. Avoid manual preview creation if the platform supports direct Git integration.
• Name preview environments clearly. Branch names, commit SHAs, or pull request numbers should make URLs easy to trace back to source changes.
• Decide how previews handle external services. For example, use test auth providers, staging APIs, or seeded demo data.
• Protect previews when needed. Internal apps or unreleased features may need password protection or access controls.
• Test preview cleanup behavior. Stale previews can clutter dashboards and confuse reviewers if they are never removed.
• Document what previews are for. Teams should know whether previews are intended for visual review, QA checks, stakeholder approval, or all three.

If preview environments are central to your process, compare them alongside your CI and QA practices in Best Cloud Test Environment Platforms Compared for Fast QA and CI.

Scenario 4: React app with custom domain and production cutover

Connecting a custom domain is simple in principle, but it is often where production launches get delayed.

• Choose the canonical domain first. Decide whether the app lives at the apex domain, a subdomain like app.example.com, or both with a redirect.
• Lower DNS friction before launch. Make sure the person with DNS access is part of the release plan.
• Add the domain in the hosting dashboard before changing DNS. Many platforms provide clear records only after domain setup starts.
• Verify HTTPS after DNS propagation. Do not assume certificate provisioning is complete until you have tested it.
• Check redirect behavior. HTTP to HTTPS, old subdomain to new subdomain, and non-canonical host to canonical host should all behave predictably.
• Review cookies and auth domains. Moving from a preview domain to a production custom domain can affect sessions, callbacks, and cookie scope.

Scenario 5: React app that needs more than static hosting

Some apps start as static frontends but outgrow that model. You may need server-side logic, scheduled jobs, file processing, WebSocket support, or region-specific execution.

• List the runtime features you actually need. Avoid migrating to a heavier platform just because it seems more flexible.
• Decide whether frontend and backend should stay separate. A split setup can keep deployments cleaner; a unified setup can reduce coordination overhead.
• Check cold start and execution limits if using serverless functions. These details matter once your React app depends on server-side endpoints.
• Plan logs and observability. Build logs are not enough when runtime issues appear after deploy.
• Keep static assets on the CDN path. Even if the app gains server logic, your frontend bundle should still be delivered efficiently.

If your broader stack includes custom backend services, How to Deploy a Node.js App to the Cloud: Platform-by-Platform Guide is a useful companion piece.

What to double-check

Before you announce a production URL or ask teammates to rely on preview builds, review these details carefully. Most React hosting issues are not dramatic failures. They are small configuration mismatches that show up only after users click deeper into the app.

• Build output: Confirm the deployed directory contains the files your host should actually serve.
• SPA routing: Refresh a nested route directly in the browser. If it fails, your rewrite rules are not complete.
• Base paths: If the app is hosted under a subpath instead of the domain root, check asset paths and router configuration.
• Environment variables: Make sure production, staging, and preview values are distinct and documented.
• Client-side secrets: Never place private API keys or server credentials in code shipped to the browser.
• Custom domain records: Verify the exact DNS records, not just the intended setup.
• HTTPS: Test certificate issuance and secure redirects after DNS changes settle.
• Cache behavior: Deploy a change and verify that browsers pick up the new HTML while static assets remain cache-efficient.
• Error pages: Decide what users should see on missing routes, failed asset requests, and application errors.
• Performance basics: Compress assets, reduce oversized bundles, and confirm image handling is reasonable for your traffic profile.
• Analytics and monitoring: Ensure production and preview traffic are not mixed in ways that make debugging harder.
• Access controls: Internal previews, admin apps, or customer-specific demos may need gated access.

A practical habit is to keep a release checklist in the repository itself. That keeps domain, redirect, preview, and environment expectations close to the codebase rather than buried in team memory.

Common mistakes

The most persistent React app deployment problems are usually process problems rather than platform failures. These are the mistakes worth watching for.

Using production services from preview builds

This can lead to accidental data writes, confusing analytics, and difficult bug reports. Preview builds should ideally connect to staging services or clearly isolated test paths.

Forgetting single-page app rewrites

A homepage that loads correctly does not prove the app is configured correctly. Deep links and browser refreshes are the real test for SPA routing.

Embedding secrets in the frontend

Anything shipped to the browser should be treated as public. If a value must stay secret, it belongs in a server-side environment or backend service.

Letting preview environments drift from production

Preview builds are useful only if they reflect production closely enough to catch meaningful issues. If previews use different build settings, disabled features, or unrealistic data, they lose value quickly.

Making DNS changes at the last minute

Custom domains are often treated as a final checkbox, but they touch DNS ownership, HTTPS provisioning, redirects, and auth callbacks. Prepare this part early.

Ignoring rollback strategy

Fast deployment is helpful only if you can recover cleanly. Know how to redeploy the last good version, restore environment variables if needed, and verify the custom domain points to the right release.

Choosing a platform for features you will not use

The best platform to build web apps is rarely the one with the longest features page. It is the one that supports your actual React workflow with the least operational drag.

If you are still comparing broader app hosting choices beyond frontend-first providers, Heroku vs Render vs Railway vs Fly.io for Staging and Test Apps can help frame the tradeoffs.

When to revisit

This setup is worth reviewing whenever your inputs change. That is what makes a hosting checklist valuable: it stays useful beyond the initial launch.

Revisit your React hosting workflow in these situations:

• Before a major launch or seasonal planning cycle. Confirm domains, redirects, certificates, and monitoring before traffic changes.
• When you change build tools. Moving from one React toolchain to another can change build commands, output directories, and environment variable conventions.
• When you add preview requirements. Teams often start simple and later need pull request previews, password-protected demos, or branch-specific configuration.
• When backend dependencies expand. New APIs, auth providers, or background jobs may push you beyond basic static hosting.
• When performance becomes visible to users. Larger bundles, more routes, and heavier assets are signs to review your CDN and caching approach.
• When your domain strategy changes. Rebrands, new subdomains, or separate app and marketing sites usually require DNS and redirect updates.
• When your platform workflow changes. If your host changes deployment behavior, build images, or integration options, update your checklist and test assumptions.

To keep this practical, end each quarter with a five-step review:

1. Deploy a fresh preview build from a branch and confirm it works end to end.
2. Check that preview environments use the correct non-production services.
3. Verify production domain, HTTPS, and redirects.
4. Test a direct refresh on nested routes and a clean rollback of the last release.
5. Update your repository documentation with any changed commands, environment variables, or DNS notes.

If you do only that, your React app deployment process will stay healthier than many teams that rely on habit instead of a documented workflow.

Hosting a React app well is less about chasing the newest platform and more about keeping a reliable chain from commit to preview to production. Start with a simple deployment path, add preview builds where they help review speed, keep custom domains and HTTPS boring, and revisit the setup whenever your tooling or team process changes. That is the kind of system you can return to and trust.