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

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

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

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

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

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

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

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

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

ما لا يكونه OpenNext

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

مشهد الاستضافة الذاتية في 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 أو Lambda@Edge — تنفيذ الميدلوير

يبدو وكأنه الكثير. هو كذلك. لكن 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-80 ميجابايت اعتماداً على تبعياتك. نطاقات بدايات البرد من 800 ميلي ثانية إلى 3 ثوان.

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

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

OpenNext: استضافة Next.js بنفسك على AWS أو Cloudflare أو VPS بدون Vercel - architecture

هدف النشر: 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 بالتدوير في أقل من 5 ميلي ثانية عالمياً
  • حافة عالمية بشكل افتراضي — يعمل SSR الخاص بك في أكثر من 300 موقع
  • تسعير غير عقلاني — 5 دولارات / شهر لـ 10 مليون طلب في الخطة المدفوعة

العيوب:

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

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

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

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

Dockerfile

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

# المرحلة 1: التبعيات
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

# المرحلة 2: البناء
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

# المرحلة 3: الإنتاج
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 أسهل إعداد، DX مثل Vercel
AWS EC2 t4g.medium 2 vCPU، 4GB RAM ~$25 بالفعل على AWS

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

ما تخسره مع Docker / VPS

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

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

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

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

دعنا نتحدث عن المال. هذا يعتمد على بيانات الفواتير الفعلية من تطبيق Next.js يقوم بـ ~5 مليون طلب / شهر مع 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 كبيرة
  • بدايات باردة على خادم بدون حالة غير مقبولة لحالتك
  • تحتاج إلى استراتيجيات تخزين مؤقت مخصصة لا تناسب نموذج Vercel
  • اصطدمت بحدود حجم الدالة أو حدود وقت التنفيذ في Vercel

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

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

دليل الهجرة

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

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

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

# ابحث عن الميدلوير
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 الثقيل + الميدلوير + تحسين الصور → 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

      # لـ 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 }}

      # لـ Docker/VPS (بديل):
      # - 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 CI الخاص بك
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. راقب معدلات الخطأ و TTFB و Core Web Vitals بعناية فائقة

الخطوة 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 أعلاه مع هذا باستخدام بناء متعدد المراحل مع نفس الصورة الأساسية.

اختلافات سلوك الميدلوير. Vercel يشغل الميدلوير على شبكة الحافة الخاصة بهم. على AWS/SST، يعمل كدالة CloudFront (محدود إلى 10 ميلي ثانية التنفيذ، حجم 2MB). قد يحتاج الميدلوير المعقد إلى نقله إلى دالة الخادم. كان عليّ إعادة هندسة ميدلوير المصادقة بسبب هذه الحدود.

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

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

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

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

هل يدعم OpenNext Next.js App Router ومكونات الخادم؟ دعم كامل. App Router و Server Components و Server Actions و Streaming و 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 والميدلوير وتحسين الصور والعرض الجزئي المسبق. تتمتع Astro و Remix بقصص نشر أبسط بكثير. إذا كانت البدء بمشروع جديد والاستضافة الذاتية ذات أولوية، فكر في Astro — فهو أبسط بشكل كبير في الاستضافة. لكن إذا كنت بالفعل على Next.js، فإن OpenNext يجعل الهجرة عملية.

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