شبکه

امن‌ترین روش ارتباط بین دو سرویس بک‌اند چیه؟ - ارتباط امن بین API ها

یه روز یکی از سرویس‌های داخلیت باید با یه سرویس دیگه حرف بزنه. مثلاً سرویس سفارش باید به سرویس پرداخت بگه «این سفارش رو تسویه کن». اولین راهی که به ذهن خیلی‌ها می‌رسه اینه: یه endpoint باز کن، یه API key هم بذار توش، تمام. مشکل از همینجا شروع میشه، چون «داشتن یه کلید» با «امن بودن ارتباط» فاصله‌ی زیادی داره.

قبل از هر چیز بذار یه چیزی رو روشن کنم: انتخاب پروتکل (REST، GraphQL، gRPC) اصلاً چیزی نیست که امنیت رو تضمین کنه. REST یه انتخاب کاملاً خوبه، ولی خود REST بودن هیچ ربطی به امن بودن نداره. امنیت از جای دیگه‌ای میاد: از اینکه چطور احراز هویت می‌کنی، چطور تصمیم می‌گیری کی به چی دسترسی داره، چطور داده رو رمزنگاری می‌کنی، چطور ورودی‌ها رو validate می‌کنی، و چقدر دو سیستم رو از هم ایزوله نگه می‌داری. این پنج تا با هم امنیت رو می‌سازن، نه انتخاب فرمت پیام.

معماری کلی، قبل از رفتن سراغ جزئیات

یه تصویر کلی از یه معماری معقول این شکلیه: سرویس A از طریق HTTPS به یه API Gateway یا reverse proxy می‌رسه، اونجا احراز هویت، تعیین دسترسی، rate limiting و محدودیت IP اعمال میشه، بعد درخواست به سرویس B واقعی می‌رسه، و در نهایت به دیتابیس. نکته‌ی مهم اینه که هیچ‌کدوم از این لایه‌ها به تنهایی کافی نیستن — این‌ها روی هم دفاع در عمق (defense in depth) رو می‌سازن. هدف طراحی یه سیستم «غیرقابل نفوذ» نیست (چنین چیزی وجود نداره)، هدف اینه که اگه یه لایه شکست خورد، بقیه‌ی سیستم خودکار قربانی نشه.

HTTPS اجباریه، نه اختیاری

این نکته آنقدر بدیهی به نظر می‌رسه که خیلی‌ها ازش رد می‌شن، ولی هنوز هم می‌بینم سرویس‌های داخلی که فقط چون «پشت فایروال هستن» با HTTP ساده کار می‌کنن. فرقی نمی‌کنه ترافیک بین دو تا دیتاسنتر رد بشه یا بین دو تا container توی یه کلاستر — بدون TLS، هر کسی که بین راه بایسته می‌تونه credential ها و داده‌ها رو بخونه. این یعنی همیشه https://api.example.com، هیچ‌وقت http://api.example.com، حتی برای ترافیک کاملاً داخلی.

برای ارتباط سرویس به سرویس، می‌تونی از این هم جلوتر بری و از mutual TLS (mTLS) استفاده کنی. توی TLS معمولی فقط کلاینت مطمئن میشه داره با سرور درست حرف می‌زنه؛ توی mTLS هر دو طرف certificate دارن و همدیگه رو verify می‌کنن. راه‌اندازیش توی Node.js با ماژول https این شکلیه:

const https = require('https');
const fs = require('fs');

const server = https.createServer({
  key: fs.readFileSync('server-key.pem'),
  cert: fs.readFileSync('server-cert.pem'),
  ca: fs.readFileSync('client-ca.pem'),
  requestCert: true,
  rejectUnauthorized: true,
}, (req, res) => {
  res.end('اتصال معتبره');
});

server.listen(443);

نکته‌ی requestCert: true و rejectUnauthorized: true اینجاست که اگه کلاینت certificate معتبر نداشته باشه، اصلاً اجازه‌ی وصل شدن پیدا نمی‌کنه — قبل از اینکه حتی یه خط از کد اپلیکیشنت اجرا بشه. برای API های داخلی حساس، mTLS یکی از قوی‌ترین گزینه‌هاست. مشکلش اینه که مدیریت certificate ها (تمدید، revoke کردن، rotate کردن) خودش یه پروژه‌ی جداست؛ اگه چند تا سرویس داری و مدیریتش برات سخته، ابزارهایی مثل service mesh (Istio، Linkerd) این کار رو خودکار می‌کنن.

از JWT کاربر برای ارتباط سرویس به سرویس استفاده نکن

یه اشتباه رایج اینه که همون JWT ای که برای احراز هویت کاربر نهایی صادر شده رو برای ارتباط بین دو تا سرویس backend هم دوباره‌کاری می‌کنن — یعنی چیزی شبیه Authorization: Bearer <user-jwt> رو بین سرویس‌ها پاس میدن. این کار مرز بین «هویت کاربر» و «هویت سرویس» رو از بین می‌بره و باعث میشه permission های کاربر و سرویس قاطی بشن. به جاش باید یه credential مخصوص machine-to-machine داشته باشی. گزینه‌های خوب اینجا شامل OAuth 2.0 Client Credentials، mTLS، درخواست‌های امضاشده (signed requests)، ترکیب API key و HMAC، و توکن‌های کوتاه‌مدت سرویس‌محور هستن.

برای بیشتر زیرساخت‌های متوسط، ترکیب OAuth 2.0 Client Credentials به‌همراه HTTPS انتخاب معقولیه؛ برای ارتباطات داخلی که واقعاً حساس هستن، mTLS به‌همراه توکن‌های کوتاه‌مدت گزینه‌ی قوی‌تریه.

هر سرویس هویت خودش رو داشته باشه

یه اشتباه دیگه که خیلی رایجه: یه کلید API واحد و master برای همه‌چیز. چیزی شبیه یه متغیر محیطی به اسم MASTER_API_KEY که همه‌ی سرویس‌ها ازش استفاده می‌کنن. مشکل این روش اینه که وقتی یکی از سرویس‌ها compromise بشه، عملاً کل سیستم compromise شده — چون همه از یه کلید استفاده می‌کردن.

راه درست‌تر اینه که هر سرویس یه service account مخصوص خودش داشته باشه، و به هر کدوم فقط همون permission هایی که واقعاً بهش نیاز داره داده بشه. مثلاً اگه سرویس A فقط باید کاربر بسازه و بخونه، نباید اصلاً امکان حذف کاربر یا دسترسی به بخش پرداخت رو داشته باشه:

