OpenNext: استضافة Next.js ذاتياً على AWS و Cloudflare و VPS بدون Vercel

أقوم بتشغيل Next.js في الإنتاج منذ الإصدار 9. لمعظم هذا الوقت، كانت Vercel الخيار الواضح — نشر، نسيان، المضي قدماً. لكن في مكان ما حول عام 2024، بدأت الفواتير تبدو وكأنها أقساط سيارات. عندما تتجاوز فاتورة الاستضافة الخاصة بك لموقع تسويق تكاليف البنية التحتية السحابية الفعلية، يكون هناك شيء معطل. هذا عندما بدأت أحفر في OpenNext، وبعد ترحيل ثلاث تطبيقات إنتاجية من Vercel على مدار السنة الماضية، لدي آراء.

هذا ليس مقال "Vercel سيء". Vercel ممتازة حقاً. لكنها لم تعد الخيار الوحيد، وللعديد من الفرق، فهي ليست الخيار الصحيح. دعني أرشدك عبر كل شيء تعلمته عن استضافة Next.js بنفسي باستخدام OpenNext — الجيد والسيء والمدهش برخص الثمن.

جدول المحتويات

• ما هو OpenNext ولماذا موجود
• مشهد الاستضافة الذاتية في 2025-2026
• هدف النشر: AWS مع SST
• هدف النشر: Cloudflare Workers
• هدف النشر: VPS مع Docker
• مقارنة التكاليف: Vercel مقابل الاستضافة الذاتية
• متى تترك Vercel
• دليل الترحيل
• الأخطاء الشائعة وكيفية تجنبها
• الأسئلة الشائعة

ما هو OpenNext ولماذا موجود

تم تصميم Next.js للتشغيل على Vercel. هذا ليس نظرية مؤامرة — إنها بنية. ميزات مثل ISR (Incremental Static Regeneration)، وMiddleware، وتحسين الصور، والإجراءات على الخادم لها تطبيقات خاصة بـ Vercel مدمجة فيها. عندما تحاول next start على خادم عشوائي، تحصل على مجموعة فرعية من ما يمكن لـ Next.js أن يفعله.

OpenNext هو محول مفتوح المصدر يأخذ إخراج بناء Next.js الخاص بك وينقله إلى حزم نشر تعمل على منصات أخرى. بدأ كمشروع مجتمع SST مركزاً على AWS Lambda، لكن اعتباراً من الإصدار v3 (الإصدار الرئيسي الحالي في 2025)، يدعم أهداف نشر متعددة بما في ذلك Cloudflare Workers وخوادم Node.js التقليدية والمزيد.

إليك ما يتعامل معه OpenNext فعلاً:

• ISR وإعادة التحقق — نظام إعادة التحقق القائم على الوسوم الذي تطبقه Vercel ببنيتها التحتية الداخلية؟ يعيد OpenNext إنشاءها باستخدام DynamoDB + SQS على AWS، أو مخازن KV على Cloudflare.
• تحسين الصور — مكون Next.js <Image> يعتمد على واجهة برمجية لتحسين. يضع OpenNext محسناً قائماً على Sharp أو يوجه إلى حلول خاصة بالمنصة.
• Middleware — يعمل على الحافة على Vercel. يعيّن OpenNext هذا إلى CloudFront Functions أو Cloudflare Workers أو يشغله في العملية على VPS.
• الإجراءات على الخادم — دعم كامل، موجهة من خلال وظيفة الخادم المناسبة.
• البث والعرض المسبق الجزئي — تحسن الدعم بشكل كبير في OpenNext v3.x.

ما لا يكون OpenNext عليه

إنه ليس منصة استضافة. إنه ليس CDN. إنه محول البناء — طبقة ترجمة بين إخراج Next.js والبنية التحتية الخاصة بك. لا تزال بحاجة إلى تشغيل الشيء في مكان ما بالفعل.

مشهد الاستضافة الذاتية في 2025-2026

انفجرت النظام البيئي منذ أن بدأت النظر في هذا لأول مرة. إليك الوضع الحالي:

