پلتفرم به‌عنوان سرویس · Platform as a Service

پلتفرم ابری (PaaS) از کد تا اجرای برنامه

پلتفرم ابری آراد، محیطی برای استقرار اپلیکیشن، اجرای Docker و راه‌اندازی سرویس‌های وابسته است که در آن مسیر انتشار برنامه، منابع پردازشی و تنظیمات اجرا را کنار هم انتخاب می‌کنید تا زیرساخت PaaS با نیاز محصول شما هماهنگ شود

مشاهده سرویس‌های PaaS
DEPLOYMENT PIPELINEاز کد تا اجرای اپلیکیشن
آماده استقرار
app.aradcloud.app

PaaS چیست؟

از Commit تا اجرای اپلیکیشن؛ بدون مدیریت روزمره سرور

PaaS یا Platform as a Serviceلایه‌ای آماده میان کد و زیرساخت ابری است؛ تیم شما کد، وابستگی‌ها و تنظیمات اپلیکیشن را تعریف می‌کند و پلتفرم، مسیر Build، Runtime، Release و اجرای سرویس را در یک جریان مشخص قرار می‌دهد.

01
محیط اجرا آماده می‌شودRuntime، Build و فرمان اجرای پروژه در یک مسیر مشخص تعریف می‌شوند.
02
انتشار قابل پیگیری می‌شودوضعیت Build، Release فعال و مسیر بازگشت نسخه برای تیم روشن‌تر است.
03
عملیات روزمره کمتر می‌شودتیم به‌جای نگه‌داری مستقیم سیستم‌عامل، روی کد، داده و رشد محصول تمرکز می‌کند.
OPERATING MODEL

چه کسی چه چیزی را مدیریت می‌کند؟

Code → Build → Run
تیم شما
کد و منطق محصولRepository، وابستگی‌ها و فرمان اجرا
داده و تنظیمات کسب‌وکارSchema، Config و سیاست نگه‌داری
مسئولیت مشترک
امنیت اپلیکیشنSecrets، سطح دسترسی و به‌روزرسانی کد
پایداری سرویسHealth Check، ظرفیت و برنامه بازیابی
لایه پلتفرم
Build و Runtimeآماده‌سازی محیط و اجرای Release
زیرساخت پایهسیستم‌عامل، شبکه و منابع پردازشی
مرز مسئولیت‌ها را قبل از خرید با پلن تطبیق دهیدچک‌لیست Production ←
روش‌های استقرار PaaS

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

از استقرار مستقیم کد و Docker تا سرویس‌های داده و ابزارهای آماده؛ مسیر اجرا را براساس معماری پروژه انتخاب کنید. گزینه‌های فعال پنل، مرجع نهایی دسترس‌پذیری هستند.

</>
Runtime & Framework

استقرار مستقیم کد

برای اپلیکیشن‌های Backend، Frontend و API که مستقیماً از Repository یا فایل پروژه Build و منتشر می‌شوند.

Node.jsPythonPHPGoJava.NETStatic
Container

استقرار Docker

برای پروژه‌هایی که Runtime، وابستگی‌ها و فرمان اجرای اختصاصی خود را داخل Image تعریف می‌کنند.

  • ورودی Docker Image یا Dockerfile
  • تنظیم Environment Variable و فرمان اجرا
  • مناسب سرویس‌های سفارشی و قابل‌تکرار
Data Services

دیتابیس و سرویس‌های داده

پایگاه داده، Cache، Queue و Search را متناسب با الگوی خواندن، نوشتن و مقیاس اپلیکیشن کنار سرویس اصلی قرار دهید.

SQLNoSQLCacheQueueSearch
One-click & Tools

برنامه‌های آماده و ابزارها

برای ابزارهای تیمی، مدیریت محتوا، مشاهده‌پذیری و سرویس‌های مکمل که با تنظیمات اولیه مشخص و مسیر راه‌اندازی کوتاه‌تر شروع می‌شوند.