سرویس A → مجاز به: create_user, read_user, update_access
سرویس A → غیرمجاز به: delete_user, access_payments, access_admin, access_database

به این اصل، least privilege میگن: هر جزء از سیستم فقط دسترسی‌ای رو داشته باشه که برای انجام کارش لازمه، نه بیشتر. این ساده‌ترین و در عین حال مؤثرترین اصلی هست که خیلی از تیم‌ها فراموشش می‌کنن.

احراز هویت با تعیین دسترسی فرق داره

احراز هویت (authentication) به این سؤال جواب میده: «تو کی هستی؟» و تعیین دسترسی (authorization) به این سؤال: «تو اجازه‌ی چه کاری رو داری؟» یه فرض اشتباه رایج اینه که فکر کنیم چون یه request احراز هویت شده، پس قابل اعتماده. این درست نیست. باید هر endpoint جداگانه چک بشه که آیا سرویسی که این درخواست رو فرستاده، مجوز انجام همین عملیات خاص رو داره یا نه. مثلاً POST /users ممکنه نیاز به مجوز user:create داشته باشه، در حالی که DELETE /users/:id ممکنه به یه مجوز کاملاً متفاوت نیاز داشته باشه که خیلی محدودتر بهش داده میشه.

امضای درخواست‌ها با HMAC

برای APIهایی که سطح امنیتی بالاتری می‌خوان، امضای درخواست (request signing) با HMAC یه لایه‌ی اضافه‌ی خیلی خوبیه. ایده اینه که هر دو سرویس یه secret مشترک دارن، و هر request قبل از ارسال با اون secret امضا میشه:

const crypto = require('crypto');

function signRequest(method, path, body, secret) {
  const timestamp = Date.now().toString();
  const payload = method + path + timestamp + JSON.stringify(body);
  const signature = crypto
    .createHmac('sha256', secret)
    .update(payload)
    .digest('hex');
  return { timestamp, signature };
}

این امضا معمولاً توی هدرهایی مثل این ارسال میشه:

X-Client-ID: service-a
X-Timestamp: 1760000000
X-Signature: a3f9c2...

سمت سرور، همین امضا دوباره از روی method، path، timestamp و body محاسبه میشه و با چیزی که تو header اومده مقایسه میشه. اگه یکی وسط راه request رو بگیره و مثلاً ایمیل داخل body رو عوض کنه، امضا دیگه match نمی‌کنه و request رد میشه — بدون اینکه اصلاً لازم باشه محتوای request رمزنگاری بشه؛ همین که تغییرناپذیریش تضمین بشه کافیه.

محافظت در برابر replay attack

فقط امضا کردن request کافی نیست. اگه کسی یه request معتبر و امضاشده رو ضبط کنه و بعداً دوباره همونو بفرسته، امضا هنوز معتبره چون چیزی توش عوض نشده. این همون replay attack هست. راه‌حلش ترکیب سه چیزه: timestamp، یه شناسه‌ی یکتا برای هر request (نان‌س یا request-id)، و امضا:

X-Timestamp: 1760000000
X-Request-ID: 550e8400-e29b-41d4-a716-446655440000
X-Signature: a3f9c2...

منطق سمت سرور این شکلیه: اول چک میشه timestamp توی یه بازه‌ی معقول هست (مثلاً کمتر از پنج دقیقه اختلاف با زمان فعلی سرور)، بعد چک میشه که این request-id قبلاً پردازش نشده (این بخش معمولاً با یه cache سریع مثل Redis پیاده میشه، با یه TTL برابر با همون بازه‌ی زمانی)، و اگه هر دو شرط برقرار بود، امضا verify میشه و در نهایت request-id ذخیره میشه تا دفعه‌ی بعد تکراری تشخیص داده بشه. بدون این مکانیزم، حتی امضای HMAC هم در برابر یه حمله‌ی ساده‌ی «ضبط و پخش دوباره» بی‌دفاعه.

شبکه رو محدود کن، این شاید مهم‌ترین قدمه

اگه سرویس B فقط قراره از طرف سرویس A صدا زده بشه، هیچ دلیلی نداره که اصلاً از اینترنت عمومی در دسترس باشه. این یکی از نکاتی هست که تأثیرش روی امنیت کلی سیستم از خیلی چیزهای دیگه بیشتره، چون هر لایه‌ی امنیتی دیگه‌ای که بذاری (authentication، rate limit، signature) باز هم در معرض حمله قرار می‌گیره اگه شبکه به‌طور عمومی باز باشه.

ابزارهایی که برای این کار به کار میان شامل قوانین فایروال، security group های ابری، شبکه‌ی خصوصی (VPC)، VPN یا WireGuard، IP allowlist، و DNS داخلی هستن. ایده‌آل اینه که ترافیک بین دو سرویس فقط از یه شبکه‌ی خصوصی رد بشه، نه از مسیر عمومی اینترنت که بعد پشت فایروال فیلتر بشه. این دو تا از نظر امنیتی خیلی با هم فرق دارن، حتی اگه نتیجه‌ی نهایی مشابه به نظر برسه.

هیچ‌وقت دسترسی مستقیم دیتابیس نده

یه اشتباه خطرناک که گاهی توی معماری‌های عجله‌ای دیده میشه اینه که یه سرویس بیرونی، مستقیماً credential دیتابیس سرویس دیگه رو داشته باشه. حتی اگه این credential محدود به یه کاربر readonly باشه، این کار لایه‌ی authorization اپلیکیشن رو کاملاً دور می‌زنه. مسیر درست همیشه از طریق API میگذره: سرویس A فقط باید از طریق HTTPS و API عمومی سرویس B باهاش حرف بزنه، و سرویس B خودش تصمیم می‌گیره که این عملیات با توجه به authorization چطور روی دیتابیس اجرا بشه. سرویس A هیچ‌وقت نباید بتونه کاری بیشتر از اونی که API صراحتاً exposed کرده انجام بده.

اعتماد کورکورانه به ورودی، حتی از سرویس داخلی