المنصة	دعم OpenNext	النضج	الأفضل لـ
AWS (عبر SST)	من الدرجة الأولى	جاهز للإنتاج	الفرق الموجودة بالفعل على AWS
Cloudflare Workers	محول رسمي	مستقر (بعض الحالات الحدودية)	تطبيقات موجهة للحافة، تحسين التكاليف
Docker/VPS	مجتمع + رسمي	مستقر	النشرات البسيطة، البنية التحتية الموجودة
Kubernetes	مخططات Helm المجتمع	تطور	المشاريع، مجموعات K8s الموجودة
Netlify	محول مدمج (محولهم الخاص)	جاهز للإنتاج	فرق ملتزمة بـ Netlify
Google Cloud Run	مجتمع	تجريبي	متاجر GCP

المساريان اللذان اختبرتهما بشكل شخصي وأستطيع الاستشهاد بهما هما AWS عبر SST و Docker على VPS. Cloudflare هو الوافد الجديد المثير الذي يتحسن شهرياً.

هدف النشر: AWS مع SST

هذا هو المسار الذهبي. SST (Serverless Stack) لديه دعم مدمج لـ Next.js مدفوعاً بـ OpenNext، وهو حيث ذهب معظم الجهد الهندسي.

نظرة عامة على البنية

عندما تنشر Next.js عبر SST على AWS، إليك ما يتم إنشاؤه:

• توزيع CloudFront — CDN الخاص بك، يتعامل مع الأصول الثابتة والتوجيه
• وظيفة Lambda — العرض من جانب الخادم، مسارات API، إجراءات الخادم
• دلو S3 — الأصول الثابتة، الصفحات المعروضة مسبقاً، ذاكرة التخزين المؤقت ISR
• جدول DynamoDB — تعيين وسوم ISR لإعادة التحقق
• طابور SQS — معالجة إعادة التحقق غير المتزامنة
• CloudFront Function أو Lambda@Edge — تنفيذ Middleware

يبدو وكأنه الكثير. هو كذلك. لكن SST يجرد كل هذا إلى حوالي 20 سطر من الإعدادات.

إعدادات SST

إليك sst.config.ts حقيقي من أحد مشاريعي الإنتاجية:

/// <reference path="./.sst/platform/config.d.ts" />

export default $config({
  app(input) {
    return {
      name: "my-nextjs-app",
      removal: input.stage === "production" ? "retain" : "remove",
      home: "aws",
      providers: {
        aws: {
          region: "us-east-1",
        },
      },
    };
  },
  async run() {
    const site = new sst.aws.Nextjs("Site", {
      domain: {
        name: "myapp.com",
        dns: sst.aws.dns(),
      },
      warm: 5, // keep 5 Lambda instances warm
      memory: "1024 MB",
      environment: {
        DATABASE_URL: process.env.DATABASE_URL!,
        NEXT_PUBLIC_API_URL: "https://api.myapp.com",
      },
    });

    return {
      url: site.url,
    };
  },
});

ثم النشر:

npx sst deploy --stage production

النشر الأول يستغرق 8-12 دقيقة (انتشار توزيع CloudFront). النشرات اللاحقة 2-4 دقائق.

اعتبارات Lambda

أكبر مشكلة في الاستضافة القائمة على Lambda هي البدايات الباردة. وظائف خادم Next.js ليست صغيرة — تبحث عن حزم 20-80MB اعتماداً على التبعيات الخاصة بك. البدايات الباردة تتراوح من 800ms إلى 3 ثواني.

التخفيفات التي استخدمتها:

1. الحد الأدنى من المساحة المخصصة — معامل warm في SST يبقي الحالات ساخنة. في $0.0000041667 لكل GB-second، الحفاظ على 5 نسخ من وظيفة 1GB دافئة يكلف حوالي $15/شهر.
2. حزم أصغر — تدقيق التبعيات من جانب الخادم. وجدت مشروعاً يستورد lodash من جانب الخادم عندما احتجنا فقط إلى lodash/get. انخفضت الحزم من 68MB إلى 31MB.
3. النشر الإقليمي — لا تستخدم Lambda@Edge للعرض من جانب الخادم ما لم تحتج إليه بشدة. Lambda أحادي المنطقة مع تخزين CloudFront مؤقت جيد تماماً لـ 95٪ من التطبيقات.

