سیاوش حسین‌زاده

مدیریت Fleet وردپرس همیشه بین دوتا سناریوی بد گیر کرده بود، یا پرداخت ماهانه سنگین به SaaSهایی مثل ManageWP، یا لاگین دستی و فرسایشی به هرکدوم از داشبوردها. حالا پروژه WPMgr اومده این وسط یه راه سوم بسازه. یه Control Panel متن‌باز بر پایه Go و یه ایجنت سبک PHP.

از زاویه مهندسی نرم افزار، معماریش واقعا تمیز پیاده شده. خبری از شیر کردن پسورد ادمین نیست و همه‌چیز با One-time code و امضای دیجیتال Ed25519 جلو میره. علاوه بر اون، سیستم Snapshot خودکار قبل از هر آپدیت و Rollback در صورت فیل شدن Health check، دقیقا همون فیچرهاییه که وقتی کلید کل زیرساختت رو میدی دست یه ابزار بهش نیاز داری.

اما با نسخه 0.61 و حدود ۱۶۰ تا ستاره، هنوز خیلی زوده که بهش برچسب Production-ready بزنیم. نکته کلیدی اینجاست که بکاپ‌ها فعلا سمت کلاینت Encrypt نمیشن، یعنی دیتای حساس کلاینت کاملا وابسته به Access control مقصد ذخیره‌سازیه (مثلا باکت S3 آروان کلاد یا هر چیز دیگه ای که استفاده کنید). پروژه با ۱۶۰۰ تا کامیت و CI مرتب پتانسیل بالایی داره، ولی تا وقتی توی دنیای واقعی تست نشه، سپردن دیتای بیزینس مشتری‌ها بهش ریسک و اشتباه بزرگیه. برای تست و روی پروژه‌های شخصی عالیه، ولی برای مشتری واقعی باید صبر کرد تا کد بیشتر چکش بخوره.

یه نکته مهم هم اینکه این نقد ها مربوط به حالت Self-hosted پروژه‌ست. با این وضعیت، نسخه SaaS هم فعلا خیلی قانع‌کننده نیست. وقتی بخشی از نگرانی های امنیتی و اعتماد رو از Self-hosted داری، پرداخت هزینه برای SaaS بدون اینکه مزیت خیلی مشخصی نسبت به گزینه‌های جاافتاده‌تر داشته باشه، چندان منطقی به نظر نمیاد. ضمن اینکه Claude هم توی توسعه پروژه نقش داشته و با یه نگاه به Frontend، به نظر میاد بخش قابل توجهی از اون با AI ساخته شده. استفاده از AI ذاتا ایراد نیست، ولی توی پروژه‌ای که قراره دسترسی مدیریتی به چندین سایت و دیتای امنیتی حساس داشته باشه، کیفیت Review و تست انسانی کد خیلی مهم تر میشه.

سورس پروژه: https://github.com/mosamlife/wpmgr

یکی از چیزهایی که توی Browser Agentها خیلی راحت نادیده گرفته میشه، هزینه هر Action ـه. وقتی برای هر حرکت، screenshot کامل صفحه رو به مدل میدی، LLM باید دوباره UI رو تحلیل کنه، المنت مناسب رو پیدا کنه و بعد تصمیم بگیره چه کاری انجام بده. این هم Token میخوره، هم Latency اضافه میکنه.

Browser Use برای همین ایده جالبی به اسم Jev Ultrafast منتشر کرده. به جای اینکه برای هر Action یک screenshot جدید به مدل بدی، ساختار صفحه و المنت های قابل تعامل رو به شکل ساده در اختیارش میذاری؛ مثلاً [3] textbox یا [7] button.

مدل دیگه لازم نیست بفهمه این دکمه کجای صفحه قرار گرفته یا کل UI چه شکلیه. فقط باید تصمیم بگیره مثلا:

روی [7] کلیک کنم؟ یا داخل [3] چیزی بنویسم؟

این تغییر ظاهرا ساده، معماری Agent رو هم عوض میکنه. Browser بیشتر کار اجرای Action رو انجام میده و LLM تبدیل میشه به Decision Maker. برای Browser Agent، همیشه بیشتر دیدن به معنی هوشمندتر شدن نیست؛ گاهی باید اطلاعاتی که مدل میبینه رو کمتر کنیم تا سریع تر و ارزان تر تصمیم بگیره.

سورس پروژه: https://github.com/browser-use/jev-ultrafast