حتی اگه یه request از یه سرویس authenticated بیاد، بازم باید ورودی‌هاش validate بشن — schema، طول رشته‌ها، فرمت شناسه‌ها، URL ها، اسم فایل‌ها، enum ها، بازه‌ی عددی، و حجم payload. یه نکته‌ی خاص اینجا مربوط به SSRF هست: اگه سرور تو بر اساس یه URL که از سمت کاربر یا سرویس دیگه اومده (مثلاً یه فیلد callback_url) یه request جدید می‌سازه، بدون validate کردن اون آدرس ممکنه یه آسیب‌پذیری SSRF ایجاد بشه که مهاجم بتونه از طریق سرورت به منابع داخلی شبکه دسترسی پیدا کنه که اصلاً نباید بهشون دسترسی داشته باشه.

rate limit فقط برای ترافیک بیرونی نیست

یه سرویس authenticated لزوماً امن نیست. اگه سرویس A به هر دلیلی — یه باگ، یه حلقه‌ی بی‌نهایت، یه retry logic خراب — شروع کنه به بمباران کردن سرویس B، معتبر بودن token یا امضا هیچ کمکی نمی‌کنه. گذاشتن rate limit حتی روی ترافیک کاملاً داخلی، چیزیه که خیلی وقت‌ها دیر بهش فکر می‌کنیم؛ معمولاً بعد از اینکه یه بار یه سرویس داخلی کل کلاستر رو از پا درآورده. منطقی‌ترین کار اینه که برای هر endpoint بر اساس هزینه‌ی محاسباتیش یه سقف جدا تعریف کنی؛ یه request خواندنی ساده و یه عملیات export سنگین طبیعتاً نباید سقف یکسانی داشته باشن.

لاگ کردن، اما نه هر چیزی

وقتی یه چیزی خراب میشه، اولین جایی که سراغش میری لاگ‌هاست. صرفاً لاگ کردن مسیر و متد request (POST /users) کافی نیست؛ چیزهایی که واقعاً کمک‌کننده هستن شامل timestamp، اسم سرویس فرستنده، endpoint، شناسه‌ی یکتای request، نتیجه‌ی عملیات، تصمیم authorization، آدرس IP مبدأ، و latency میشن. نکته‌ی خیلی مهم اینه که هیچ‌وقت secret ها یا credential های حساس رو توی لاگ ننویسی — این خودش یه منبع رایج نشت اطلاعاته که کمتر بهش توجه میشه.

مقایسه‌ی روش‌های ارتباطی

انتخاب پروتکل بین دو سرویس بیشتر به الگوی استفاده بستگی داره تا امنیت، هرچند بعضی گزینه‌ها ذاتاً برای یه سناریوی خاص مناسب‌ترن:

روش	مناسب برای
REST روی HTTPS	APIهای عمومی پلتفرم، انعطاف‌پذیر و پرکاربرد
GraphQL روی HTTPS	کوئری‌های منعطف سمت کلاینت
gRPC با mTLS	ارتباط سرویس‌به‌سرویس داخلی، latency پایین
WebSocket	ارتباط real-time دوطرفه
صف پیام (Message Queue)	عملیات async و پس‌زمینه‌ای
اتصال مستقیم به دیتابیس	باید کاملاً پرهیز بشه
HTTP بدون TLS	هیچ‌وقت

برای ارتباط بین دو پلتفرم مستقل، REST به‌همراه HTTPS و OAuth2 (یا mTLS برای موارد حساس‌تر) یه انتخاب کاملاً محکمه. برای میکروسرویس‌های داخلی که تعداد زیادی درخواست کوچیک و پرتکرار با هم رد و بدل می‌کنن، gRPC یا یه message broker معمولاً منطقی‌تره.

نکته‌ای که در آخر ارزش تکرار کردن داره: هدف طراحی یه API که «هک کردنش غیرممکنه» نیست — چنین چیزی وجود خارجی نداره. هدف اینه که سیستم رو طوری بچینی که compromise شدن یه جزء، خودکار به compromise شدن همه‌چیز منجر نشه. ایزوله کردن شبکه، least privilege، credential های جداگانه برای هر سرویس، محدود کردن دسترسی دیتابیس، و دفاع در عمق، در عمل خیلی بیشتر از انتخاب REST یا GraphQL یا هر پروتکل دیگه‌ای روی امنیت واقعی سیستم تأثیر می‌ذارن.

کِلا پاترول - Claw Patrol: فایروال متن‌باز Deno برای کنترل agent های هوش مصنوعی

دینو‌ (Deno) (همون شرکتی که Ryan Dahl، خالق Node.js، رهبریش می‌کنه) یه ابزار جدید متن‌باز منتشر کرده به اسم Claw Patrol؛ یه فایروال امنیتی که بین agent های هوش مصنوعی و زیرساخت واقعی (دیتابیس، Kubernetes، سرورها) می‌شینه و دقیقاً کنترل می‌کنه که هر agent چه کاری مجازه انجام بده.

داستان از کجا شروع شد

Deno برای سرویس هاستینگش (Deno Deploy)، از agent های مبتنی بر مدل‌هایی مثل Claude Opus برای رسیدگی خودکار به incident های production استفاده می‌کنه؛ agent هایی که به PostgreSQL، Kubernetes، ClickHouse، AWS، گیت‌هاب، و Slack دسترسی write دارن. این agent ها تونستن بخش قابل‌توجهی از incident هایی که قبلاً نیاز به دخالت انسان داشتن رو خودکار حل کنن. ولی همین سطح از دسترسی، یه ریسک فاجعه‌بار هم به همراه داره: اگه یه agent قربانی prompt injection بشه یا رفتار غیرمنتظره‌ای نشون بده، همون دسترسی می‌تونه به فاجعه تبدیل بشه.

طبق صحبت‌های Ryan Dahl تو کنفرانس AI Engineer، فلسفه‌ی پشت Claw Patrol اینه: agent رو باید مثل یه نرم‌افزار کاملاً نامعتمد در نظر گرفت، مهم نیست مدل زیرینش چقدر «همسو» به نظر برسه. راه‌حل‌های موجود (ACL، ابزارهای MCP، LLM gateway، HTTP proxy، credential vault، sandbox کردن پروسه) هر کدوم یه‌جای کار می‌لنگن، مخصوصاً وقتی پای پروتکل‌های غیر-HTTP مثل PostgreSQL یا spawn کردن subprocess وسط بیاد.

چطور کار می‌کنه

