Two Ways to Ship a Frontend: Static Files or a Running Server

When you start building a frontend application, one question will shape your entire deployment pipeline more than any framework choice: does this app need a server that stays alive, or can it live as a folder of files?

This is not a theoretical architecture debate. It is a practical decision that determines how you build, where you deploy, what can go wrong, and how you fix it.

The Static Frontend: Files That Speak for Themselves

Imagine you are building a company profile page, a documentation site, or a marketing landing page. You write some HTML, add CSS, throw in a few images, and upload it somewhere. The browser downloads those files and renders them. Done.

That is a static frontend. Everything the browser needs is ready at build time. HTML, CSS, JavaScript, fonts, images — they all become files that can sit on a basic web server, a CDN, or an S3 bucket. No server process runs after deployment. No waiting for a runtime to start. The files just sit there, waiting to be served.

But static does not mean simple. A React or Vue application that fetches data from an API can still be built into static files. The difference is that the data does not appear until the browser runs the JavaScript and makes API calls. This is called client-side rendering. The initial HTML might be a shell, and the real content fills in after the page loads.

The pipeline for a static frontend is straightforward:

  1. Run the build command.
  2. Collect the output files.
  3. Upload them to storage or a CDN.

No server restart. No health check. No waiting for a process to become ready. Deployment can be as simple as replacing files in a bucket or updating a CDN pointer. If something goes wrong, you swap back to the previous files. It is fast, cheap, and hard to break.

The SSR Frontend: Pages Cooked on Demand

Now consider an e-commerce site that shows real-time pricing, stock availability, and personalized recommendations. If you build this as static files, users will see stale data until the browser runs JavaScript and fetches fresh information. That delay can cost sales, confuse customers, and make the app feel sluggish.

This is where server-side rendering (SSR) comes in. When a user requests a page, the server fetches the latest data, renders the HTML, and sends a fully formed page to the browser. The user sees the content immediately, without waiting for JavaScript to load and execute.

SSR means your frontend is no longer just files. It is a running application that needs a server, dependencies, environment variables, and proper startup sequences. The pipeline now looks more like a backend deployment:

  1. Build the application into server-ready code.
  2. Install runtime dependencies.
  3. Configure environment variables for the target environment.
  4. Start the server process or deploy into a container.
  5. Run health checks to confirm the server is accepting requests.
  6. Route traffic to the new version.
  7. Monitor for errors after the switch.

If something goes wrong, rollback means reverting the server version, not just swapping files. You need to handle database connections, session state, and cache invalidation. It is more complex, but necessary when users need fresh data on every page load.

The Middle Ground: Static Site Generation

There is a hybrid approach called static site generation (SSG). It looks like SSR during build time but behaves like a static site at runtime. The rendering happens once during the build, not on every request. The result is a set of pre-rendered HTML files that can be served statically.

SSG works well for content that does not change every second. Blog posts, documentation pages, product pages fetched from a CMS — these can be rendered at build time and served as static files. The user gets fast page loads, and you avoid managing a server runtime.

But SSG has a trade-off. If your content changes frequently, you need to rebuild and redeploy the entire site. For a blog with one new post per week, that is fine. For an e-commerce site with inventory updates every minute, SSG becomes impractical.

What This Means for Your Pipeline

The choice between static, SSR, and SSG is not just about architecture. It is about how often your content changes, how fast users need to see updates, and how much operational overhead your team can handle.

Here is a quick way to think about it:

The diagram below walks through the decision and shows the corresponding pipeline for each path.

flowchart TD A[Does the app need a server?] -->|No| B[Static Frontend] A -->|Yes| C[Content changes constantly?] C -->|No| D[SSG - Static Site Generation] C -->|Yes| E[SSR - Server-Side Rendering] B --> F[Build static files] F --> G[Upload to CDN / S3] G --> H[Serve files] D --> I[Build & pre-render HTML] I --> J[Upload static output] J --> K[Serve as static files] E --> L[Build server code] L --> M[Install runtime deps] M --> N[Start server process] N --> O[Health check & route traffic]
  • Static: Content rarely changes. Users can tolerate a small delay before data appears. You want the simplest possible deployment.
  • SSR: Content changes constantly. Users need fresh data on every page load. You are willing to manage a server runtime.
  • SSG: Content changes periodically. You want fast page loads without running a server. You can rebuild the site when content updates.

Your pipeline should follow this decision, not fight it. If you choose static, do not add unnecessary server management. If you choose SSR, do not pretend it is just a folder of files.

A Practical Checklist Before You Decide

Before you commit to a deployment strategy, answer these questions:

  • How often does the content on this page change? Every second, every hour, or every week?
  • Can users wait for JavaScript to fetch data after the page loads, or do they need the content immediately?
  • Does your team have the capacity to manage a server runtime, including monitoring, restarts, and rollbacks?
  • How fast do you need to recover from a bad deployment? Swapping files is faster than restarting a server.
  • Will the same page look different for different users based on their session or location?

Your answers will point you toward the right approach. Do not let the framework or the hype decide for you.

The Concrete Takeaway

A static frontend is a folder of files. An SSR frontend is a running application. Treat them differently in your pipeline, and you will avoid unnecessary complexity or missing critical steps. Start with the simplest approach that meets your users' need for fresh content, and only add server-side rendering when the data demands it.