Choosing React hosting based on your application architecture

Your React hosting choice is mostly a runtime question: where does your application generate HTML, and does it need server-side code while users are making requests? Client-side rendered applications that produce static build artifacts need different infrastructure than server-rendered applications that execute Node.js code per request.

This article focuses on that React-specific decision. For a broader comparison of static file hosting and application runtimes, see Application hosting vs web hosting. For a deeper Next.js deployment guide, see How to deploy Next.js applications with SSR and API routes.

React rendering strategies and infrastructure requirements

Your React application renders content through three primary strategies, each with distinct hosting implications:

Client-side rendering (CSR) executes JavaScript in the browser to generate DOM elements. The build process compiles your React code into static files, including HTML entry points, JavaScript bundles, and CSS assets. No server-side execution occurs during user requests.

Server-side rendering (SSR) executes React components on a Node.js server for each incoming request, generating HTML before sending it to the browser. This requires a persistent server process running JavaScript. Next.js with getServerSideProps, Remix with server loaders, and similar framework patterns fit this model.

Static site generation (SSG) executes React components at build time to pre-render pages as static HTML files. When the framework emits a fully static export, the deployed artifact is static files. If the same app also uses API routes, SSR, or incremental regeneration, it still needs a runtime service.

The hosting decision reduces to one question: does your application execute server-side code during user requests, or does it serve pre-built static files? Runtime server code belongs on a web service with a Node.js runtime. Static output belongs on static site hosting with CDN distribution.

Static site hosting for client-rendered applications

Static hosting serves pre-compiled build artifacts through CDN edge locations without executing application code. When a user visits your application, the CDN returns HTML, JavaScript, and CSS files. The browser executes JavaScript to render components, handle routing, and fetch data from APIs.

This approach fits applications where:

• React renders entirely in the browser with frameworks like Create React App or Vite
• Build output consists of static files without server-side rendering requirements
• Client-side routing handles navigation using libraries like React Router
• API data fetching occurs from the browser using fetch or libraries like React Query

Static hosting requires configuring fallback routing for client-side routers. Single-page applications use browser APIs to handle route changes without server requests, but direct URL access sends a request to the server. Render does not automatically configure this fallback for every static site. Add a static site rewrite rule with Source /*, Destination /index.html, and Action Rewrite so React Router can handle direct visits to nested routes. See Render static site redirects and rewrites.

Render Static Sites (render.com/docs/static-sites) serve files through a global CDN. For standard Vite or Create React App projects, configure the build command and publish directory during service creation. When pull request previews are enabled, Render can create a temporary service preview for each pull request.

Critical prerequisite: Verify your package.json contains a build script that outputs to a directory like dist/, build/, or out/. You'll specify both the build command and publish directory when creating your static site on Render.

Web service hosting for server-rendered applications

Server-side rendering frameworks execute React components on a Node.js server during each request, generating personalized HTML before sending responses. This requires persistent compute resources running your application code.

This approach becomes necessary when:

• Next.js uses getServerSideProps for per-request data fetching
• Remix loaders execute server-side to load route data
• API routes within frameworks require backend logic execution
• Personalized content rendering depends on request headers, cookies, or session data

This simplified example demonstrates the pattern:

Render's web service hosting (render.com/docs/web-services) provides Node.js runtime environments with configurable instance types through manual or automatic scaling, and persistent disk options. The platform executes your build command, then runs your start command to launch the Node.js server.

Critical prerequisites:

• Your repository must contain a package.json with build and start scripts
• Your start command launches a persistent HTTP server (typically next start)
• You configure environment variables for API keys, database URLs, and secrets through the Render dashboard
• You understand PORT binding: Render sets the PORT environment variable (default value 10000) that your server must bind to on host 0.0.0.0

Performance consideration: Server-side rendering introduces latency because each request waits for component execution and data fetching. You should implement caching strategies in production deployments, including Cache-Control headers for CDN-cacheable pages, application-level caching for database queries, and incremental static regeneration where appropriate.

Security requirements for SSR:

• Never expose API keys or database credentials in client-side code
• Implement request validation and sanitization for user inputs processed server-side
• Configure CORS policies for browser-originated API calls to your own backend
• Use server-side authentication, request timeouts, and allowlists where appropriate when SSR code calls external APIs
• Use environment variables for all secrets (render.com/docs/configure-environment-variables)

Monorepo hosting patterns

Monorepos containing multiple React applications require understanding how hosting services discover deployable artifacts. Each application represents a separate hosting service deployment with its own build configuration.

Build path specification: Configure each service's root directory to point to the specific application subdirectory:

Each application deploys as an independent service with its own build command, publish directory, and environment variables. Render monorepo support lets you set a root directory per service. When you set rootDir: apps/marketing-site, Render treats that directory as the service root. Build commands, start commands, and static publish paths run relative to that root, and files outside the root directory are not available to the service.

Use rootDir when the app is self-contained:

Keep the service rooted at the repository root when the app depends on workspace packages or shared code outside the app directory. In that model, use build filters to limit deploy triggers and run the app build from the repo root:

Development workflow considerations

Pull request previews function differently across hosting types. When service previews are enabled, both static sites and web services can create a temporary standalone service with its own onrender.com URL for each pull request. Render updates the preview from pushes to the pull request branch and deletes it when the pull request closes or merges. For static sites, Render builds and deploys the static files. For web services, Render creates a separate instance running the branch's server code. Web service previews are billed at the same rate as the base service, while static site previews remain free. See Render service previews.

Custom domains attach to both hosting types through DNS configuration. After DNS updates, Render verifies the domain and provisions TLS. For web services, new deploys must pass health checks before Render routes traffic to the new instance.

Build performance optimization: Static site builds scale vertically with faster build machines. Web service deployments can scale vertically for more CPU and memory, and horizontally with multiple instances for runtime traffic.

Next steps

Deploy a Create React App to static hosting to understand the build-to-deployment workflow. Then create a Next.js application using getServerSideProps and deploy to web service hosting to observe the runtime differences. Compare service preview behavior, deployment speeds, and monitoring dashboards between hosting types.

Frequently asked questions