Claw Patrol یه gateway است که ترافیک agent رو از طریق تونل WireGuard یا Tailscale می‌گیره، TLS رو terminate می‌کنه، و بعد پروتکل داخلی رو parse می‌کنه؛ نه فقط HTTP، بلکه SQL، Kubernetes API، و SSH هم پشتیبانی می‌شن. برای هر پروتکل، gateway یه سری «fact» سطح-wire استخراج می‌کنه: برای Postgres/ClickHouse، فعل SQL و اسم جدول؛ برای Kubernetes، resource/verb/namespace؛ برای HTTP، method/path/header/body.

این fact ها بعد در برابر قوانینی که با HCL (همون زبون تنظیمات HashiCorp) نوشتی، سنجیده می‌شن:

rule "k8s-no-secrets" {
  endpoint  = k8s-prod
  condition = "k8s.resource == 'secrets'"
  verdict   = "deny"
  reason    = "Secret values must not leave the cluster via the agent"
}

وب اسمبلی (WebAssembly) چیه و چرا این‌قدر سروصدا کرده

اگه اسم WebAssembly (یا به اختصار Wasm) رو شنیدی و کنجکاو شدی دقیقاً چیه، جواب کوتاهش اینه: یه فرمت باینری برای اجرای کد با سرعت نزدیک به native، مستقیم تو مرورگر (و جاهای دیگه). ولی این جواب کوتاه نمی‌گه چرا این تکنولوژی این‌قدر مهمه. برای فهمیدنش بهتره از مشکلی شروع کنیم که Wasm حلش می‌کنه.

مشکلی که جاوااسکریپت نمی‌تونست حلش کنه

جاوااسکریپت تنها زبونیه که مرورگرها به‌صورت native اجرا می‌کنن. برای دهه‌ها، اگه می‌خواستی چیزی تو مرورگر اجرا بشه، مجبور بودی یا مستقیم جاوااسکریپت بنویسی، یا زبون دیگه‌ت رو به جاوااسکریپت compile کنی (مثل TypeScript). مشکل اینجاست که جاوااسکریپت یه زبون dynamically-typed و interpreted هست؛ حتی با موتورهای JIT فوق‌پیشرفته‌ای مثل V8، برای کارهای سنگین محاسباتی (پردازش تصویر، فیزیک بازی، رمزنگاری، پردازش صوت و ویدیو) هنوز به سقف عملکرد زبون‌های کامپایل‌شده مثل C++ یا Rust نمی‌رسه.

WebAssembly این محدودیت رو برمی‌داره. به‌جای این‌که مجبور باشی کد C++ یا Rust ت رو به جاوااسکریپت ترجمه کنی (که هم کند و هم ناقصه)، می‌تونی مستقیم به یه فرمت باینری فشرده و بهینه compile‌ش کنی که مرورگر می‌تونه تقریباً به همون سرعت کد native اجراش کنه.

چند تا ویژگی کلیدی

فرمت باینری، نه متنی: برخلاف جاوااسکریپت که یه متن قابل‌خوندنه، Wasm یه فرمت باینری فشرده‌ست. این یعنی هم فایلش کوچیک‌تره (دانلود سریع‌تر)، هم parse کردنش برای مرورگر سریع‌تره؛ چون نیازی به تحلیل سینتکس متنی نیست.

Sandboxed و امن: کد Wasm دقیقاً مثل جاوااسکریپت، تو یه محیط ایزوله (sandbox) اجرا می‌شه. نمی‌تونه مستقیم به فایل‌سیستم یا شبکه دسترسی پیدا کنه، مگه از طریق API هایی که خود جاوااسکریپت در اختیارش می‌ذاره. یعنی امنیتش مستقل از این‌که کد اصلی با چه زبونی نوشته شده، حفظ می‌شه.

مستقل از زبان مبدأ: Wasm خودش یه زبون برنامه‌نویسی نیست که مستقیم باهاش کد بنویسی (هرچند می‌شه). بیشتر یه target compilation است؛ یعنی زبون‌هایی مثل C، C++، Rust، Go، و حتی بخش‌هایی از پایتون می‌تونن بهش compile بشن.

نزدیک به سرعت native: چون فرمتش از قبل به یه ساختار شبیه assembly نزدیکه (برای همین اسمش Wasm است)، مرورگر نیازی به تفسیر خط‌به‌خط نداره و می‌تونه خیلی سریع‌تر از جاوااسکریپت معمولی اجراش کنه.

Valkey vs Redis: چرا یه fork جدید اومد و کدوم رو باید انتخاب کنی

اگه چند وقتیه دنبال اخبار دنیای دیتابیس‌ها و کش بودی، احتمالاً اسم Valkey رو دیدی و برات سؤال شده چرا یهو یه رقیب جدی برای Redis ظاهر شده، در حالی که تا همین چند سال پیش Redis عملاً بدون رقیب تو حوزه‌ی خودش بود. داستان این fork، بیشتر به یه تغییر لایسنس برمی‌گرده تا یه اختلاف فنی.

چرا Valkey اصلاً به وجود اومد

مارس ۲۰۲۴، شرکت Redis Ltd. اعلام کرد که نسخه‌های بعدی Redis دیگه از لایسنس متن‌باز BSD استفاده نمی‌کنن و به‌جاش زیر لایسنس‌های Source Available (مثل RSALv2 و SSPLv1) منتشر می‌شن. این تغییر یعنی شرکت‌هایی که می‌خواستن Redis رو به‌عنوان یه سرویس ارائه بدن (مثل کلود پرووایدرها)، دیگه اجازه‌ی این کار رو بدون توافق جداگانه با Redis Ltd. نداشتن.

این تصمیم واکنش شدیدی تو کامیونیتی اوپن‌سورس ایجاد کرد. چند روز بعد، لینوکس فاندیشن به همراه چند تا شرکت بزرگ (از جمله AWS، Google Cloud، Oracle، Ericsson و چند تا دیگه) پروژه‌ی Valkey رو راه انداختن؛ یه fork از آخرین نسخه‌ی BSD-licensed Redis (نسخه‌ی ۷.۲.۴) که زیر همون لایسنس متن‌باز BSD قدیمی باقی می‌مونه و توسعه‌اش کاملاً community-driven پیش می‌ره.

از نظر فنی چقدر فرق دارن

نکته‌ی مهم اینه که چون Valkey از یه commit مشخص از Redis فورک شده، تا مدت‌ها تقریباً کد یکسانی داشتن؛ همون دستورات، همون ساختار داده (string، hash، list، set، sorted set)، و همون پروتکل RESP. یعنی اگه یه اپلیکیشن با Redis کار می‌کرد، تغییر به Valkey تو خیلی از موارد فقط با عوض کردن آدرس سرور ممکن بود، بدون تغییر تو کد.

