تصور کنید برنامهنویسی هستید که در سپتامبر ۲۰۲۶ میان دو راهی دشواری گیر کرده است: سرعت خیرهکننده در توسعه یا اطمینان مطلق از اینکه کد روی سرور دقیقاً همانطور اجرا میشود که روی لپتاپش بوده است. انتخاب میان Lerd و Docker Desktop دیگر صرفاً بحث کانتینرسازی نیست، بلکه درباره این است که عاملهای هوش مصنوعی (AI Agents) چگونه استک محلی شما را مدیریت میکنند. این ابزارها برای انواع متفاوتی از «صحت» بهینه شدهاند؛ Lerd سرعت توسعهدهنده در پروژههای PHP را در اولویت قرار میدهد و Docker Desktop بر تطابق کانتینری و ثبات گستردهتر اکوسیستم تمرکز دارد.
توسعه محلی برای PHP سالهاست که میدان نبرد میان راحتیِ سرعتهای بومی و قابلیت اطمینان کانتینرهاست. در حالی که ابزارهایی مثل Laravel Herd گردش کار در macOS را ساده کردند، تیمهای لینوکس و مک اغلب با «مالیات کانتینر» دستوپنجه نرم میکردند؛ یعنی همان حجم زیاد فایلهای YAML و مدیریت Volumeها فقط برای ویرایش یک کنترلر ساده. اگر بخواهید این دو ابزار را در یک مدل ذهنی واحد قرار دهید، مقایسه تیره و تار میشود. سوال واقعی این نیست که «کدام یک بهتر است»، بلکه این است که «برای چه هدفی بهتر است؟»
زمینه: تفاوت در مسائل بنیادین
Lerd صراحتاً یک ابزار PHP-first است. این ابزار برای کسانی طراحی شده که میخواستند تجربه Laravel Herd را روی لینوکس داشته باشند و تمرکز ویژهای بر باز بودن و گردش کارهای «عامل-آگاه» (Agent-aware) دارد. مجموعه ویژگیهای آن حول محور سایتهای لینکشده، HTTPS خودکار، تغییر Runtime و نصب آگاه از فریمورک ساخته شده است. هدف Lerd حذف اصطکاکهای عملیاتی است که چرخه روزانه یک توسعهدهنده PHP را کند میکند.
در مقابل، Docker Desktop یک لایه راحتی برای لاراول نیست؛ بلکه یک پلتفرم عظیم کانتینری است. داکر یک گردش کار پایدار با Compose فراهم میکند و همسویی شدیدی با سیستمهای تولیدی (Production) دارد که در حال حاضر در کانتینرها اجرا میشوند. اگر اپلیکیشن شما به شبکه پیچیدهای از PHP، Nginx، Redis، Meilisearch، Workerهای صف و Sidecarهای سفارشی وابسته است، داکر شما را مجبور میکند تمام این موارد را صراحتاً تعریف کنید تا اطمینان حاصل شود که روی هر ماشینی به یک شکل اجرا میشوند.
این تفاوت، تعریف «راهاندازی محلی» (Local Setup) را تغییر میدهد. در Lerd، راهاندازی معمولاً به معنای لینک کردن پروژه، اجازه دادن به ابزار برای سیمکشی دامنهها و سرویسها و تغییر نسخه PHP است. اما در Docker Desktop، راهاندازی شامل کلون کردن مخزن، نصب پلتفرم، تایید استک Compose، مدیریت Volumeها و پورتها، انتظار برای Build شدن Imageها و عیبیابی موارد خاص در لبههای ارتباط میزبان و کانتینر است.
بازی سرعت: رویکرد PHP-First در Lerd
Lerd خود را به عنوان یک محیط Podman-native معرفی میکند که مخصوص PHP در لینوکس و macOS طراحی شده است. این ابزار صراحتاً ساخته شده تا همان چیزی باشد که کاربران Laravel Herd در لینوکس آرزو داشتند. طبق مستندات آن، Lerd با اتوماسیون خستهکنندهترین بخشهای نصب لاراول، «تشریفات» (Ceremony) داکر را حذف میکند.
ویژگیهای کلیدی Lerd عبارتند از:
- شبکهبندی خودکار: اتصال سایتها به دامنههای
.testو فعالسازی خودکار HTTPS. - انعطافپذیری در Runtime: توسعهدهندگان میتوانند نسخه PHP و Node را برای هر پروژه به صورت مجزا تغییر دهند، بدون اینکه نیاز به بازسازی Imageها باشد.
- سرویسهای باندلشده: وابستگیهای رایج مانند Redis و پایگاهداده به عنوان سرویسهای داخلی ارائه میشوند.
- پیکربندی آگاه از فریمورک: جریانهای تخصصی برای لاراول، شامل مدیریت یکپارچه لاگها و Workerها.
برای یک برنامهنویس جونیور، این یعنی تجربه روز اول تقریباً آنی است. آنها مجبور نیستند برای شروع کدنویسی به «مکانیک کانتینر» تبدیل شوند. آنها از تلههای رایج پورتهای باز، Bind Mountها و بررسیهای آمادگی سرویس (Service Readiness) که اغلب باعث سردرگمی در Onboarding داکر میشود، در امان میمانند. توسعهدهندگان ارشد اغلب دانش نامرئی داکری که در طول زمان جمع کردهاند را دستکم میگیرند؛ اما جونیورها ده قطعه متحرک و چهار جای مختلف را میبینند که ممکن است خطا در آنها پنهان باشد. ارگونومی PHP-first در Lerd این مالیات ذهنی را کاهش میدهد.
بازی تطابق: زیرساخت Docker Desktop
Docker Desktop برای نوع دیگری از صحت بهینه شده است: تطابق با محیط تولید (Production Parity). داکر سعی نمیکند یک لایه راحتی برای لاراول باشد، بلکه یک پلتفرم کامل کانتینری با اکوسیستمی عظیم و گردش کار Compose پایدار است. داکر با فایل Compose به عنوان یک قرارداد قانونی برای توپولوژی اپلیکیشن برخورد میکند.
نقاط قوت داکر در موارد زیر است:
- آینهسازی دقیق: اگر محیط تولید از یک Image خاص PHP با اکستنشنهای کامپایلشده سفارشی استفاده میکند، داکر تضمین میکند که محیط محلی دقیقاً مشابه آن باشد.
- توپولوژیهای پیچیده: داکر زمانی میدرخشد که یک مخزن شامل سرویسهای غیر PHP، Sidecarهای سفارشی یا نیازهای شبکهای غیرtrivial باشد (مثلاً ترکیب PHP، Nginx، Redis، Meilisearch، یک Worker صف و یک Scheduler).
- ثبات: حذف سندرم «روی سیستم من کار میکرد» با اجبار به تعریف تمام پیشفرضهای محیطی در تنظیمات تحت کنترل نسخه (Version-controlled).
اگرچه این رویکرد وزن عملیاتی را زیاد میکند، اما از شکستهای بحرانی جلوگیری میکند؛ مواردی که در آن Workerهای صف یا ایندکسرهای جستجو در محیط Staging متفاوت از محیط محلی رفتار میکنند. داکر انتخابی صادقانه است وقتی صحت محلی به خودِ قرارداد کانتینر وابسته باشد—مثلاً زمانی که شما همان Image را در CI، محیطهای Preview و Production اجرا میکنید.
ایزولاسیون Runtime و تطابق: توازن (Trade-off)
Lerd ایزولاسیون PHP به ازای هر پروژه و سرویسهای محلی را با اصطکاک بسیار کمتری نسبت به یک استک داکر فراهم میکند. برای اکثر محصولات لاراول که بر پایه CRUD هستند، این مقدار کافی است. اگر یک پروژه به PHP 8.2 و پروژه دیگر به 8.4 نیاز دارد و هر کدام Redis یا دیتابیس خود را میخواهند، Lerd موارد رایج را پوشش میدهد بدون اینکه توسعهدهنده را مجبور کند تمام روز به ارکستراسیون فکر کند.
با این حال، این با تطابق کامل اپلیکیشن (Full Application Parity) متفاوت است. Docker Desktop قویترین تضمین را ارائه میدهد که شکل Runtime محلی، آینه محیط تولید است. این شامل نه تنها نسخه، بلکه نحوه شبکهبندی سرویسها، نحوه شروع، پیکربندی، Mount شدن و نظارت (Supervision) آنهاست. این امر از ناراحتیهای رایج زیر جلوگیری میکند:
- «Worker صف در محیط Staging متفاوت رفتار میکند.»
- «ایندکس جستجو فقط در Build کانتینر شکست میخورد.»
- «این اکستنشن در محیط محلی وجود دارد اما در تولید نیست.»
- «روی سیستم من کار میکند اما در CI نه.»
جزئیات: یافتن نقطه بهینه
نقطه بهینه Lerd
Lerd زمانی انتخاب مناسبی است که محیط تولید شما آنقدر عجیب و غریب نباشد که توسعهدهندگان محلی نیاز داشته باشند هر کانتینر را دقیقاً آینهسازی کنند. اکثر محصولات لاراول CRUD-heavy در این دسته قرار میگیرند. آنها به PHP منطقی، سرویسهای رایج، TLS، Workerها و جریان کاری روان روزانه نیاز دارند. آنها نیاز ندارند هر همتیمی قبل از ویرایش یک کنترلر، مشغول عیبیابی «لینوکس-در-یک-باکس» شود. برای این تیمها، داکر اغلب بیشتر از آنکه ارزش ایجاد کند، تشریفات اضافه میآورد.
نقطه بهینه Docker Desktop
داکر زمانی به انتخاب بهتری تبدیل میشود که صحت محلی به خودِ قرارداد کانتینر وابسته باشد. این در موارد زیر حیاتی است:
- وقتی چندین سرویس اپلیکیشن با شبکهبندی غیرtrivial را ارسال میکنید.
- وقتی به یک Base Image سفارشی با اکستنشنهای کامپایلشده متکی هستید.
- وقتی همان Image را در CI، محیطهای Preview و Production اجرا میکنید.
- وقتی سرویسهای غیر PHP بخشهای درجه اول مخزن هستند، نه وابستگیهای اتفاقی.
- وقتی میخواهید هر پیشفرض محیطی در Compose یا تنظیمات Image تحت کنترل نسخه تعریف شده باشد.
تغییر به سمت عاملهای هوش مصنوعی: ادغام MCP
مهمترین تکامل در سال ۲۰۲۶، ادغام پروتکل زمینهٔ مدل (Model Context Protocol یا MCP) است. عاملهای هوش مصنوعی در حال حرکت از تولید صرف کد به سمت مدیریت فعال محیط محلی هستند. این دیگر یک مزیت انحصاری داکر نیست.
Lerd شامل یک سرور MCP داخلی است که به طور خاص برای دستیارهای هوش مصنوعی که محیط محلی را مدیریت میکنند، طراحی شده است. فایل README آن صراحتاً عملیات محیطی را لیست میکند که یک عامل اکنون میتواند مستقیماً انجام دهد:
- لینک کردن سایتها به دامنهها.
- مدیریت سرویسهای محلی.
- اجرای جریانهای نصب آگاه از فریمورک.
- تغییر Runtimeهای PHP.
- دنبال کردن (Tailing) لاگها و کار با پایگاهدادهها.
این یک حرکت با اهرم بالا برای تیمهایی است که از عاملهای کدنویسی برای انجام «کارهای سخت و تکراری» نگهداری محیط استفاده میکنند—کارهایی که توسعهدهندگان اغلب فراموش میکنند یا به تعویق میاندازند. Lerd در اینجا جسور است و یک سطح ابزاری متمرکز بر پروژه PHP را ارائه میدهد.
Docker Desktop (نسخه ۴.۶۲ به بعد) با MCP Toolkit پاسخ داده است. این یک زیرساخت گستردهتر در سطح پلتفرم است که ویژگیهای زیر را دارد:
- پروفایلهای MCP و یک کاتالوگ جامع.
- مدیریت CLI برای سرورهای MCP.
- سرورهای MCP کانتینری و جریانهای کاری ایزوله (Sandboxed) برای عاملها.
- پشتیبانی از MCP پویا و MCP Gateway.
در حالی که این سیستم قدرتمندتر و گستردهتر است، توسعهدهنده را مجبور میکند به جای اکشنهای خاص لاراول، در قالب ابزارهای کانتینری و Gatewayها فکر کند. Lerd یک بازی مستقیم روی تجربه توسعهدهنده (DX) است؛ داکر یک بازی روی زیرساخت گسترشپذیر است.
مقایسه گردش کار روزانه
در یک سهشنبه معمولی، کاربر Lerd یک Branch را Pull میکند و میبیند که پروژه از قبل روی یک دامنه تمیز با نسخه درست PHP فعال است. Redis و دیتابیس در دسترس هستند و قابلیت مشاهده صف/زمانبندی یکپارچه شده است. شما میتوانید Runtimeها را تغییر دهید یا لاگها را بررسی کنید بدون اینکه از نظر ذهنی از «حالت لاراول» خارج شوید. گردش کار کاملاً در حالت لاراول باقی میماند، که برای تیمهایی که سریع کد اپلیکیشن را ارسال میکنند، ایدهآل است.
یک کاربر Docker Desktop ممکن است با بازسازی کانتینرها یا کندی عملکرد Bind-mount مواجه شود. آنها باید مطمئن شوند که استک Compose درست است و منتظر Build شدن Imageها بمانند. عملکرد Bind-mount یک توسعهدهنده ممکن است بدتر از دیگری باشد، یا کسی ممکن است فراموش کند بعد از تغییر اکستنشنها، Image را بازسازی کند. با این حال، آنها این اطمینان را دارند که Worker و Scheduler محلی آنها دقیقاً همان Imageای را اجرا میکند که به تولید میرود. وقتی استک به خوبی نگهداری شود، این ثبات با پیچیدهتر شدن معماری (فراتر از سادگی لاراول)، ارزشمندتر میشود.
معیارهای انتخاب برای سال ۲۰۲۶
Lerd را انتخاب کنید اگر اکثر این موارد درست است:
- مخزن شما عمدتاً یک اپلیکیشن لاراول یا PHP است.
- سرعت توسعهدهنده محلی بیشتر از تطابق دقیق کانتینری اهمیت دارد.
- تغییر آسان PHP به ازای هر پروژه را بدون نگهداری Imageها میخواهید.
- میخواهید عاملهای هوش مصنوعی محیط را از طریق یک سطح MCP متمرکز بر PHP مدیریت کنند.
- تیم شما شامل توسعهدهندگانی است که برای بهرهوری نباید به دانش عمیق داکر نیاز داشته باشند.
Docker Desktop را انتخاب کنید اگر اکثر این موارد درست است:
- فایلهای Compose از قبل بخشی از گردش کار عادی تیم شما هستند.
- محیط تولید در کانتینرها اجرا میشود و تطابق محلی به طور روتین شما را از باگها نجات میدهد.
- مخزن شامل چندین سرویس فراتر از یک استک استاندارد لاراول است.
- به کنترل در سطح Image روی اکستنشنها، باینریها، جریانهای استارتآپ یا قراردادهای سرویس نیاز دارید.
- ابزارهای هوش مصنوعی شما باید با یک داستان گستردهتر از MCP کانتینری و Sandbox سازگار باشند.
توصیه نهایی
برای اکثر تیمهای Laravel-first، من با Lerd شروع میکنم. این یک توصیه کاربردی است: اکثر تیمها بازدهی (ROI) معناداری از وارد کردن پیچیدگی کامل داکر به توسعه محلی برای هر پروژه به دست نمیآورند. در عوض، آنها با Onboarding کندتر، حلقههای بازخورد کندتر و عادیسازی خاموشِ اصطکاک محیطی مواجه میشوند.
Lerd پیشفرض تیزتری است وقتی اپلیکیشن عمدتاً لاراول است و عاملهای هوش مصنوعی بخشی از گردش کار هستند. پشتیبانی داخلی آن از MCP اکنون که عملیات محیط محلی در حال تبدیل شدن به بخشی از توسعه با کمک عاملهاست (و نه یک لایه مجزا و فقط انسانی)، بسیار مرتبط است. با این حال، Lerd جایگزین جهانی Docker Desktop نیست. اگر معماری تولید شما واقعاً «کانتینر-شکل» است، اگر مخزن شما بیشتر شبیه یک پلتفرم است تا یک اپلیکیشن، یا اگر تیم شما به Compose به عنوان حقیقت مشترک وابسته است، Docker Desktop همچنان جایگاه خود را دارد. در آن محیطها، وزن اضافی در واقع خریدِ چیزی واقعی است.
اشتباه این است که داکر را انتخاب کنید چون «جدیتر» به نظر میرسد، یا Lerd را انتخاب کنید چون داکر یک بار کسی را اذیت کرده است. ابزاری را انتخاب کنید که با «حالت شکست» (Failure Mode) واقعی که سعی در اجتناب از آن دارید، مطابقت داشته باشد. اگر حالت شکست، توسعه کند لاراول است، Lerd را انتخاب کنید. اگر حالت شکست، Drift محیطی میان سرویسها و مراحل مختلف است، Docker Desktop را انتخاب کنید. این قانون تصمیمگیری واقعی است. هر چیز دیگری جزئیات پیادهسازی است.
گفتگو