هدف النشر: Cloudflare Workers

كانت Cloudflare تحقق حركات جادة. وقت تشغيل Workers الخاص بهم يدعم الآن عدداً كافياً من واجهات برمجة تطبيقات Node.js بحيث يمكن لـ Next.js أن يعمل هناك بالفعل، وأصبح محول OpenNext Cloudflare مستقراً بشكل ملحوظ.

الإعداد مع OpenNext Cloudflare

npm install @opennext/cloudflare

أضف إلى wrangler.toml:

name = "my-nextjs-app"
main = ".open-next/worker.js"
compatibility_date = "2025-01-01"
compatibility_flags = ["nodejs_compat_v2"]

[assets]
directory = ".open-next/assets"
binding = "ASSETS"

[[kv_namespaces]]
binding = "NEXT_CACHE_KV"
id = "your-kv-namespace-id"

بناء ونشر:

npx @opennext/cloudflare build
npx wrangler deploy

المقايضات في Cloudflare

الإيجابيات:

• لا بدايات باردة — يتم تشغيل Workers في أقل من 5ms عالمياً
• حافة عالمية بشكل افتراضي — يعمل العرض من جانب الخادم الخاص بك في 300+ موقع
• التسعير المجنون — $5/شهر لـ 10 ملايين طلب على الخطة المدفوعة

السلبيات:

• حدود الذاكرة — 128MB مجاني، 256MB مدفوع. قد تصطدم تطبيقات Next.js الكبيرة بهذا.
• حدود وقت وحدة المعالجة المركزية — 30 ثانية على الخطة المدفوعة. قد تكون صفحات العرض من جانب الخادم الثقيلة مشكلة.
• فجوات توافق Node.js — معظم الأشياء تعمل، لكن إذا كنت تستخدم وحدات عقدة أصلية مثل sharp مباشرة، فستحتاج إلى حلول بديلة. يمكن لـ Cloudflare Images التعامل مع التحسين بدلاً من ذلك.
• بعض ميزات Next.js غير مدعومة — اعتباراً من أوائل 2025، دعم العرض المسبق الجزئي لا يزال تجريبياً على Cloudflare.

لمواقع كثيفة المحتوى وصفحات التسويق، Cloudflare Workers مقنعة بشكل لا يصدق. بالنسبة لتطبيقات ويب معقدة مع منطق ثقيل من جانب الخادم، أود الاستمرار في الاستمرار نحو AWS أو Docker.

هدف النشر: VPS مع Docker

في بعض الأحيان تريد فقط خادماً. لا وظائف Lambda، لا وقت تشغيل الحافة، لا مخطط بنية 47 خدمة. صندوق يشغل الكود الخاص بك. أحترم ذلك.

Dockerfile

إليك Dockerfile الإنتاجي الذي أستخدمه. إنه متعدد المراحل، محسّن، وفعل بالفعل:

# Stage 1: Dependencies
FROM node:20-alpine AS deps
RUN apk add --no-cache libc6-compat
WORKDIR /app
COPY package.json pnpm-lock.yaml ./
RUN corepack enable pnpm && pnpm install --frozen-lockfile

# Stage 2: Build
FROM node:20-alpine AS builder
WORKDIR /app
COPY --from=deps /app/node_modules ./node_modules
COPY . .

ENV NEXT_TELEMETRY_DISABLED=1
ENV NODE_ENV=production

RUN corepack enable pnpm && pnpm build

# Stage 3: Production
FROM node:20-alpine AS runner
WORKDIR /app

ENV NODE_ENV=production
ENV NEXT_TELEMETRY_DISABLED=1

RUN addgroup --system --gid 1001 nodejs
RUN adduser --system --uid 1001 nextjs

COPY --from=builder /app/public ./public
COPY --from=builder --chown=nextjs:nodejs /app/.next/standalone ./
COPY --from=builder --chown=nextjs:nodejs /app/.next/static ./.next/static

USER nextjs

EXPOSE 3000
ENV PORT=3000
ENV HOSTNAME="0.0.0.0"

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