CMSCI/CDMonitoringStorageRegistry
پلتفرم‌هایی که ارائه می‌دهیم

پروژه‌تان را با Runtime و Framework مناسب مستقر کنید

از Backend و API تا Frontend، SSR و Container؛ فناوری پروژه را انتخاب کنید و نسخه، منابع و فرمان اجرای آن را پیش از سفارش با گزینه‌های فعال پنل تطبیق دهید.

نکته فنی: نمایش هر فناوری به معنی تأیید همه نسخه‌ها یا Add-onها نیست؛ نسخه Runtime، Build Command، Start Command، Storage و سرویس‌های داده را هنگام سفارش بررسی کنید.

راهنمای انتخاب پلتفرم
از ایده تا اجرا

استقرار اپلیکیشن در چهار تصمیم روشن

پیش از خرید، روش ورود کد، محیط اجرا، منابع و وابستگی‌های پروژه را مشخص کنید.

۱

روش استقرار

Git، فایل پروژه، Docker Image یا برنامه آماده را انتخاب کنید.

۲

محیط اجرا

Runtime، نسخه و فرمان Build/Start را مطابق پروژه تعیین کنید.

۳

منابع و داده

CPU، RAM، Storage و سرویس‌های داده موردنیاز را برآورد کنید.

۴

دامنه و انتشار

دامنه، متغیرهای محیطی و سیاست انتشار نسخه را تکمیل کنید.

راهنمای انتخاب منابع
چک‌لیست فنی خرید
۸معیار فنی پیش از خرید

PaaS آماده Production را با هشت معیار ارزیابی کنید

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

01

Build و Deploy قابل مشاهده

منبع کد، خروجی Build، وضعیت Release و نسخه فعال باید در یک مسیر روشن دیده شوند.

  • اتصال Repository
  • Build Log
  • Release History
02

Rollback و کنترل نسخه

در صورت خطا، مسیر بازگشت به Release پایدار باید سریع و قابل پیش‌بینی باشد.

نسخه قبلی تا چه مدت نگه‌داری می‌شود؟
03

منابع و مقیاس

CPU و RAM باید با الگوی بار پروژه هماهنگ شوند؛ شیوه Scale و زمان اعمال تغییرات را بررسی کنید.

CPU · RAM · Instance
04

Logs و Monitoring

لاگ اجرای اپلیکیشن، مصرف منابع و Health Check برای تشخیص سریع خطا ضروری‌اند.

Runtime Log · Metric · Alert
05

دامنه، Route و SSL

اتصال دامنه، مسیر ترافیک و تمدید گواهی را پیش از انتقال Production شفاف کنید.

Domain · HTTPS · Redirect
06

Config و Secrets

تنظیمات محیطی و اطلاعات حساس باید از کد جدا باشند و با کنترل دسترسی مدیریت شوند.

ENV · Secret · Access
07

داده و Storage پایدار

اتصال دیتابیس، Cache، Queue و فضای پایدار را با الگوی خواندن و نوشتن پروژه تطبیق دهید.

Database · Cache · Volume
08

تیم، محیط و دسترسی

Development، Staging و Production باید نقش‌ها و سطح دسترسی مشخص داشته باشند.

Role · Environment · Audit
تجربه توسعه‌دهنده

وضعیت Release را بدون جست‌وجو میان چند ابزار دنبال کنید

یک مسیر مدیریتی خوب باید Build، نسخه فعال، سلامت سرویس، مصرف منابع و رویدادهای مهم را قابل مشاهده کند؛ تا تیم فنی سریع‌تر علت خطا یا نیاز به ظرفیت بیشتر را پیدا کند.

  • نمایش مرحله Build و تاریخچه Release
  • دسترسی به Logهای اجرا و رخدادها
  • تفکیک تنظیمات محیط‌های مختلف
  • نمایش منابع و وابستگی‌های سرویس
