You Outgrew Cloudflare Pages — Here's What Comes Next

TL;DR — Cloudflare Pages is great for static sites. The moment you need server-side rendering, a managed database, background jobs, WebSockets, or anything beyond a glorified CDN, you hit walls. RaidFrame gives you everything Pages doesn't — Docker containers, managed Postgres/Redis, cron jobs, and real SSR — at VPS prices.

Why developers pick Cloudflare Pages

The pitch is compelling. Free static hosting, global CDN, fast builds, Git integration. For a marketing site or docs page, it's genuinely good.

But most apps don't stay static. You add authentication. Then a database. Then background jobs. Then real-time features. And suddenly you're duct-taping five Cloudflare products together.

Where Cloudflare Pages breaks down

No real server-side rendering

Pages is a static hosting platform. You can bolt on Cloudflare Workers for dynamic functionality, but Workers aren't a Node.js runtime. They run on V8 isolates with a completely different execution model.

That means:

• No native fs module
• No long-running processes
• No streaming responses beyond what the Workers runtime supports
• Next.js support via @cloudflare/next-on-pages is experimental and breaks regularly

If your framework expects a Node.js server (Next.js, Remix, Nuxt, SvelteKit with SSR), you're fighting the platform instead of building your product.

The 1MB Worker size limit

Each Cloudflare Workers function is capped at 1MB after compression on the free tier, and 10MB on paid plans. That includes your code and all dependencies.

One node_modules import chain and you're over the limit. Prisma alone exceeds it. Any ORM with a query engine won't fit.

# Check your Worker bundle size
npx wrangler deploy --dry-run --outdir dist
du -sh dist/*
# If it's over 1MB compressed — you have a problem.

No managed databases

Cloudflare has D1 (SQLite-based) and Hyperdrive (connection pooling for external databases). Neither is managed Postgres. D1 is still in open beta with significant limitations:

• SQLite semantics, not Postgres
• 10GB max database size (free), 50GB (paid)
• No extensions, no PostGIS, no jsonb indexing
• Limited to 1,000 rows per query result

If your app uses Postgres, you need an external database provider. Now you're managing Cloudflare Pages + Workers + an external DB, paying two companies, and dealing with cross-network latency.

No background jobs or cron

Pages has no built-in way to run scheduled tasks. You can set up Workers Cron Triggers, but that's a separate Worker deployment with its own configuration, its own codebase, and its own debugging workflow.

Want to send a daily email digest? Process uploaded images? Clean up expired sessions? Each one is a separate Worker with a separate wrangler.toml.

No WebSocket support

Cloudflare Pages doesn't support WebSockets. You need Durable Objects for stateful real-time connections — a separate product with its own pricing, its own programming model, and a steep learning curve.

Building a chat feature? Live dashboard? Collaborative editor? You're now deep into Cloudflare's proprietary runtime.

No Docker containers

You can't run arbitrary containers on Cloudflare Pages. Your app must conform to their build system and Workers runtime. If your backend is a Go binary, a Python FastAPI server, or a Rust service — Pages can't run it.

Build minute limits

500 build minutes sounds generous until you have a monorepo with a 4-minute build that deploys 6 times a day. That's 720 minutes/month — you're over the free tier in 3 weeks.

The Cloudflare Complexity Tax

Here's what a "real" app looks like on Cloudflare's ecosystem:

That's seven products to do what a single rf deploy handles on RaidFrame. Seven billing line items. Seven sets of documentation. Seven things that can break independently.

The same app on RaidFrame

rf login
rf init
rf add postgres
rf add redis
rf cron add "0 9 * * *" "node scripts/daily-digest.js"
rf deploy

Done. Your app runs as a real Node.js process (or Docker container) with:

• Full SSR — Next.js, Remix, Nuxt, whatever you want
• Managed PostgreSQL with no size limits on free tier queries
• Managed Redis for caching and queues
• Cron jobs that run inside your app's environment
• WebSocket support out of the box
• SSL, custom domains, auto-scaling

No bindings. No isolates. No "deploy this as a separate Worker."

How to migrate from Cloudflare Pages

Step 1: Remove Cloudflare-specific code

Strip out Workers bindings and @cloudflare/next-on-pages adapter. Replace D1 calls with standard Postgres queries via Prisma, Drizzle, or your ORM of choice.

npm uninstall @cloudflare/next-on-pages wrangler
npm install prisma @prisma/client

Step 2: Add a Dockerfile (optional)

RaidFrame auto-detects most frameworks. But if you want full control:

FROM node:20-alpine
WORKDIR /app
COPY package*.json ./
RUN npm ci
COPY . .
RUN npm run build
EXPOSE 3000
CMD ["npm", "start"]

Step 3: Deploy

npm install -g @raidframe/cli
rf login
rf init
rf add postgres
rf deploy

Your app is live at your-app.raidframe.app with SSL, managed Postgres, and a real server runtime. Migration takes 15-30 minutes for most projects.

Step 4: Update DNS

Point your custom domain to RaidFrame:

rf domains add yourdomain.com

Update your DNS A record. RaidFrame provisions an SSL certificate automatically.

Cost comparison

On Cloudflare, costs scale unpredictably as you add products. On RaidFrame, you know exactly what you're paying.

FAQ

Is Cloudflare Pages bad?

It was useful for static sites — a CDN with Git-based deploys. If your site is truly static (marketing pages, docs, blogs), Pages can work. But most teams outgrow it fast once they need server-side logic, databases, or background processing.

Do I need a separate CDN with RaidFrame?

No. RaidFrame includes edge caching and DDoS protection. You shouldn't need to bolt on a separate CDN — your hosting platform should handle this out of the box.

What about Cloudflare Workers as a standalone platform?

Workers is a different product from Pages. It's more capable but has its own limitations — V8 isolate execution model, no native Node.js APIs, no Docker, no managed Postgres. If your app fits the Workers model, great. Most full-stack apps don't.

How long does migration take?

For a static site with a few API routes: 15-30 minutes. For a complex app with D1, KV, R2, and Durable Objects: a few hours to replace Cloudflare-specific APIs with standard libraries.

Will I lose Cloudflare's edge network speed?

RaidFrame deploys to multi-region infrastructure with built-in edge caching. For most apps, the latency difference is negligible — your database query takes 50ms, not the 2ms CDN difference.

Does RaidFrame support monorepos?

Yes. Use rf init in each service directory. RaidFrame builds and deploys each service independently with shared environment variables.

Related reading

• Deploy Next.js + Postgres for Free
• Deploy Any Docker App on RaidFrame
• Cloud Cost Optimization: Cut Your Bill by 40%
• AI Bots Are Inflating Your Hosting Bill

Stop duct-taping Cloudflare products together. Deploy your full-stack app on one platform — start for free.