حرج: أنت بحاجة إلى output: 'standalone' في next.config.js:

/** @type {import('next').NextConfig} */
const nextConfig = {
  output: 'standalone',
};

module.exports = nextConfig;

توصيات VPS

شغلت هذا الإعداد على عدة موفرين:

الموفر	المواصفة	التكلفة الشهرية	الملاحظات
Hetzner CAX21	4 vCPU ARM، 8GB RAM	€7.49 (~$8)	أفضل قيمة، مراكز بيانات الاتحاد الأوروبي
DigitalOcean Droplet	2 vCPU، 4GB RAM	$24	تغطية أمريكية جيدة
Fly.io (machine)	2 vCPU، 4GB RAM	~$30	التوسع التلقائي، مناطق عالمية
Railway	استخدام	$5-50	إعداد أسهل، تجربة تطوير تشبه Vercel
AWS EC2 t4g.medium	2 vCPU، 4GB RAM	~$25	بالفعل على AWS

لنشر Docker مباشر، Hetzner ذات قيمة مجنونة. أشغل تطبيق Next.js يخدم 2M+ pageviews/شهر على Hetzner ARM بـ €7.49 خلف CDN مجاني من Cloudflare. الخادم بالكاد يتنفس بصعوبة.

ما تفقده مع Docker/VPS

دعنا نكون صادقين بشأن ما لا يعطيك next start على VPS مقارنة بـ Vercel أو إعداد SST:

• إعادة التحقق من ISR أساسية — ذاكرة تخزين مؤقت على نظام الملفات فقط. لا توجد ذاكرة تخزين مؤقت موزعة عبر عدة حالات. إذا كنت تشغل خادماً واحداً، فهذا جيد. متعدد الخوادم؟ تحتاج إلى Redis أو طبقة ذاكرة تخزين مؤقت مشتركة.
• لا middleware الحافة — يعمل Middleware في العملية، وهو جيد تماماً لمعظم حالات الاستخدام.
• تحسين الصور — يعمل عبر Sharp، لكنك تخدم الصور المحسنة من أصلك الفردي. ضع Cloudflare أو CDN في الأمام.
• لا نشرات ذرية — تحتاج إلى التعامل مع نشرات بدون وقت توقف بنفسك (Docker Compose مع فحوصات صحية، أو وكيل عكسي مثل Caddy/Traefik).

بالنسبة لمعظم التطبيقات في Social Animal، خاصة بناء headless CMS التي نفعلها عبر عمل تطوير headless CMS، VPS واحد مع CDN في الأمام مناسب تماماً.

مقارنة التكاليف: Vercel مقابل الاستضافة الذاتية

دعنا نتحدث عن المال. هذا يستند إلى بيانات فاتورية حقيقية من تطبيق Next.js يفعل حوالي 5M طلب/شهر مع ISR، وتحسين الصور، والعرض المعتدل من جانب الخادم.

عامل التكلفة	Vercel Pro	Vercel Enterprise	AWS/SST	Cloudflare	Hetzner VPS
المنصة الأساسية	$20/user/mo	مخصص (~$3k+/mo)	$0	$5/mo	€7.49/mo
الحوسبة/الطلبات	$150-400/mo	مدرجة	$40-80/mo	$0-15/mo	مدرجة
النطاق الترددي (100GB)	مدرجة	مدرجة	$8.50 (CloudFront)	مدرجة	مدرجة
تحسين الصور	$50-200/mo	مدرجة	$5-15/mo (Lambda)	$5/mo (CF Images)	مدرجة (Sharp)
ISR/ذاكرة التخزين المؤقت	مدرجة	مدرجة	$2-5/mo (DynamoDB)	$0-5/mo (KV)	$0
الإجمالي المقدر	$300-700/mo	$3,000+/mo	$55-110/mo	$10-25/mo	$8-15/mo

أرقام Vercel هذه ليست افتراضية. رأيت الفواتير. التسعير لكل مقعد، والمبالغ الزائدة في تنفيذ الوظائف، والرسوم على النطاق الترددي على طبقة Pro تضيف بسرعة كبيرة لفرق من 5+.