PROJECT / PRODUCTIONapi-serviceنمای یکپارچه استقرار و سلامت اپلیکیشن
Release فعال
VERSIONv2.4.1نسخه فعال
BUILDPassedخروجی موفق
ROUTEHTTPSدامنه متصل
runtime logs
14:22:08 release v2.4.1 started
14:22:19 health check passed
14:22:20 traffic switched successfully
● service is ready
تصمیم‌گیری با داده‌های اجرادرخواست دموی پنل
تعرفه‌ها و پیکربندی‌های بررسی‌شده در صفحه قیمت‌گذاری این محصول آمده‌اند. مشاهده قیمت و محاسبه هزینه ←
قیمت سرویس PaaS

پلن مناسب را با منابع موردنیاز پروژه مقایسه کنید

برای مشاهده شکل نهایی جدول، قیمت و منابع زیر با داده‌های آزمایشی تکمیل شده‌اند؛ این اعداد تعرفه رسمی آرادکلود نیستند.

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

آغاز

شروع اقتصادی

پایه

پروژه کم‌مصرف

توسعه

محیط توسعه فعال

رشد

Production آماده رشد

حرفه‌ای

بار کاری پایدار

مقیاس

منابع پرترافیک

سازمانی

معماری چندسرویسی
قیمت ماهانه—در انتظار تکمیل تعرفه—در انتظار تکمیل تعرفه—در انتظار تکمیل تعرفه—در انتظار تکمیل تعرفه—در انتظار تکمیل تعرفه—در انتظار تکمیل تعرفه—در انتظار تکمیل تعرفه
قیمت ساعتی—در انتظار تکمیل تعرفه—در انتظار تکمیل تعرفه—در انتظار تکمیل تعرفه—در انتظار تکمیل تعرفه—در انتظار تکمیل تعرفه—در انتظار تکمیل تعرفه—در انتظار تکمیل تعرفه
RAM (GB)1 GB2 GB4 GB8 GB16 GB32 GB64 GB
vCPU (CORE)0.5 Core1 Core2 Core4 Core8 Core16 Core32 Core
Disk (GB SSD)10 GB20 GB40 GB80 GB160 GB320 GB640 GB
موارد استفاده

PaaS برای کدام پروژه‌ها انتخاب بهتری است؟

وقتی سرعت انتشار و تمرکز تیم روی محصول از مدیریت مستقیم سیستم‌عامل و وب‌سرور مهم‌تر است.

API / SERVICE↙

Backend، API و Microservice

برای سرویس‌هایی که مستقل منتشر می‌شوند، متغیرهای محیطی مشخص دارند و به دیتابیس، Cache یا Queue متصل‌اند.

  • REST یا GraphQL API
  • سرویس‌های مستقل
  • Worker کنار سرویس اصلی
GitBuildAPI
WEB / SSR

وب‌اپلیکیشن و Frontend

برای React، Vue، Next.js و Nuxt.js؛ از خروجی Static تا SSR و Full-stack.

ReactNext.jsVue
MVP

محصول اولیه و آزمایش بازار

برای تیمی که می‌خواهد زمان آماده‌سازی زیرساخت را کم و نسخه اولیه را سریع‌تر منتشر کند.

تمرکز بیشتر روی توسعه
WORKER / JOB

پردازش پس‌زمینه

اجرای Queue Worker، کارهای زمان‌بندی‌شده و پردازش‌هایی که نباید درخواست کاربر را متوقف کنند.

PRODUCT TEAM

تیم‌های محصول و نرم‌افزار

برای ساخت یک مسیر تکرارپذیر میان Development، Staging و Production با نقش‌ها و Releaseهای روشن.

DEV→STAGE→PROD
انتخاب مطمئن‌تر پیش از خرید

معماری PaaS پروژه‌تان را با نیاز واقعی تطبیق دهید