ولی از اون موقع، هر دو پروژه مسیر مستقل خودشون رو رفتن. Valkey ویژگی‌هایی مثل بهبود عملکرد چندنخی (multi-threading بهتر برای بعضی عملیات)، کاهش مصرف حافظه، و چند تا دستور جدید اضافه کرده که مستقیماً از Redis نمیان. از طرف دیگه، Redis Ltd. هم بعداً یه تغییر جهت دیگه داد و اعلام کرد که از نسخه‌ی ۸ به بعد، Redis دوباره زیر یه لایسنس متن‌باز (AGPLv3) منتشر می‌شه؛ هرچند AGPL هم شرایط خاص خودش رو داره و دقیقاً همون آزادی BSD رو نمی‌ده.

چرا این تفاوت لایسنس واقعاً مهمه

برای خیلی از تیم‌ها، این موضوع صرفاً یه بحث حقوقی انتزاعی نیست. لایسنس‌های Source Available که Redis Ltd. تو یه بازه استفاده کرد، محدودیت‌هایی رو برای شرکت‌هایی که می‌خوان از Redis به‌عنوان بخشی از یه سرویس commercial استفاده کنن ایجاد می‌کنه. حتی با برگشت Redis به AGPL، بعضی سازمان‌ها (به‌خصوص اون‌هایی که سیاست‌های سخت‌گیرانه‌ای درباره‌ی لایسنس‌های copyleft قوی دارن) ترجیح می‌دن سراغ چیزی برن که از اول زیر BSD مونده، بدون هیچ تغییر مسیری تو تاریخچه‌ش.

Rate Limiting: چرا هر API باید یک سقف مصرف داشته باشه

فرض کن یک endpoint ساده داری که لیست محصولات رو برمیگردونه. یک روز متوجه میشی سرورت زیر فشار عجیبی رفته، درحالی‌که تعداد کاربر واقعی زیاد نشده. وقتی لاگ‌ها رو نگاه میکنی، میبینی یک IP تنها، چند هزار درخواست در ثانیه فرستاده — یا یک اسکریپت خرابه، یا یک نفر داره عمداً داده‌هات رو میخراشه (scrape میکنه)، یا حتی داره تلاش میکنه با حجم درخواست سرویس رو از کار بندازه. rate limiting دقیقاً همون لایه‌ایه که جلوی این سناریو رو میگیره: تعیین میکنه هر کلاینت (بر اساس IP، کاربر، یا API key) توی یک بازه‌ی زمانی مشخص، حداکثر چند درخواست میتونه بفرسته.

چرا واقعاً مهمه

اولین و واضح‌ترین دلیل، محافظت از منابع سرور در برابر سوءاستفاده یا حملات است. حملات denial-of-service (چه عمدی چه ناشی از یک باگ توی کلاینت که وارد یک حلقه‌ی بی‌نهایت از درخواست شده) میتونن یک سرویس سالم رو در عرض چند ثانیه از پا دربیارن. rate limiting یک سقف مشخص میذاره که جلوی این نوع فشار رو میگیره، قبل از این‌که به لایه‌های عمیق‌تر سیستم (مثل دیتابیس) برسه.

دومی، توزیع عادلانه‌ی منابع بین کاربرهاست. اگه یک API عمومی داری که چند هزار کلاینت مختلف ازش استفاده میکنن، بدون rate limiting هیچ تضمینی نیست که یک کلاینت پرمصرف، کل ظرفیت سرور رو برای بقیه اشغال نکنه. با یک سقف مشخص برای هر کلاینت، مطمئن میشی هیچ‌کس نمیتونه سهم بقیه رو بخوره.

سومی، کنترل هزینه است، مخصوصاً وقتی endpoint پشت سرش یک سرویس گرون‌قیمت باشه — مثلاً یک API که هر درخواستش یک فراخوانی به یک مدل هوش مصنوعی یا یک سرویس ثالث پولی میفرسته. بدون سقف، یک باگ ساده توی کد کلاینت (مثلاً یک حلقه‌ی retry بی‌پایان) میتونه صورت‌حساب رو در عرض چند ساعت نجومی کنه.

چهارمی، جلوگیری از brute-force. روی endpoint هایی مثل لاگین، rate limiting جلوی این رو میگیره که یک مهاجم بتونه با امتحان‌کردن هزاران رمز عبور در ثانیه، حساب کاربری رو بشکنه.

الگوریتم‌های رایج rate limiting

چند روش استاندارد برای پیاده‌سازی rate limiting وجود داره، و هرکدوم trade-off متفاوتی دارن.

Fixed Window

ساده‌ترین روش: یک بازه‌ی زمانی ثابت (مثلاً هر دقیقه) در نظر میگیری و میشماری چند درخواست توش اومده. اگه از سقف رد بشه، بقیه رد میشن تا شروع بازه‌ی بعدی.

Cache: کش چیه؟ چرا کش کنیم؟ یک لایه با سرعت بسیار بیشتر

فرض کن یک صفحه داری که برای ساختنش باید بری سراغ دیتابیس، چند تا جدول رو join کنی، نتیجه رو پردازش کنی، و بعد HTML بسازی. این کار شاید ۲۰۰ میلی‌ثانیه طول بکشه. حالا اگه این صفحه رو هزار نفر در ثانیه ببینن، و محتواش هر بار عوض نشه، داری همون کار سنگین رو هزار بار در ثانیه تکرار میکنی، درحالی‌که جواب همیشه یکیه. کش دقیقاً همین اتلاف رو حل میکنه: جواب رو یک بار حساب میکنی، جایی نگهش میداری که دسترسی بهش خیلی سریع‌تره، و دفعه‌های بعد به‌جای محاسبه‌ی دوباره، همون جواب آماده رو برمیگردونی.

این ایده به‌قدری پایه‌ایه که توی تقریباً هر لایه‌ای از یک سیستم، از مرورگر گرفته تا CDN تا سرور تا دیتابیس، یک نسخه‌ی متفاوت از همین ترفند رو میبینی.

کش توی مرورگر و سمت کاربر