أرقام AWS/SST تفترض حركة معتدلة مع حد أدنى من المساحة المخصصة. تسعير Cloudflare حقاً مجنون — من الصعب حقاً إنفاق أموال حقيقية هناك ما لم تفعل شيئاً غريباً.

متى تترك Vercel

لا تترك فقط لأنك تستطيع. اترك لأنك يجب أن تترك. إليك إطار عملي:

ابقَ على Vercel إذا:

• فريقك صغير (1-3 مطورين) ووقت المطور هو المورد الأغلى لديك
• تنفق أقل من $100/شهر على Vercel
• ليس لديك أي شخص يستمتع بعمل البنية التحتية
• تكرر بسرعة وتحتاج معاينات فورية لكل PR
• تستخدم ميزات خاصة بـ Vercel مثل Analytics أو Speed Insights أو تكاملات Vercel AI SDK

اترك Vercel إذا:

• الفاتورة الشهرية تتجاوز $500 وتنمو
• تحتاج إلى البنية التحتية في مناطق محددة للامتثال (GDPR، إقامة البيانات)
• تشغل بالفعل بنية تحتية كبيرة من AWS/GCP/Cloudflare
• البدايات الباردة على serverless غير مقبولة لحالة الاستخدام الخاصة بك
• تحتاج إلى استراتيجيات ذاكرة تخزين مؤقت مخصصة لا تناسب نموذج Vercel
• ضربت حدود حجم وظيفة Vercel أو حدود وقت التنفيذ

فكر بجدية في الترك إذا:

• أنت على تسعير Vercel Enterprise وكان تجديد العقد للتو
• تطبيقك ثابت في الغالب/ISR وتدفع أسعار SSR الديناميكية
• تريد تشغيل الواجهة الأمامية جنباً إلى جنب مع الخادم الخاص بك في نفس البنية التحتية

دليل الترحيل

فعلت هذا ثلاث مرات الآن. إليك العملية التي أتبعها، مكررة من خلال التجربة الموجعة.

الخطوة 1: تدقيق ميزات Next.js الخاصة بك

قبل أن تلمس أي شيء، قم بفهرسة ميزات Next.js التي تستخدمها فعلاً:

# ابحث عن middleware
find . -name "middleware.ts" -o -name "middleware.js"

# ابحث عن مسارات API
find ./app -name "route.ts" -o -name "route.js" | head -20

# تحقق من ISR
grep -r "revalidate" ./app --include="*.ts" --include="*.tsx" | head -20

# تحقق من الإجراءات على الخادم
grep -r "use server" ./app --include="*.ts" --include="*.tsx" | head -20

# تحقق من next.config للميزات الخاصة
cat next.config.js

الخطوة 2: اختر هدفك

بناءً على التدقيق:

• ISR ثقيل + middleware + تحسين الصور → AWS/SST
• SSR بسيط + موقع محتوى → Cloudflare أو VPS
• البنية التحتية الموجودة لـ Docker/K8s → VPS/Docker
• تحتاج إلى إنجازها بحلول الجمعة → Docker على Railway أو Fly.io

إذا كنت تبني مع Next.js أو Astro، فإن خيار منصة الهدف يؤثر بشكل كبير على قرارات العمارة الخاصة بك.

الخطوة 3: قم بإعداد CI/CD

CI/CD في Vercel حقاً رائع. ستفتقده. كرره مع GitHub Actions:

# .github/workflows/deploy.yml
name: Deploy
on:
  push:
    branches: [main]

jobs:
  deploy:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4

      - uses: pnpm/action-setup@v4
        with:
          version: 9

      - uses: actions/setup-node@v4
        with:
          node-version: 20
          cache: 'pnpm'

      - run: pnpm install --frozen-lockfile
      - run: pnpm build
      - run: pnpm test

      # For SST:
      - run: npx sst deploy --stage production
        env:
          AWS_ACCESS_KEY_ID: ${{ secrets.AWS_ACCESS_KEY_ID }}
          AWS_SECRET_ACCESS_KEY: ${{ secrets.AWS_SECRET_ACCESS_KEY }}

      # For Docker/VPS (alternative):
      # - run: docker build -t myapp .
      # - run: docker push registry.example.com/myapp:latest
      # - run: ssh deploy@server 'cd /app && docker compose pull && docker compose up -d'