نوع اپلیکیشن، Runtime یا Docker، منابع، دیتابیس، دامنه و الزامات Production را مرور کنید تا مسیر سفارش دقیق‌تر شود.

مشاهده پنل آراد
سرویس PaaS چیست؟

PaaS یا Platform as a Service محیطی آماده برای ساخت، استقرار و اجرای اپلیکیشن است. در این مدل، تیم توسعه به‌جای مدیریت روزمره سیستم‌عامل و زیرساخت پایه، بیشتر روی کد و محصول تمرکز می‌کند.

تفاوت PaaS با VPS چیست؟

در VPS کنترل بیشتری روی سیستم‌عامل دارید، اما نگه‌داری آن هم با شماست. PaaS بخشی از عملیات زیرساخت و فرایند استقرار را مدیریت می‌کند و در مقابل، سطح کنترل مستقیم کمتر می‌شود.

برای خرید PaaS چه اطلاعاتی آماده کنیم؟

نوع پروژه، روش استقرار، Runtime یا Docker، منابع تقریبی، دامنه، دیتابیس و سرویس‌های جانبی، تعداد محیط‌ها و الزامات پشتیبانی را مشخص کنید.

چه Runtime و نسخه‌هایی فعال است؟

فهرست Runtimeها و نسخه‌ها می‌تواند تغییر کند. گزینه‌های فعال پنل در زمان سفارش مرجع نهایی است؛ برای مهاجرت پروژه موجود، نسخه دقیق را پیش از خرید تطبیق دهید.

قیمت PaaS چگونه محاسبه می‌شود؟

هزینه معمولاً به CPU، RAM، Storage، ترافیک، تعداد سرویس‌ها و خدمات مکمل وابسته است. مبلغ نهایی را براساس گزینه‌های فعال پنل یا پیش‌فاکتور فروش بررسی کنید.

آیا PaaS برای سازمان مناسب است؟

اگر تیم به استقرار استانداردتر و کاهش کار عملیاتی نیاز دارد، PaaS می‌تواند گزینه مناسبی باشد. پیش از سفارش، شبکه، امنیت، سطح دسترسی، SLA، پشتیبانی و سیاست داده را بررسی کنید.

راهنمای خرید PaaS

پیش از انتخاب پلتفرم PaaS، مسیر اجرای پروژه را بشناسید

مطالعه راهنمای کامل خرید PaaSبستن راهنمای کامل

خرید هاست Node.js و استقرار اپلیکیشن

برای API، Backend و سرویس‌های Real-time، نسخه Node.js، فرمان Start، متغیرهای محیطی، اتصال دیتابیس و رفتار WebSocket را بررسی کنید. اگر پروژه چند سرویس یا Worker دارد، هر فرایند را به‌عنوان سرویس مستقل طراحی کنید.

هاست Python، Django و Flask

در پروژه‌های Python باید فایل وابستگی، WSGI/ASGI، فرمان اجرای Gunicorn یا Uvicorn، فایل‌های Static و Migration دیتابیس مشخص باشد. Django برای محصول کامل‌تر و Flask برای سرویس‌های سبک‌تر مسیر رایجی است.

خرید هاست Laravel و PHP

نسخه PHP، افزونه‌های موردنیاز، Composer، Document Root، Queue Worker، Scheduler و دسترسی Storage را پیش از انتقال کنترل کنید. برای Laravel، مدیریت فایل‌های محیطی و اجرای Migration باید بخشی از برنامه Release باشد.

استقرار Docker روی PaaS

وقتی Runtime آماده برای وابستگی‌های پروژه کافی نیست، Docker محیط اجرا را قابل‌تکرار می‌کند. Image سبک، Health Check، پورت، Volume پایدار، Registry و روش Rollback را پیش از Production تعیین کنید.

هاست React، Next.js و Frontend