خیلی‌ها وقتی میشنون "مدل جدید AI"، فکر میکنن قراره جایگزین GPT یا Claude بشه. Jev از TypeSafe AI اصلا برای این ساخته نشده. این مدل یه Primitive جدیده، یه تابع هوشمند که جواب typed برمی‌گردونه، نه متن. سه نوع سؤال داره: Choice (انتخاب از بین N گزینه تا ۲۵۵ تا)، Score (موقعیت روی یک طیف)، و Noul (احتمال yes/no). سوال مشخصی بهش میدی و اون مستقیما یه مقدار برمی‌گردونه billing، 0.82، 0.91. بدون Parse کردن متن، بدون Structured Output Error.

واقعیت فنی ماجرا چیه؟ قیمت ورودی ۰.۰۴۲$ به ازای هر میلیون Token با Output رایگان. Latency بین ۷۰ تا ۵۰۰ میلی‌ثانیه. ولی چیزی که معماری رو عوض می‌کنه الگوی Cascade هست. Jev درخواست‌های ارزان رو روت‌بندی میکنه و تصمیم میگیره کدوم‌ها اصلا به مدل گرون نیاز دارن. ایده ساده‌ست، صد درخواست میاد، ۶۰ تاش Code-only حل می‌شه (مثل lookup سفارش)، ۳۰ تاش مدل تخصصی کوچک‌تر میگیره و فقط ۱۰ تاش فرستاده میشه به Opus 5 یا GPT-5.6. در میلیون توکن، ۶,۴۸۰$ به جای ۳۰,۴۰۰$. و ۸۰۰,۰۰۰ تاش زیر نیم ثانیه جواب میده، نه ده ثانیه. یکی از شگفت انگیزترین کاربردهاش در ۴۸ ساعت اول ریلیز، یه Browser Agent که بلیط پرواز Zürich به London رو توی Google Flights واقعی، توی ۷.۱ ثانیه رزرو کرد. هزینه‌اش ۰.۰۰۳۹$ بود. مدل بزرگ فقط برای نوشتن متن فراخوانی می‌شد، بقیه کارها Jev انجام می‌داد. ولی حقیقت تلخش رو هم بخونید: Jev محاسبه نمیکنه، تاریخ رو نمیفهمه، و هر چیزی که کد میتونه حساب کنه رو نباید ازش بخواید. State‌ای که بهش میدید دنیاییه که اون فقط ازش می‌فهمه و اگه دیتای بد بفرستید، با اطمینان بالا جواب غلط برمیگردونه. benchmarks هم صرفا توافق با دو مدل frontier هست، نه Accuracy واقعی. Jev جایگزین LLM نیست! یه لایه تصمیم گیری سریع و ارزون جلوی LLM هست. اگه درکش کنی، کل معماری سیستم‌هات عوض میشه. لینک مقاله راهنما: https://dev.to/valyuai/how-to-use-jev-a-practical-guide-to-typesafes-system-one-model-g5e

سندروم تحلیل‌های زرد دوباره بالا گرفته، ولی واقعیت فنی ماجرا چیه؟

گوگل قابلیت Search generative AI control رو توی Search Console رول‌اوت کرده. کارش صرفا یک چیزه، تعیین اینکه محتوای شما توی AI Overviews و AI Mode گوگل بیاد یا Exclude بشه. نه قراره معجزه‌ای بشه و نه ربطی به Train شدن مدل‌های دیگه مثل GPT یا Grok داره. مدیریت دیتای آموزشی هنوز دست Google-Extended هست و این سوییچ حتی سیگنال رنکینگ سئو هم نیست.

از طرفی، حضور توی این نتایج لزوما برای هر بیزنسی برد نیست. اگه سایت فروشگاهی یا محصول Conversion-driven داری، پاسخ‌های جنریتیو اغلب کاربر رو در وضعیت Zero-click نگه می‌دارن! یعنی کاربر دیتای تو رو می‌خونه، خریدش رو جای دیگه می‌کنه و ترافیک ورودی سایتت رسما نابود می‌شه.

تکنولوژی ابزاره، نه ترند برای پز دادن. به جای تصمیم‌های هیجانی، گزارش Generative AI performance رو بررسی کنید و با توجه به مدل درآمدی سایت تصمیم بگیرید، نه ریلزهای چند ثانیه‌ای افرادی که تقریبا ۵ کلمه از مستندات رسمی گوگل رو نمی‌تونن از روش بخونن...

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