الخطوة 4: النشرات المعاينة

هذا هو الشيء الوحيد الذي يفتقده الناس أكثر من Vercel. بالنسبة لـ SST، استخدم المراحل:

# في مسار العمل PR الخاص بك
npx sst deploy --stage pr-${{ github.event.pull_request.number }}

بالنسبة إلى Docker، أدوات مثل Coolify (استضافة ذاتية) أو Railway تتعامل مع نشرات المعاينة بشكل جيد.

الخطوة 5: قطع DNS

لحظة الترحيل الفعلية. أوصي دائماً بـ:

1. نشر للبنية التحتية الجديدة جنباً إلى جنب مع Vercel
2. اختبر بدقة مع نطاق مرحلي
3. خفض TTL لـ DNS إلى 60 ثانية قبل يوم واحد
4. قطع DNS خلال ساعات حركة منخفضة
5. حافظ على نشر Vercel قيد التشغيل لمدة 48 ساعة كنسخة احتياطية
6. راقب معدلات الخطأ وتحميل الصفحة الأول والمقاييس الأساسية للويب بعناية

الخطوة 6: هدم Vercel

بمجرد أن تكون واثقاً (أعطها أسبوعاً على الأقل)، أوقف اشتراك Vercel وأزل المشروع. لا تترك المشاريع الزومبي تراكم الرسوم.

الأخطاء الشائعة وكيفية تجنبها

متغيرات البيئة تختفي. Next.js لديه متغيرات NEXT_PUBLIC_ بادئة (مجمعة في وقت البناء) ومتغيرات الخادم فقط (متاحة في وقت التشغيل). على Vercel، هذا التمييز غير واضح نوعاً ما. على الاستضافة الذاتية، فهو صارم. تأكد من توفر جميع متغيرات NEXT_PUBLIC_ في وقت البناء في CI الخاص بك.

ذاكرة التخزين المؤقت ISR لا تستمر. على Docker، يجب أن يكون دليل .next/cache على حجم مستمر. وإلا، فإن كل إعادة تشغيل للحاوية تفقد الصفحات المخزنة مؤقتاً:

# docker-compose.yml
services:
  web:
    build: .
    ports:
      - "3000:3000"
    volumes:
      - next-cache:/app/.next/cache

volumes:
  next-cache:

فشل تثبيت Sharp. مكتبة تحسين الصور sharp تحتاج إلى ثنائيات خاصة بالمنصة. في Docker، تأكد من تثبيت التبعيات داخل نفس البنية كوقت التشغيل الخاص بك. يتعامل Dockerfile أعلاه مع هذا باستخدام بناء متعدد المراحل مع نفس صورة الأساس.

اختلافات سلوك Middleware. تشغل Vercel middleware على شبكة الحافة الخاصة بهم. على AWS/SST، يعمل كـ CloudFront Function (محدود إلى تنفيذ 10ms، حجم 2MB). قد تحتاج Middleware المعقدة إلى التحرك إلى وظيفة الخادم. اضطررت إلى إعادة صياغة middleware المصادقة بسبب هذه الحدود.

رؤوس وإعادات كتابة مفقودة. إذا كنت تعتمد على vercel.json للرؤوس أو إعادات التوجيه أو إعادة الكتابة، فتحتاج إلى نقل هذه إلى next.config.js أو إعدادات CDN/وكيل عكسي الخاصة بك.

إذا بدا كل هذا مرهقاً، فهذا بالضبط نوع العمل على البنية التحتية الذي نتعامل معه في Social Animal. تحقق من التسعير أو تواصل معنا — قمنا بهذه الترحيلات عدة مرات بما يكفي للحصول على عملية مكررة.

الأسئلة الشائعة