React و Vue می‌توانند خروجی Static داشته باشند؛ Next.js و Nuxt.js بسته به معماری به SSR یا Runtime سمت سرور نیاز دارند. نوع Build، متغیرهای زمان Build و Runtime، Cache و مسیر فایل‌های Static را از ابتدا روشن کنید.

PaaS چیست و چه مشکلی را حل می‌کند؟

پلتفرم به‌عنوان سرویس لایه‌ای میان کد اپلیکیشن و زیرساخت خام است. این مدل کارهای تکراری مانند آماده‌سازی Runtime، Build، انتشار و مشاهده وضعیت اجرا را منظم می‌کند تا تیم محصول زمان بیشتری برای توسعه داشته باشد؛ بااین‌حال معماری کد، داده، امنیت اپلیکیشن و انتخاب منابع همچنان مسئولیت تیم شماست.

خرید PaaS بهتر است یا VPS؟

اگر کنترل کامل سیستم‌عامل، نصب بسته‌های سیستمی خاص یا شبکه سفارشی اولویت اصلی است، VPS انعطاف بیشتری دارد. اگر استقرار استاندارد، تحویل سریع‌تر و کاهش نگه‌داری زیرساخت اهمیت بیشتری دارد، PaaS گزینه ساده‌تری است. تصمیم نهایی را با محدودیت‌های فنی و هزینه کل عملیات بگیرید.

سایر پلتفرم‌ها؛ .NET، Go، Angular، Vue و Nuxt

برای .NET نسخه Runtime و فرمان Publish، برای Go فرایند Build و Binary، و برای Angular، Vue و Nuxt نوع خروجی Static یا Server-side را مشخص کنید. نمایش این فناوری‌ها در صفحه به معنی فعال‌بودن همه نسخه‌ها نیست؛ گزینه‌های موجود پنل در زمان سفارش مرجع نهایی‌اند.

هزینه واقعی سرویس PaaS شامل چیست؟

فقط قیمت پایه اپلیکیشن را مقایسه نکنید. CPU، RAM، دیسک پایدار، ترافیک، دیتابیس، Backup، تعداد محیط‌ها، دامنه، Log و سطح پشتیبانی می‌توانند هزینه نهایی را تغییر دهند. مقایسه منصفانه باید روی معماری و واحد صورتحساب برابر انجام شود.

چک‌لیست مهاجرت اپلیکیشن به PaaS

نسخه Runtime، وابستگی‌ها، Cron Job، فایل پایدار، دیتابیس، Queue، Secrets، دامنه، TLS، Health Check، Log و برنامه Rollback را مستند کنید. ابتدا محیط آزمایشی بسازید و پیش از انتقال ترافیک، Build، اتصال سرویس‌ها و بازیابی داده را بررسی کنید.

برای Production چه سؤالاتی بپرسیم؟

محدودیت منابع، روش Scale، محل داده، Backup و بازیابی، دسترس‌پذیری، مدت نگه‌داری Log، سطح پشتیبانی، SLA، دسترسی اعضای تیم و نحوه خروج داده را شفاف کنید. پاسخ این پرسش‌ها ریسک انتخاب صرفاً براساس قیمت را کاهش می‌دهد.

راهنمای انتخاب سرویس

PaaS چه تفاوتی با VPS دارد؟

در PaaS نقطه شروع، استقرار و مدیریت اپلیکیشن است؛ در VPS مدیریت ماشین و سیستم‌عامل هم بخشی از کار شماست. انتخاب به روش ورود کد، محیط اجرای برنامه، وابستگی‌ها و میزان کنترل زیرساخت بستگی دارد.

پیش از سفارش بررسی کنید

  • روش ورود پروژه و محیط اجرای موردنیاز را مشخص کنید.
  • فرمان اجرا، متغیرهای محیطی و سرویس‌های داده را بررسی کنید.
  • منابع برنامه و مسیر انتشار را پیش از سفارش مشخص کنید.