A senior DevOps engineer unpacks the State of React survey, revealing that the biggest challenge isn’t the code, but the massive shift in deployment strategies required by modern frameworks like Next.js.

My Take on the 2024 State of React Survey: It’s Not About The Code, It’s About The Deployment

I remember the Slack message from Alex, one of our sharp junior devs, on a Thursday afternoon. “Hey Darian, I finished the new marketing microsite. Just need to get it on a server. It’s a simple Next.js app, should be easy.” An hour later, my PagerDuty alert went off. One of our shared Nginx reverse proxies, `prod-web-gateway-01`, was throwing 502 Bad Gateway errors. Alex, with the best of intentions, had tried to treat his Next.js app like the old Create React App projects we used to deploy. He dropped the build output into a folder and pointed Nginx at it, expecting magic. What he got was a crash loop. This, right here, is my biggest takeaway from the State of React survey. The tools have evolved faster than our deployment patterns, and it’s causing real-world friction.

The Real Problem: Your React App is Now a Server

Reading through the survey, the dominance of frameworks like Next.js (and its Server Components) is no surprise. They’re powerful, and developers love them. But here’s the part that gets lost in the hype: we’re not just shipping a bundle of static HTML, CSS, and JS to an S3 bucket anymore. We are shipping a stateful, long-running Node.js application.

This is a fundamental architectural shift that has massive implications for us in DevOps and infrastructure:

• Deployment: You can’t just `rsync` a build folder. You need to manage a running process, handle ports, and ensure it restarts on failure.
• Scaling: A simple S3 bucket scales infinitely for static files. A Node.js server needs load balancing, health checks, and a strategy for horizontal scaling (adding more instances).
• Observability: Logging isn’t just about Nginx access logs anymore. You need application-level logging, performance monitoring (APM), and ways to debug a server process, not just a browser console.

When Alex tried to deploy his app, he wasn’t deploying a website; he was trying to deploy a server without realizing it. That’s the disconnect. So, how do we fix it?

Three Ways to Tame the Modern React App

Let’s walk through the options, from the quick-and-dirty fix to the architecturally sound solution.

Solution 1: The ‘Get It Working By EOD’ Fix

This is the classic “make it work on the existing EC2 instance” approach. It’s fast, uses tools you already know, but it’s brittle and doesn’t scale well. You basically turn a Node.js process manager like PM2 into a makeshift service and put your existing Nginx server in front of it as a reverse proxy.

Step 1: Install PM2 and run the app. You’d SSH into the server, `app-web-02`, and run:

# Install PM2 globally
npm install pm2 -g

# Go to your app directory
cd /var/www/my-next-app

# Run the production build
npm run build

# Start the app with PM2
pm2 start npm --name "my-next-app" -- start

Step 2: Configure Nginx as a reverse proxy. You then edit your Nginx config to pass requests for your domain to the running Node.js process (which Next.js defaults to port 3000).

server {
    listen 80;
    server_name my-new-app.techresolve.com;

    location / {
        proxy_pass http://localhost:3000;
        proxy_http_version 1.1;
        proxy_set_header Upgrade $http_upgrade;
        proxy_set_header Connection 'upgrade';
        proxy_set_header Host $host;
        proxy_cache_bypass $http_upgrade;
    }
}

Warning: This is a technical trap. It works for one app, but it turns your server into a fragile monolith. Multiple apps compete for memory and CPU, and a crash in one can impact others. Use this to get out of a jam, but have a plan to move to a better solution.

Solution 2: The ‘Do It Right’ Architecture (Containerization)

This is the modern, sustainable approach. We treat the Next.js application as the self-contained service it is. We package it in a Docker container and run it on a proper container orchestration platform like AWS ECS Fargate or Kubernetes (EKS).

First, you need a Dockerfile in your project root:

# Use the official Node.js 18 image
FROM node:18-alpine AS base

# 1. Install dependencies only when needed
FROM base AS deps
RUN apk add --no-cache libc6-compat
WORKDIR /app
COPY package.json yarn.lock* package-lock.json* pnpm-lock.yaml* ./
RUN \
  if [ -f yarn.lock ]; then yarn install --frozen-lockfile; \
  elif [ -f package-lock.json ]; then npm ci; \
  elif [ -f pnpm-lock.yaml ]; then yarn global add pnpm && pnpm i --frozen-lockfile; \
  else echo "Lockfile not found." && exit 1; \
  fi

# 2. Build the app
FROM base AS builder
WORKDIR /app
COPY --from=deps /app/node_modules ./node_modules
COPY . .
RUN npm run build

# 3. Production image
FROM base AS runner
WORKDIR /app
ENV NODE_ENV=production
COPY --from=builder /app/public ./public
COPY --from=builder /app/.next/standalone ./
COPY --from=builder /app/.next/static ./.next/static

EXPOSE 3000
ENV PORT 3000

CMD ["node", "server.js"]

From here, you build this image, push it to a registry (like ECR), and define a service in ECS or a deployment in Kubernetes. This gives you isolated environments, easy scaling, rolling updates, and proper health checks. It’s more work upfront but pays for itself in stability and scalability.

Solution 3: The ‘Let Someone Else Handle It’ Option

This is my favorite option for many projects, especially front-end focused ones. Platforms like Vercel (from the creators of Next.js) and Netlify are purpose-built for this. You connect your Git repository, and they handle everything: the build pipeline, running the Node.js serverless functions, CDN distribution, and scaling.

You’re abstracting away the infrastructure entirely. Your job becomes `git push`, and their platform does the rest. It’s often not the cheapest option for massive-scale applications, but for most marketing sites, blogs, and internal apps, the time and salary saved on DevOps effort makes it a massive win.

Comparing The Approaches

Let’s break down the trade-offs in a way management can understand.

So, the next time a developer says they’re building a “simple React app,” my first question isn’t “Which state manager are you using?”. It’s “How are we going to run it in production?”. The State of React survey confirms that the frontend world has moved on from static files. It’s our job in DevOps to build the right platforms to support them without burning the whole infrastructure down.

Darian Vance

Lead Cloud Architect & DevOps Strategist

With over 12 years in system architecture and automation, Darian specializes in simplifying complex cloud infrastructures. An advocate for open-source solutions, he founded TechResolve to provide engineers with actionable, battle-tested troubleshooting guides and robust software alternatives.

🤖 Frequently Asked Questions