اولین لایه‌ای که هر کاربر باهاش برخورد میکنه، کش مرورگره. وقتی یک فایل CSS یا تصویر یا فونت رو دانلود میکنی، مرورگر بر اساس هدرهای HTTP مثل Cache-Control و ETag تصمیم میگیره که آیا لازمه دوباره از سرور بگیرتش یا همون نسخه‌ی محلی رو نشون بده. برای همین دفعه‌ی دوم که یک سایت رو باز میکنی، خیلی سریع‌تر لود میشه — چون مرورگر اصلاً درخواست جدیدی نمیفرسته، یا اگه بفرسته، سرور فقط میگه «چیزی عوض نشده» (کد وضعیت ۳۰۴) و دوباره کل فایل رو نمیفرسته.

کش توی CDN

لایه‌ی بعدی که خیلی وقت‌ها دیده نمیشه، CDN است — سرویس‌هایی مثل Cloudflare یا ArvanCloud که یک نسخه از فایل‌های استاتیک سایتت (تصویر، CSS، JS، و حتی گاهی HTML) رو روی سرورهای پخش‌شده در نقاط مختلف جغرافیایی نگه میدارن. وقتی کاربری از یک شهر دیگه به سایتت وصل میشه، به‌جای این‌که درخواستش تا سرور اصلی بره، نزدیک‌ترین edge server جواب رو از کشش برمیگردونه. این هم سرعت رو بالا میبره و هم فشار روی سرور اصلی رو کم میکنه.

کش سمت سرور (Application Cache)

توی خود اپلیکیشن، معمولاً از ابزارهایی مثل Redis یا Memcached استفاده میشه تا نتیجه‌ی محاسبات سنگین یا کوئری‌های تکراری رو نگه دارن. مثلاً اگه یک API داری که لیست محصولات پرفروش رو برمیگردونه، به‌جای این‌که هر بار این لیست رو از دیتابیس محاسبه کنی، یک بار حسابش میکنی و توی Redis با یک TTL (زمان انقضا) ذخیره‌اش میکنی:

لود بالانسر: از یک سرور تنها تا چیزی که هیچ‌وقت down نمیشه

اکثر پروژه‌ها همین‌طور شروع میشن: یک سرور ساده روی یک VPS معمولی، کاربر کم، همه‌چیز روبه‌راه. مشکل معمولاً از جایی شروع میشه که یک اتفاق باعث میشه ترافیک چند برابر بشه — یک پست وایرال، یک کمپین تبلیغاتی، یا فقط رشد طبیعی کاربر — و همون یک سرور شروع میکنه به کند شدن و timeout دادن. راه‌حلی که خیلی‌ها اول امتحان میکنن اضافه‌کردن منابع به همون سرور است: رم بیشتر، CPU بیشتر. این کار یک‌مدت جواب میده، ولی زیاد طول نمیکشه که همون مشکل دوباره برگرده. نکته اینه که این مسیر یک سقف داره، و لود بالانسر دقیقاً همون‌جایی وارد میشه که این سقف رو کنار میزنه: به‌جای یک سرور بزرگ‌تر، چند سرور کوچک‌تر که ترافیک بینشون تقسیم بشه.

قبل از لود بالانسر: مقیاس عمودی

قبل از این‌که مفهوم load balancing جا بیفته، راه‌حل رایج برای مقابله با ترافیک بالا چیزی بود به اسم مقیاس عمودی یا vertical scaling: سرور موجود رو قوی‌تر میکردی. رم بیشتر، هسته‌ی پردازشی بیشتر، دیسک سریع‌تر. این روش یک مشکل بزرگ داره: یک سقف فیزیکی وجود داره. حتی اگه پول بی‌نهایت هم داشته باشی، یک سرور فیزیکی یا مجازی یک جایی به حداکثر ظرفیتش میرسه. علاوه بر این، این مدل یک نقطه‌ی شکست واحد داره؛ اگه همون یک سرور بخوابه، کل سرویس از دسترس خارج میشه.

بعد از لود بالانسر: مقیاس افقی

لود بالانسر اومد تا یک مسیر جایگزین باز کنه: مقیاس افقی یا horizontal scaling. به‌جای یک سرور قوی، چند سرور معمولی رو کنار هم میذاری و یک لایه‌ی جلویی به اسم load balancer درخواست‌های ورودی رو بینشون پخش میکنه. کاربر اصلاً نمیفهمه پشت صحنه چند سرور داره کار میکنه؛ فقط یک آدرس یا دامنه میبینه.

نتیجه‌ی این تغییر دو چیزه: اول، دیگه سقف فیزیکی وجود نداره — هر وقت ترافیک بالا رفت، یک سرور دیگه اضافه میکنی. دوم، دیگه نقطه‌ی شکست واحد نداری؛ اگه یکی از سرورها بخوابه، لود بالانسر خودش میفهمه و ترافیک رو به بقیه‌ی سرورها هدایت میکنه، بدون این‌که کاربر چیزی متوجه بشه.

لایه‌ی ۴ در مقابل لایه‌ی ۷

لود بالانسرها معمولاً روی دو سطح کار میکنن. لود بالانسر لایه‌ی ۴ (L4) روی سطح transport کار میکنه، یعنی فقط IP و پورت رو میبینه و بدون این‌که وارد محتوای درخواست بشه، ترافیک رو پخش میکنه. سریع‌تره چون کار کمتری انجام میده، ولی هوشمندی کمتری داره.

لود بالانسر لایه‌ی ۷ (L7) روی سطح application کار میکنه، یعنی میتونه محتوای درخواست HTTP رو ببینه — مسیر URL، هدرها، کوکی‌ها — و بر همون اساس تصمیم بگیره کدوم سرور جواب بده. مثلاً میتونی بگی درخواست‌هایی که مسیرشون با شروع میشه برن سراغ یک گروه از سرورها، و درخواست‌های برن سراغ یک گروه دیگه. این انعطاف هزینه داره: کمی کندتر از L4 است چون باید محتوای درخواست رو parse کنه.

شبکه توزیع محتوا (CDN) چیست؟ میتونم سرعت سایتم رو افزایش بدم؟

تا به حال دقت کرده‌اید چرا سایت‌هایی مثل نتفلیکس، یوتیوب یا حتی گوگل، از هر نقطه‌ای از دنیا با سرعتی نزدیک به هم بارگذاری می‌شوند؟ راز این سرعت، در یک سرور قدرتمند در یک گوشه دنیا پنهان نشده است. راز آن در هزاران سرور کوچک است که در سراسر جهان پخش شده‌اند و منتظرند تا محتوای مورد نیاز شما را از نزدیک‌ترین نقطه ممکن تحویل دهند.

