На 9 октомври 2026 г. Mistral добави Managed Deployments в публична предварителна версия. Услугата изпълнява Workflows върху инфраструктура на Mistral Cloud и изисква платен план. В съобщението са посочени управление през Studio или API, удостоверяване със служебни акаунти, логове и възможност изходящата мрежова връзка да бъде блокирана при изграждане и изпълнение.

Какво всъщност се управлява

Техническото ръководство описва изграждане на Docker образ от GitHub хранилище и изпълнение на контейнера според неговите ENTRYPOINT или CMD. Работникът получава автоматично обновяван токен за служебния си акаунт. Поддръжката изисква Workflows SDK поне 3.10. Посоченият регион е nl-north-1 в Нидерландия.

Редакционният ни прочит е, че услугата премества инфраструктурни задачи, без да премахва отговорността за приложението. Екипът продължава да определя какво прави процесът, какви данни използва и как изглежда приемлив резултат. Контейнер, който е стартирал успешно, и задача, която е изпълнена правилно, са различни нива на проверка.

За хипотетичен помощник, който обработва входящи запитвания, това означава да се разграничат получаването на съобщението, извличането на данните, подготовката на отговор и разрешението за изпращане. Управляваният изпълнител осигурява мястото за работа; конкретният екип трябва да определи границите между тези стъпки.

Лимитите са част от архитектурата

Страницата за квотите посочва три едновременно работещи управлявани внедрявания за Pay-as-you-go и десет за Enterprise; безплатният план има нула. Размерът на работника се избира от платформата. Все още не се показват отделни CPU и памет метрики за всяко внедряване. Лимитите на предварителната версия могат да се променят.

От тези числа не можем да изчислим автоматично колко клиентски задачи ще бъдат обслужени. Броят внедрявания и натоварването вътре в тях са различни величини. Полезен собствен тест би следил времето за завършване, отказите и натрупаната опашка при представителни задачи. SIExpo не е изпълнявал такъв тест и не обещава конкретен капацитет.

Кой може да регистрира процес

Ръководството за hardened deployments ограничава регистрацията до разрешени потребители и служебни акаунти. Новите управлявани внедрявания, създадени през Studio, са защитени по подразбиране с възможност за отказ от тази настройка. Другите клиенти могат да имат различно начално поведение. Правото да управляваш внедряването не е само по себе си право да регистрираш работник.

Това разграничение има практичен смисъл. В наш пример два процеса не бива случайно да се представят като една и съща производствена задача, без екипът да знае кой от тях ще получи изпълнението. Управлението на идентичностите трябва да е отделен преглед, а не предположение, основано на името на проекта.

Тайните имат собствен жизнен цикъл

Документацията за secrets описва свързване на тайна от същия workspace към променлива на средата. Промяната на стойността не рестартира автоматично работника. Посочено е и предупреждение, че Docker build аргументите могат да останат в историята и слоевете на образа. Следователно чувствителна стойност не трябва да се приема за защитена само защото е подадена при build.

За екипа това поставя конкретен въпрос при обновяване: кои работници вече използват новата стойност и кои още работят със старата? Собственият план за промяна трябва да включва наблюдение на реалното изпълнение. Тази поука произтича от описаното поведение, без да предполага допълнителна функция за автоматична ротация на външни услуги.

Наблюдението показва пътя на задачата

Отделното ръководство за observability описва OpenTelemetry логове, traces и метрики. Traces съдържат времена и грешки, докато логовете могат да се разглеждат за конкретно изпълнение. Изпращането към собствена система е възможно; пренасочените сигнали няма да се виждат в Studio, ако вече не се изпращат към платформата на Mistral.

За читателя това е причина да търси съгласувана следа: кога е започнала задачата, коя стъпка е спряла и какъв резултат е записан. Само зеленият статус на контейнера не разказва тази история. Публичната предварителна версия предлага конкретен нов начин за внедряване, но стойността му трябва да се оценява чрез действителния работен процес, а не чрез обещание за автоматизация без човешка организация.