هل OpenNext جاهزة للإنتاج في 2025؟ نعم. OpenNext v3.x يشغل أحمال عمل الإنتاج لآلاف الشركات. مسار SST/AWS هو الأكثر اختباراً بشكل معركة، مع دعم Cloudflare قريب جداً. لن أسمي دعم Google Cloud أو Kubernetes العاري ناضجاً حتى الآن، لكن AWS و Cloudflare متينة.

هل يدعم OpenNext App Router في Next.js و Server Components؟ دعم كامل. App Router، Server Components، Server Actions، البث، و Suspense كلها تعمل. فريق OpenNext يتتبع إصدارات Next.js بعناية، على الرغم من وجود تأخير عادة من 1-3 أسابيع بعد إصدارات Next.js الرئيسية قبل أن يلحق OpenNext.

كم يمكنني الادخار فعلاً من خلال ترك Vercel؟ يعتمد بشكل كبير على أنماط الاستخدام الخاصة بك. بالنسبة لفريق من 5 مطورين يشغلون تطبيقاً متوسط الحركة، رأيت فرقاً تنتقل من $600-800/شهر على Vercel Pro إلى $30-80/شهر على AWS/SST أو أقل من $20/شهر على VPS. المدخرات حقيقية ولكن العبء الإضافي في الصيانة أيضاً.

هل يمكنني استخدام ISR (Incremental Static Regeneration) بدون Vercel؟ بالمطلق. على AWS/SST، يستخدم ISR DynamoDB لذاكرة التخزين المؤقت للوسوم و SQS لإعادة التحقق غير المتزامنة — فهو يعمل بالكامل بما في ذلك إعادة التحقق عند الطلب عبر revalidateTag() و revalidatePath(). على VPS، يعمل ISR مع ذاكرة التخزين المؤقت على نظام الملفات، وهو جيد للنشرات أحادية الخادم.

ماذا عن معاينات Vercel للنشر؟ هل يمكنني تكرار تلك؟ يمكنك الحصول على 80٪ من التجربة. يدعم SST نشرات قائمة على المرحلة، لذا يمكن لكل PR الحصول على المكدس الخاص به. تقدم أدوات مثل Coolify والأدوات المماثلة نشرات معاينة لإعدادات قائمة على Docker. ما لن تكرره بسهولة هو نظام التعليقات المرئية في Vercel والتكامل الضيق مع GitHub لحالة النشر. معظم الفرق تجد المقايضة مقبولة.

هل يجب أن أستخدم OpenNext مع Cloudflare أو AWS لموقع headless CMS؟ بالنسبة لمواقع headless CMS الثقيلة في المحتوى (Sanity، Contentful، Storyblok)، Cloudflare Workers هو خيار ممتاز. تميل هذه المواقع إلى أن تكون ثقيلة ISR مع منطق خفيف من جانب الخادم — مثالي لنموذج تسعير Cloudflare. لن أذهب إلى AWS إلا إذا كنت بحاجة إلى ميزات لا تدعمها Cloudflare حتى الآن أو إذا كنت بالفعل عميقاً في النظام البيئي AWS.

هل استضافة Next.js بنفسي أصعب من استضافة Astro أو Remix بنفسي؟ بصراحة؟ نعم. Next.js لديها إخراج بناء الأكثر تعقيداً من أي إطار عمل لأن لديها ميزات مثل ISR وMiddleware وتحسين الصور والعرض المسبق الجزئي. Astro و Remix لديهما قصص نشر أبسط بكثير. إذا كنت تبدأ مشروعاً جديداً والاستضافة الذاتية هي الأولوية، فكر في Astro — فهو أبسط بشكل كبير في الاستضافة. لكن إذا كنت بالفعل على Next.js، فإن OpenNext يجعل الترحيل عملياً.

ماذا يحدث إذا توقف OpenNext عن صيانته؟ OpenNext مدعومة من SST ولديها مجتمع نشط مع رعاة رئيسيين. قالت ذلك، هذا قلق شرعي لأي اعتماد مفتوح المصدر. التخفيف هو أن النهج Docker/standalone (next start) يعمل بدون OpenNext على الإطلاق — تفقد فقط بعض الميزات الأكثر تقدماً مثل إعادة التحقق من وسوم ISR و edge middleware. إنها تدهور لطيف، وليس منحدراً.