---
title: "How I Made My Next.js Portfolio Actually Production-Ready (For $0)"
author: "Rantideb Howlader"
date: "2026-04-09T00:00:00.000Z"
canonical_url: "https://www.ranti.dev/blog/production-ready-nextjs-ci-cd-edge-firewall"
license: "CC-BY-4.0"
---
I'll be honest. For a long time, my portfolio was held together with hope.
The animations were smooth. The Lighthouse scores were green. It looked great in a demo. But if you pulled back the curtain, the reality was embarrassing: no CI pipeline, no automated tests, no rate limiting on the API routes, and nothing stopping a broken import from nuking the entire live site.
I'd push to `main`, refresh the browser, and pray.
That's not how real production software works. At any serious company, code goes through layers of automated checks before it reaches users. Bad formatting gets rejected at commit time. Builds are verified in isolated environments. API endpoints are protected from abuse. These aren't luxuries. They're table stakes.
So I decided to build all of it into my portfolio. Not to over-engineer a personal site, but to actually understand, hands-on, what production infrastructure feels like when you're the one setting it up.
The surprising part? Every tool I used is open-source, and I didn't spend a single dollar.
Here's the full breakdown.
## What I Was Actually Solving For
Before I started, I wrote down the specific failure modes I wanted to eliminate:
```mermaid
graph TD
A["My Portfolio Before"] --> B["No CI Pipeline"]
A --> C["No Automated Tests"]
A --> D["Open API Routes"]
A --> E["Analytics Blocking UI"]
B --> F["Broken commits reach production"]
C --> G["Silent regressions on 40+ routes"]
D --> H["Bots can drain Firebase quota"]
E --> I["Animations stutter on cheap phones"]
style A fill:#991b1b,stroke:#fca5a5,color:#fca5a5
style F fill:#7f1d1d,stroke:#f87171,color:#fca5a5
style G fill:#7f1d1d,stroke:#f87171,color:#fca5a5
style H fill:#7f1d1d,stroke:#f87171,color:#fca5a5
style I fill:#7f1d1d,stroke:#f87171,color:#fca5a5
```
Each of these is a real problem. Not theoretical. The Firebase one especially. A basic `while true; do curl` loop pointed at my `/api/spotify` route could burn through my entire daily quota in under 10 minutes.
I started with five layers of defense, each catching a different class of failure.
## Layer 1: Kill Bad Code at the Keyboard (Husky + Prettier)
The cheapest bug to fix is the one that never makes it into your Git history. That's what "shift left" means in practice: move your quality gates as early in the pipeline as possible.
I set up three tools that chain together:
```mermaid
sequenceDiagram
participant Dev as Developer
participant Git as git commit
participant Husky as Husky Hook
participant LS as lint-staged
participant P as Prettier + ESLint
Dev->>Git: git commit -m "fix header"
Git->>Husky: Pre-commit hook triggered
Husky->>LS: Identify staged files only
LS->>P: Format & lint staged files
alt Code passes
P-->>Git: Allow commit
else Code fails
P-->>Dev: Reject commit with errors
end
```
**Husky** intercepts `git commit` before Git records anything. **lint-staged** identifies only the files you've changed (no point scanning your entire codebase every time). **Prettier** reformats those files to a strict, consistent style.
If there's a syntax issue or ESLint violation, the commit gets rejected before it even exists in your local history.
### Setup
```bash
pnpm add -D husky prettier lint-staged
npx husky init
```
The pre-commit hook (`.husky/pre-commit`):
```bash
#!/bin/sh
pnpm exec lint-staged
```
The lint-staged config (`.lintstagedrc.js`):
```javascript
module.exports = {
"*.{js,jsx,ts,tsx,json,css,md}": ["prettier --write"],
};
```
Three files. That's it. Every developer who touches the repo now has automatic formatting enforced at the Git level. No IDE plugins required, no "please remember to run prettier" messages in Slack.
### The First Run Is Painful (And That's the Point)
When I first ran Prettier across my codebase, it flagged **326 files** with inconsistencies. Tabs vs spaces, trailing commas, quote style. Years of accumulated drift. I ran `pnpm prettier --write` once, committed the mass-format, and never thought about it again.
That single commit was probably the highest-impact code quality improvement I've ever made.
## Layer 2: Verify Every Push in Isolation (GitHub Actions)
Pre-commit hooks run on your laptop. But what if someone clones the repo without Husky installed? What if they force-push? You need a second gate that runs on neutral ground.
```mermaid
graph LR
A["git push"] --> B["GitHub Actions Triggered"]
B --> C["Install Dependencies"]
C --> D["Run ESLint"]
D --> E["Check Prettier"]
E --> F["Full Production Build"]
F -->|Pass| G["✅ Green Checkmark"]
F -->|Fail| H["❌ PR Blocked"]
class G mm-green
style H fill:#991b1b,stroke:#f87171,color:#fca5a5
```
Every push to `main` and every pull request triggers this pipeline. It installs dependencies from scratch (no cache shortcuts), lints the code, checks formatting in read-only mode, and runs a full production build.
```yaml
name: CI
on:
push:
branches: ["main"]
pull_request:
branches: ["main"]
jobs:
build-and-lint:
runs-on: ubuntu-latest
env:
FORCE_JAVASCRIPT_ACTIONS_TO_NODE24: true
steps:
- uses: actions/checkout@v4
- uses: pnpm/action-setup@v3
with:
version: 10
- uses: actions/setup-node@v4
with:
node-version: "20"
cache: "pnpm"
- run: pnpm install
- run: pnpm lint
- run: pnpm prettier --check "**/*.{js,jsx,ts,tsx,json,css,md}"
- run: pnpm build
```
If any step fails, the commit gets a red X and merging is blocked.
### Quick Note: The Node.js Version Confusion
You might notice `FORCE_JAVASCRIPT_ACTIONS_TO_NODE24` alongside `node-version: "20"`. These are two completely different things.
GitHub Actions uses Node.js internally to run its own action scripts (`actions/checkout`, etc.). That internal runtime is migrating to Node 24. The env flag tells GitHub's scaffolding to use the newer version, which suppresses deprecation warnings.
Your actual application still builds on Node 20. They're separate execution contexts running on the same machine.
## Layer 3: Catch What Linting Can't (Vitest + Playwright)
Linting catches syntax problems. The build step catches type errors. But neither catches behavioral regressions, the kind where a change to a shared utility function silently breaks three pages you haven't opened in months.
I set up two layers of testing:
```mermaid
graph TD
A["Testing Strategy"] --> B["Unit Tests - Vitest"]
A --> C["E2E Tests - Playwright"]
B --> D["Component isolation"]
B --> E["Utility function logic"]
B --> F["Mocked JSDOM environment"]
B --> G["Runs in milliseconds"]
C --> H["Real browser engines"]
C --> I["Full navigation flows"]
C --> J["Network request assertions"]
C --> K["Multi-browser: Chromium + WebKit"]
style B fill:#1e3a5f,stroke:#60a5fa,color:#bfdbfe
style C fill:#3b1f5e,stroke:#a78bfa,color:#ddd6fe
```
**Vitest** handles unit tests. Isolated component rendering, utility function logic, expected return values. It uses JSDOM to simulate a browser environment without actually opening one, so tests complete in milliseconds.
**Playwright** handles the scary stuff. It launches real Chromium and WebKit browsers, navigates your routes, clicks buttons, waits for API responses, and asserts that specific elements appeared on the page. If a hydration mismatch or CSS layout break happens, Playwright catches it.
```typescript
// playwright.config.ts
import { defineConfig } from "@playwright/test";
export default defineConfig({
testDir: "./e2e",
webServer: {
command: "pnpm dev",
port: 3000,
reuseExistingServer: !process.env.CI,
},
projects: [
{ name: "chromium", use: { browserName: "chromium" } },
{ name: "webkit", use: { browserName: "webkit" } },
],
});
```
Together, these two layers mean I can refactor a shared component and know within seconds whether I've broken anything downstream.
## Layer 4: Stop Bots at the Door (Upstash Edge Rate Limiting)
This is the part that I'm genuinely proud of. Not because the code is complicated. It's shockingly simple. But because the architecture is so clean.
### The Problem
My portfolio makes real API calls. `/api/spotify` fetches my currently playing track. `/api/gallery` pulls photo metadata from Cloudinary. `/api/push` handles Firebase push notifications.
Each of these calls a downstream service with usage quotas. Firebase's free tier gives you 50,000 reads per day. A bot running `curl` in a loop at 100 requests/second would exhaust that quota in under **9 minutes**.
### The Solution
Instead of adding rate limiting to each individual route (fragile, repetitive), I put it in the **middleware layer**. In Next.js, middleware runs at Vercel's Edge, geographically close to the user, before the request ever reaches your serverless function.
Here's how the request flow works at a high level:
```mermaid
sequenceDiagram
participant User
participant MW as Vercel Edge (Middleware)
participant Redis as Upstash Redis
participant API as Next.js API
User->>MW: Request /api/data
MW->>Redis: Check slidingWindow(IP)
Redis-->>MW: Return status (Limit exceeded?)
alt If Remaining > 0
MW->>API: Pass traffic
API-->>User: Return 200 OK
else If Limit Exceeded
MW-->>User: Return 429 Too Many Requests
end
```
And here's the expanded version showing how the database stays protected:
```mermaid
sequenceDiagram
participant User
participant Edge as Vercel Edge
participant Redis as Upstash Redis
participant API as Next.js API Route
participant DB as Firebase / Cloudinary
User->>Edge: GET /api/spotify
Edge->>Redis: Check IP rate (slidingWindow)
Redis-->>Edge: 7/10 remaining
alt Within Limit
Edge->>API: Forward request
API->>DB: Fetch data
DB-->>API: Return data
API-->>User: 200 OK + data
else Limit Exceeded
Edge-->>User: 429 Too Many Requests
Note right of Edge: API never executes.
DB quota untouched.
end
```
The critical insight here: when the rate limit triggers, **the API route never executes**. The request gets bounced at the network edge. Your Firebase quota, your Cloudinary bandwidth, your serverless function invocations. None of them are touched.
### The Code
```typescript
// src/middleware.ts
import { Ratelimit } from "@upstash/ratelimit";
import { Redis } from "@upstash/redis";
const ratelimit = process.env.UPSTASH_REDIS_REST_URL
? new Ratelimit({
redis: Redis.fromEnv(),
limiter: Ratelimit.slidingWindow(10, "10 s"),
analytics: true,
})
: null;
export async function middleware(request: NextRequest) {
const response = NextResponse.next();
// Only rate-limit API routes
if (request.nextUrl.pathname.startsWith("/api") && ratelimit) {
const ip = request.ip ?? "127.0.0.1";
const { success, limit, reset, remaining } = await ratelimit.limit(ip);
// Professional rate limit headers (same pattern as GitHub/Stripe APIs)
response.headers.set("X-RateLimit-Limit", limit.toString());
response.headers.set("X-RateLimit-Remaining", remaining.toString());
response.headers.set("X-RateLimit-Reset", reset.toString());
if (!success) {
return new NextResponse("Too many requests, slow down.", {
status: 429,
});
}
}
return response;
}
```
`slidingWindow(10, '10 s')` means: 10 requests per 10-second rolling window, per IP. The "sliding" part matters. It's not a hard reset every 10 seconds. It continuously tracks request frequency, so you can't game it by timing your bursts.
### Why Upstash Specifically
Three reasons:
1. **Serverless-native.** Upstash exposes Redis over a REST API (HTTPS), which means it works in Vercel Edge functions. Regular Redis uses TCP connections, which Edge functions don't support.
2. **Fast.** Rate limit checks complete in under 5 milliseconds because Upstash replicates data globally.
3. **Free.** 10,000 commands/day, 256 MB storage. For a rate limiter storing IP addresses (~15 bytes each), that's enough to track millions of concurrent visitors.
### Graceful Degradation
Notice the conditional: `process.env.UPSTASH_REDIS_REST_URL ? new Ratelimit(...) : null`. If the environment variables aren't set (local development, for instance), the rate limiter just doesn't activate. The middleware still runs, still sets security headers, but skips rate limiting entirely.
No crashes. No errors. Features should degrade gracefully, not explode loudly.
## Layer 5: Lock Down the Browser (Content Security Policy)
While I was already inside `middleware.ts`, I hardened the **Content Security Policy** (CSP). This is probably the most underrated security mechanism in web development.
CSP tells the browser exactly which domains are allowed to load scripts, styles, images, and frames on your page. Without it, a cross-site scripting (XSS) attack could inject a `