Ravindra BagaleCourses & study guides मराठी Track your progress

Guides

How to Set Up CI/CD for a React App on AWS

CI builds React, syncs dist to S3, invalidates CloudFront, and verifies the URL. Prefer OIDC over long-lived keys.

Friends, React static files love S3 plus CloudFront. Chala mitrano — build on push, sync, invalidate, verify.

Quick answer

Hold this vertical picture:

  1. Build with npm ci locally first.
  2. Sketch the workflow file.
  3. Sync dist to S3.
  4. Invalidate CloudFront.
  5. Verify with curl; prefer OIDC.

Language: English · मराठी · हिंदी

Push to mainWorkflow starts npm ci && builddist/ folder aws s3 syncUpload to bucket CloudFront invalidateClear edge cache curl the URLVerify production
React CI/CD on AWS

Why this path

A React app is static files after build — S3 plus CloudFront is the common AWS pattern at Infosys client projects.

Why: Repeatable deploys on every push. What: CI build → S3 sync → CloudFront invalidate. How: Sketch the workflow and verify URL.

Example 1: Local production build

Type this:

printf "%s\n" "npm ci" "npm run build" "ls dist | head"

You will see:

npm ci
npm run build
ls dist | head

What it means: CI must run the same clean install and build your laptop uses.

Example 2: Workflow sketch (no secrets in file)

Type this:

mkdir -p /tmp/react-ci/.github/workflows && printf "%s\n" "name: deploy-react" "on:" "  push:" "    branches: [main]" "jobs:" "  build-deploy:" "    runs-on: ubuntu-latest" "    steps:" "      - uses: actions/checkout@v4" "      - run: npm ci && npm run build" "      - run: aws s3 sync dist/ s3://APP_BUCKET/ --delete" "      - run: aws cloudfront create-invalidation --distribution-id DIST_ID --paths /*" > /tmp/react-ci/.github/workflows/deploy.yml && wc -l /tmp/react-ci/.github/workflows/deploy.yml

You will see:

16 /tmp/react-ci/.github/workflows/deploy.yml

What it means: Skeleton only — replace APP_BUCKET and DIST_ID; prefer OIDC role assumption over stored keys.

Example 12: React AWS card

Type this:

printf "%s\n" "1 npm ci build 2 s3 sync 3 invalidate 4 curl verify 5 OIDC not long keys"

You will see:

1 npm ci build 2 s3 sync 3 invalidate 4 curl verify 5 OIDC not long keys

What it means: Memorize for CI/CD interviews.

Concept 1: Build then sync

CI creates dist/; sync uploads it.

Why: Same artifacts every time. What: npm ci && npm run build; aws s3 sync How: Use --delete with care.

Example 1: Local production build

Type this:

printf "%s\n" "npm ci" "npm run build" "ls dist | head"

You will see:

npm ci
npm run build
ls dist | head

What it means: CI must run the same clean install and build your laptop uses.

Example 4: Sync command meaning

Type this:

printf "%s\n" "aws s3 sync dist/ s3://APP_BUCKET/ --delete"

You will see:

aws s3 sync dist/ s3://APP_BUCKET/ --delete

What it means: --delete removes old assets not in dist — careful on shared buckets.

Example 8: Cache node modules (optional)

Type this:

printf "%s\n" "actions/setup-node with cache: npm speeds CI"

You will see:

actions/setup-node with cache: npm speeds CI

What it means: Faster pipelines without changing the build result.

Concept 2: CloudFront and SPA

Edge cache and client routes need config.

Why: Users must see new JS; deep links must work. What: create-invalidation; error pages to index.html How: Verify with curl.

Example 5: Invalidate edge cache

Type this:

printf "%s\n" "aws cloudfront create-invalidation --distribution-id DIST_ID --paths /*"

You will see:

aws cloudfront create-invalidation --distribution-id DIST_ID --paths /*

What it means: Without invalidation users may see old JS for minutes or hours.

Example 9: Verify after deploy

Type this:

printf "%s\n" "curl -I https://www.example.com" "curl -s https://www.example.com | head"

You will see:

curl -I https://www.example.com
curl -s https://www.example.com | head

What it means: Check status and that new bundle hashes appear.

Example 11: SPA routing note

Type this:

printf "%s\n" "CloudFront error pages: 403/404 -> /index.html for client routers"

You will see:

CloudFront error pages: 403/404 -> /index.html for client routers

What it means: React Router deep links need this when using S3 origin.

Concept 3: Security and rollback

No long-lived keys when OIDC works; plan rollback.

Why: Auditors ask how you authenticate deploy. What: OIDC roles; versioning or redeploy tag How: Add reviewers on production.

Example 3: S3 bucket for static site notes

Type this:

printf "%s\n" "Block public access appropriately" "Origin Access Control to CloudFront" "Versioning optional for rollback"

You will see:

Block public access appropriately
Origin Access Control to CloudFront
Versioning optional for rollback

What it means: Do not open the bucket to the world if CloudFront is the front door.

Example 6: OIDC note

Type this:

printf "%s\n" "Prefer role assumption via OIDC" "Avoid long-lived AWS keys in repository secrets when policy allows"

You will see:

Prefer role assumption via OIDC
Avoid long-lived AWS keys in repository secrets when policy allows

What it means: Interviewers at Amazon-style teams ask this.

Example 7: Environment protection

Type this:

printf "%s\n" "Use a production environment with required reviewers for main deploys"

You will see:

Use a production environment with required reviewers for main deploys

What it means: Pairs with the manual approval guide later in this series.

Example 10: Rollback idea

Type this:

printf "%s\n" "Keep previous dist in S3 versioning or redeploy last known good tag"

You will see:

Keep previous dist in S3 versioning or redeploy last known good tag

What it means: Plan rollback before peak sale days like Flipkart Big Billion style events.

React AWS card

  1. npm ci && npm run build
  2. aws s3 sync dist/ s3://BUCKET/ --delete
  3. CloudFront invalidate /*
  4. curl the site
  5. Prefer OIDC over long-lived keys

Suppose: Blank page after deploy

Check invalidation and correct bucket path.

Map CloudFront 403/404 to /index.html.

Ravindra Bagale's Tip

Infosys and TCS front-end pipelines often use OIDC to AWS — no long-lived access keys in the workflow.

Check yourself (quiz)

Q1. Why S3+CloudFront?

Static build artifacts served at the edge

Q2. Why invalidate?

Clear cached old JS/CSS at edge locations

Q3. OIDC vs keys?

Prefer short-lived role via OIDC when allowed

Q4. SPA deep links?

CloudFront error pages to /index.html

Q5. Verify how?

curl -I and spot-check HTML/JS

Q6. Rollback?

S3 versioning or redeploy last good build

Reading tracking

Mark this guide when you finish. Your browser remembers it on this device.

build → s3 sync → invalidate → curl. OIDC over long keys. Did you understand? Let us try it once more.

Frequently asked questions

Why S3 and CloudFront?

Static hosting at the edge after npm build.

Why invalidate?

Old JS may stay cached without it.

OIDC?

Short-lived role assumption instead of long-lived keys.

SPA 404 fix?

Map CloudFront errors to /index.html.

Verify?

curl -I and check the page.

Rollback?

S3 versioning or redeploy last good build.