این شبکه عظیم و هوشمند، CDN یا Content Delivery Network نام دارد. اگر صاحب یک سایت هستید، توسعه‌دهنده‌اید یا حتی فقط کنجکاوید بدانید اینترنت چگونه این‌قدر سریع کار می‌کند، این مقاله برای شما نوشته شده است. در ادامه، CDN را از پایه تا جزئیات فنی بررسی می‌کنیم.

CDN چیست؟ تعریف ساده و کاربردی

CDN مخفف عبارت Content Delivery Network به معنی «شبکه توزیع محتوا» است. به زبان ساده، CDN مجموعه‌ای از سرورهای پراکنده در نقاط مختلف جغرافیایی است که نسخه‌ای کش شده از محتوای یک سایت را در خود نگه می‌دارند.

وقتی کاربری از تهران سایت شما را باز می‌کند، به جای اینکه درخواستش به سرور اصلی سایت در آلمان برود، از نزدیک‌ترین سرور CDN (مثلاً سرور ابری در تهران یا استانبول) پاسخ می‌گیرد. این یعنی فاصله کمتر، تاخیر کمتر و سرعت بسیار بالاتر.

چرا به CDN نیاز داریم؟

برای درک اهمیت CDN، ابتدا باید با یک مفهوم کلیدی به نام Latency یا «تاخیر شبکه» آشنا شویم. وقتی کاربری در Sydney استرالیا می‌خواهد به سایتی دسترسی پیدا کند که سرور اصلی آن در نیویورک قرار دارد، داده‌ها باید هزاران کیلومتر را در کابل‌های زیردریایی طی کنند. این رفت و برگشت حتی با سرعت نور هم چند صد میلی‌ثانیه طول می‌کشد.

سیستم DNS چیست؟ راهنمای جامع و ساده از دفترچه تلفن اینترنت

تا به حال فکر کرده‌اید وقتی آدرسی مثل google.com را در مرورگر تایپ می‌کنید، دقیقاً چه اتفاقی در کسری از ثانیه رخ می‌دهد؟ کامپیوتر شما برای برقراری ارتباط با سرور گوگل، به یک آدرس عددی و طولانی به نام IP نیاز دارد. اما ما انسان‌ها حفظ کردن این اعداد را بلد نیستیم. اینجاست که یکی از شاهکارهای مهندسی اینترنت وارد عمل می‌شود.

سیستم DNS یا همان Domain Name System، نامرئی‌ترین اما حیاتی‌ترین بخش وب است. بدون آن، اینترنتی که امروز می‌شناسیم وجود نداشت. در این مقاله، می‌خواهیم این تکنولوژی را از ریشه بررسی کنیم. می‌بینیم قبل از DNS اوضاع چگونه بود، خود DNS چیست و چگونه کار می‌کند، و در نهایت بعد از پیدا شدن آدرس، چه مراحلی طی می‌شود.

قبل از DNS: دنیایی که در آن گم شده بودیم

برای درک بهتر اهمیت DNS، باید به روزهای اولیه اینترنت و شبکه ARPANET برگردیم. در آن زمان، برای پیدا کردن یک کامپیوتر در شبکه، باید آدرس IP آن را حفظ می‌کردید.

وقتی تعداد کامپیوترها کم بود، این کار شدنی بود. اما با بزرگ‌تر شدن شبکه، نیاز به یک راه حل احساس شد. راه حل اولیه فایلی به نام HOSTS.TXT بود. این فایل یک لیست متنی ساده بود که نام کامپیوترها و آدرس IP آن‌ها را در خود داشت. هر روز، یک سرور مرکزی این فایل را آپدیت می‌کرد و همه شبکه‌ها باید آن را دانلود می‌کردند.

این روش خیلی زود به بن‌بست خورد. با رشد نمایی اینترنت، حجم این فایل آنقدر زیاد شد که دانلود آن ساعت‌ها طول می‌کشید. همچنین ترافیک شبکه به شدت بالا رفت و ناهماهنگی در نسخه‌های مختلف فایل باعث شد کاربران به آدرس‌های اشتباه هدایت شوند. اینترنت به یک سیستم مقیاس‌پذیر و هوشمند نیاز داشت.

تصویر شاخص پراکسی چیست و چطور با Nginx یک سرور پروداکشن واقعی بسازیم؟

در این مقاله با مفهوم ریورس پراکسی آشنا می‌شوید، یاد می‌گیرید چرا هر سرور پروداکشنی به آن نیاز دارد، و قدم‌به‌قدم یک تنظیم واقعی با Nginx پیاده‌سازی می‌کنیم.

یک سوال ساده برای شروع

فرض کنید یک اپلیکیشن Node.js نوشته‌اید که روی پورت 3000 اجرا می‌شود. وقتی می‌خواهید آن را روی سرور منتشر کنید، چند سوال ذهنتان را درگیر می‌کند:

کاربر که example.com می‌زند، چطور به پورت 3000 می‌رسد؟
اگر چند سرویس مختلف داشتم، چطور مدیریتشان کنم؟
SSL چطور تنظیم می‌شود؟
اگر ترافیک زیاد شد، بار را چطور تقسیم کنم؟

جواب همه این سوال‌ها یک چیز است: ریورس پراکسی.

ریورس پراکسی دقیقاً چیست؟

قبل از اینکه وارد Nginx شویم، باید مفهوم پراکسی را درست بفهمیم.

فرق پراکسی معمولی با ریورس پراکسی

پراکسی معمولی (Forward Proxy): جلوی کلاینت می‌نشیند. یعنی درخواست‌های کاربر را می‌گیرد و به اینترنت می‌فرستد. سرور مقصد نمی‌داند درخواست از کجا آمده. در شبکه‌های سازمانی یا VPNها از این نوع استفاده می‌شود.
ریورس پراکسی (Reverse Proxy): جلوی سرور می‌نشیند. یعنی کلاینت فکر می‌کند دارد مستقیم با سرور اصلی صحبت می‌کند، اما در واقع با ریورس پراکسی در ارتباط است. ریورس پراکسی درخواست را می‌گیرد، پردازش می‌کند و به سرور مناسب می‌فرستد.

یک تصویر ذهنی ساده: ریورس پراکسی مثل نگهبان یا منشی جلوی یک ساختمان بزرگ است. هر کسی که می‌آید، او راهنمایی می‌کند به کدام اتاق برود.

Portainer چیست؟ مدیریت Docker بدون سردرد ترمینال