سیستم‌عامل FydeOS رویکرد متفاوتی داره. بیسش Chromium OS عه؛ یعنی همون تجربه ChromeOS بدون نیاز به خرید کروم‌بوک‌های گوگل. معماریش کلا بر پایه وب و سرویس‌های کلادی چیده شده، واسه همین روی کانفیگ‌های ضعیف و رم پایین هم خیلی نرم و ریسپانسیو میاد بالا.

قرار نیست جای یه توزیع کامل لینوکس یا سیستم‌عامل دسکتاپ اصلی شما رو بگیره و ورک‌فلو سنگین دولوپری بده. تارگتش وب‌گردی، تسک‌های سبک و مدیاست. ولی برگ برنده‌ش ساپورت روان از Subsystem اندرویده (فعلا تا اندروید ۱۳) که عملا کلی اپ موبایلی رو بدون سربار و لگ امولاتورها بالا میاره.

برای احیای لپ‌تاپ‌های خاک‌خورده و تبدیلشون به یه سیستم دم‌دستی انتخاب هوشمندانه‌ایه.

لینک دانلود: fydeos.io/download

ایمیل با دامین اختصاصی نامحدود روی کلادفلیر روی کاغذ جذابه، ولی ما پول سرویس‌هایی مثل Google Workspace رو برای UI یا ذخیره‌سازی نمی‌دیم؛ برای Deliverability می‌دیم.

پروژه Mailflare از نظر معماری Serverless واقعا تمیز پیاده شده. استک پروژه کاملا روی Edge سواره؛ ترکیب Cloudflare Workers با دیتابیس D1 و آبجکت استوریج R2. یعنی عملا بدون نیاز به مدیریت سرور لینوکسی یا کانتینر، هزینه زیرساخت سمت کاربر در اسکیل پایین تقریبا صفره.

اما چالش مهندسی سیستم‌های ایمیل هیچ‌وقت لایه Receive نبوده. دریافت ایمیل با Email Routing کلادفلیر ساده‌ست؛ چالش اصلی لایه Send، گرم کردن دامین، مدیریت IP Reputation و تنظیم دقیق رکوردهای SPF، DKIM و DMARC برای رد شدن از فیلترهای Spam پرووایدرهای بزرگه. چیزی که صرفا با چندتا ورکر سرورلس تضمین نمی‌شه.

برای MVP، سایدپروژه‌ها یا تست ایده‌هایی که توجیه نداره براشون اکانت دلاری تهیه بشه، یک گزینه فوق‌العاده‌ست. ولی برای پروداکشن بیزینس و ایمیل‌های Transactional حساس، ریسک بالایی داره.

سورس پروژه روی گیت‌هاب: https://github.com/hieunc229/mailflare

اختلال گسترده‌ای که الان تو چندتا هاستینگ و سرویس مختلف می‌بینیم: (پارس‌پک، سون‌ هاست، لیموهاست، ایران‌سرور… حتی ترب و بعضی پنل‌های پیامکی) بیشتر از هر چیز نشون می‌ده تیم‌های فنی دارن با یه شرایط خارج از کنترل خودشون می‌جنگن. وقتی برق چندتا دیتاسنتر مثل های‌وب هم‌زمان می‌پره، هیچ معماری‌ای صددرصد آماده نیست!

اینجور لحظه‌ها تیم‌ها دارن با دست‌های بسته سرویس رو روی هوا نگه می‌دارن و همزمان Recovery رو جلو می‌برن. فشار کاریشون وحشتناکه و سطح استرس بسیار بالاست.

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

اگه دسترسی مستقیم دارید به هاستتون، فقط بکاپ بگیرید و کنار بکشید، بذارید تیم‌ها با تمرکز و بدون استرس اضافه کار رو جمع کنند.

شب‌های سختِ زیرساخت همیشه روی دوش همین آدم‌هاست و واقعا باید پشتشون باشیم.

امیدوارم هرچه زودتر این مشکل برطرف بشه.

داستان اینجاست که Anthropic توی Claude Code چندتا سوتی سنگین داده بود که عملا با یک git clone ساده، سیستم دیپلوی‌منت و API Key هاتون به باد می‌رفت. مشکل از فایل‌های کانفیگ مثل settings.json شروع می‌شه. جایی که مهاجم می‌تونه با ست کردن ANTHROPIC_BASE_URL کل ترافیک و توکن‌های شما رو به سرور خودش Redirect کنه، اونم قبل از اینکه حتی دکمه تایید رو بزنید.