اگر با Docker کار کرده باشی، احتمالاً صدها بار این دستورات را تایپ کرده‌ای:

docker ps
docker logs my-container
docker restart my-container
docker compose up -d

این دستورات قدرتمندند، اما وقتی تعداد کانتینرها زیاد می‌شود یا می‌خواهی چند سرویس را همزمان چک کنی، ترمینال به‌تنهایی کمی طاقت‌فرسا می‌شود.

اینجاست که Portainer وارد می‌شود.

Portainer دقیقاً چیست؟

Portainer یک پنل مدیریتی تحت وب برای Docker است که همه کارهای رایج را در یک داشبورد گرافیکی ساده قرار می‌دهد. به‌جای اینکه برای هر کار SSH بزنی و دستور تایپ کنی، از مرورگرت وارد می‌شوی و همه‌چیز را یکجا می‌بینی.

علاوه بر Docker، از Kubernetes، Docker Swarm و Podman هم پشتیبانی می‌کند.

جالب اینجاست که خودِ Portainer هم به‌صورت یک Docker Container اجرا می‌شود.

با Portainer چه کارهایی می‌توانی انجام دهی؟

جیسون یا جیسان چیست - JSON - JavaScript Object Notation

جی‌سان یا JSON (JavaScript Object Notation) یک فرمت تبادل داده سبک (lightweight) می‌باشد که خواندن و نوشتن آن برای انسان و تولید و پارس کردن آن برای ماشین‌ها آسان است.

این زبان بر مبنای یک زیرمجموعه از زبان برنامه‌نویسی JavaScript، استاندارد ECMA-262 ویرایش سوم - دسامبر 1999، است.

JSON به صورت متنی (text) بوده و کاملاً مستقل از زبان به‌کار رفته است، اما از قوانینی استفاده می‌کند که برای برنامه‌نویسان زبان‌های خانواده C (شامل C، C++، Java، JavaScript، Perl، Python، و بسیاری زبان‌های دیگر) آشنا می‌باشد. این خصوصیات JSON را یک زبان تبادل‌داده‌ای ایده‌آل کرده است.

چرا JSON؟

ویژگی‌های JSON آن را به یک فرمت تبادل داده ایده‌آل تبدیل می‌کنند:

متن‌باز و سبک: صدور و مصرف آن کم‌حجم است و لزوماً به کتابخانه‌های سنگین نیاز ندارد.
قابل خواندن توسط انسان: نگارش آن ساده و نزدیک به ساختارهای برنامه‌نویسی معمول است.
قابل پارس شدن توسط ماشین: انواع داده‌ای ساده و قواعد مشخصی دارد که پیاده‌سازی parser را آسان می‌کند.
مستقل از زبان: پشتیبانی توسط زبان‌های متعددی دارد و انتقال داده بین محیط‌های گوناگون را آسان می‌سازد.

ساختارها و نوع‌های داده در JSON

JSON بر مبنای دو ساختار داده‌ای اصلی ساخته شده است:

یک مجموعه از زوج‌های نام/ارزش (name/value). در زبان‌های گوناگون این ساختار یک شیء (object)، ساختار (struct)، دیکشنری (dictionary)، جدول مخلوط (hash table)، لیست کلیددار (keyed list) یا آرایه انجمنی (associative array) شناخته می‌شود.
یک لیست منظم از ارزش‌ها. در بسیاری از زبان‌ها این ساختار یک آرایه (array)، بردار (vector)، لیست (list)، یا دنباله (sequence) شناخته می‌شود.

در JSON از فرم‌های زیر استفاده می‌شود:

۱. شیء (object)

یک مجموعه نامنظم از زوج‌های نام/ارزش که با { } در برگرفته شده‌اند. در انتهای هر نام یک : (دو نقطه) قرار می‌گیرد و زوج‌های نام/ارزش با , (ویرگول) جدا می‌شوند.

# /etc/nginx/sites-available/startup.com # Upstream تعریف‌ها upstream api_backend { server localhost:3000; server localhost:3001 backup; keepalive 16; } upstream upload_service { server localhost:4000; } # Redirect HTTP به HTTPS server { listen 80; server_name startup.com www.startup.com; return 301 https://$host$request_uri; } # سرور اصلی HTTPS server { listen 443 ssl http2; server_name startup.com www.startup.com; # SSL ssl_certificate /etc/letsencrypt/live/startup.com/fullchain.pem; ssl_certificate_key /etc/letsencrypt/live/startup.com/privkey.pem; ssl_protocols TLSv1.2 TLSv1.3; ssl_prefer_server_ciphers off; ssl_session_cache shared:SSL:10m; # لاگ‌ها access_log /var/log/nginx/startup_access.log; error_log /var/log/nginx/startup_error.log warn; # فایل‌های استاتیک React root /var/www/startup/build; index index.html; location / { try_files $uri $uri/ /index.html; expires 1h; add_header Cache-Control "public"; } # فایل‌های استاتیک با cache طولانی location ~* \.(js|css|png|jpg|jpeg|gif|ico|svg|woff2)$ { expires 1y; add_header Cache-Control "public, immutable"; } # API location /api/ { limit_req zone=api burst=30 nodelay; proxy_pass http://api_backend/; proxy_http_version 1.1; proxy_set_header Connection ""; proxy_set_header Host $host; proxy_set_header X-Real-IP $remote_addr; proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for; proxy_set_header X-Forwarded-Proto $scheme; # Timeout مناسب برای API proxy_connect_timeout 5s; proxy_read_timeout 60s; proxy_send_timeout 60s; } # آپلود فایل (timeout بیشتر) location /upload/ { client_max_body_size 50M; proxy_read_timeout 300s; proxy_pass http://upload_service/; proxy_set_header Host $host; proxy_set_header X-Real-IP $remote_addr; proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for; proxy_set_header X-Forwarded-Proto $scheme; } # WebSocket location /ws/ { proxy_pass http://api_backend/ws/; proxy_http_version 1.1; proxy_set_header Upgrade $http_upgrade; proxy_set_header Connection "upgrade"; proxy_set_header Host $host; proxy_read_timeout 86400s; } }

نسخه	هزینه	مناسب برای
Community Edition (CE)	رایگان	توسعه‌دهندگان، VPS، پروژه‌های شخصی
Business Edition (BE)	رایگان تا ۳ Node، بعد پولی	تیم‌ها و شرکت‌ها با نیاز به RBAC، SSO، GitOps