بحث فنی‌تر اینجاست که وقتی به AI اجازه دسترسی به Terminal و MCP (Model Context Protocol) میدی، فایل‌های کانفیگ دیگه فقط دیتا نیستن، بخشی از Execution Layer حساب می‌شن. یعنی باز کردن یک Repo غریبه مساوی با اجرای کد مخرب روی لوکال.

خلاصه اینکه توی دنیای AI-Driven Development، دیگه فقط نباید نگران پکیج‌های npm باشیم، حالا باید حواسمون به فایل‌های تنظیمات ابزارهای کدزنی هم باشه. امنیت Supply Chain از اونی که فکر می‌کردیم پیچیده‌تر شده اگه قرار باشه با AI زندگی کنیم.

وقتی ابزاری مثل n8n رو وسط سازمان میارید که به همه‌جا، از APIهای LLM گرفته تا سیستم‌های IAM و دیتای فروش دسترسی داره، عملا دارید یک Skeleton Key به نفوذگر می‌دید. با افشای CVE-2026-1470 با امتیاز ۹.۹، مشخص شد که دور زدن Sandbox و رسیدن به RCE از اون چیزی که فکر می‌کردیم راحت‌تره.

مشکل اینجاست که خیلیا فکر می‌کنن چون n8n محیط Low-code داره، پس هر کسی با دو تا درگ‌-اند-دراپ می‌تونه معمار اتوماسیون سازمان باشه! (یا مثلا متخصص اتوماسیون با هوش مصنوعی 😂) فاجعه دقیقا از همین‌جا شروع می‌شه. سپردن زیرساخت اتوماسیون به آدم‌هایی که درک عمیقی از معماری نرم‌افزار و چالش‌های امنیتی ندارن، یعنی فاجعه...

توی این گزارش جدید، محقق‌های JFrog نشون دادن که حتی با وجود لایه‌های کنترلی مبتنی بر AST و لیست‌های سیاه، باز هم می‌شه از قابلیت‌های Deprecated شده یا رفتارهای خاص Interpreterها استفاده کرد و از زندان Sandbox فرار کرد. این یعنی امنیت در سطح کد، تضمین‌کننده نیست.

بزرگترین اشتباه استراتژیک، استفاده از Internal Mode در محیط Production است. n8n صراحتا هشدار داده که برای ایزوله‌سازی باید از External Mode استفاده بشه، اما آمار Shadowserver نشون می‌ده که هنوز بیش از ۳۹,۰۰۰ Instance آسیب‌پذیر توی اینترنت رها شدن. این یعنی فقر دانش زیرساختی در تیم‌هایی که ادعای اتوماسیون دارن.

باید قبول کنیم که مدیریت امنیت در زبان‌های داینامیک مثل Python و JS برای محیط‌های Multi-tenant کابوسه. اگر تیم شما تخصص مدیریت Task Runnerها و ایزوله‌سازی فرآیندها در سطح سیستم‌عامل رو نداره، همین الان دسترسی‌های n8n رو محدود کنید.

اتوماسیون بدون امنیت، فقط سرعت بخشیدن به نابودی سازمانتونه. اگه معمار زیرساخت سر پروژه نیست، n8n رو برای کارهای حساس لانچ نکنید.

وقتی گوگل‌بات به خاطر اختلالات شبکه یا اختلال در اینترکانکت نمی‌تونه دیتاسنترهای داخلی رو درست Crawl کنه، عملا فرقی با Down بودن سایت نداره. راه‌حل این روزها برای فرار از افت رتبه، استفاده از یک کپی Mirror روی هاست خارج (مثلا اروپا) و بازی با NSهاست.

با ست کردن نیم‌سرورهای ایران و خارج در کنار هم، یه جور Failover دستی ایجاد می‌کنید. اینطوری وقتی دسترسی گوگل از بیرون به ایران مختل می‌شه، گوگل بات می‌ره سراغ هاست اروپا و ایندکس متوقف نمی‌شه. برای کاربر داخل هم همچنان Latency پایین هاست ایران رو داریم.

فقط یادتون باشه این یه Dirty Hack برای بقاست، نه یه استراتژی تمیز! اگه سایت فروشگاهی دارید، حتما روی نسخه خارج، درگاه پرداخت و ثبت‌نام رو ببندید تا دیتابیس‌هاتون ناهمگام (Out of sync) نشه. سئو مهمه، ولی Integrity دیتا از اون هم مهم‌تره.