Поддержка Laravel 2026: тарифы, SLA и выбор подрядчика

Запустить Laravel-проект — это одна задача. Поддерживать его в рабочем состоянии год за годом — другая, и она не заканчивается. PHP-зависимости устаревают, в библиотеках находят уязвимости, бизнес-требования меняются. Laravel 9 вышел из поддержки в феврале 2024 — это значит, что проекты на этой версии больше не получают патчи безопасности от авторов фреймворка. Если ваш проект работает на Laravel 8 или 9, вопрос поддержки уже не академический. Ниже — как устроен рынок, сколько стоят разные форматы и что спросить у подрядчика до подписания договора.

Зачем нужна профессиональная поддержка Laravel

Laravel — фреймворк с предсказуемым жизненным циклом. Каждый мажорный релиз получает два года исправлений ошибок и три года патчей безопасности. Это хорошая новость: сообщество активно, документация подробная. Плохая новость: если ваш проект не обновляется, он постепенно выпадает из этого цикла.

Есть несколько причин, по которым поддержка нужна даже стабильному проекту:

• Безопасность. Уязвимости в PHP, Composer-пакетах и самом Laravel закрываются регулярно. Без обновлений проект становится мишенью для автоматических сканеров.
• Совместимость. Хостинги и облака обновляют PHP. Проект, написанный под PHP 8.0, рано или поздно окажется на сервере с PHP 8.3 — и если это не проверено заранее, сбои будут неожиданными.
• Доработки. Любой живой бизнес генерирует новые требования: новый тип оплаты, изменение в логике отчетов, интеграция с партнерским API. Без технической команды эти задачи накапливаются.
• Мониторинг. Нагрузочные пики, ошибки очереди задач, переполнение диска — все это обнаруживается либо системой мониторинга, либо жалобой клиента. Второй вариант хуже.

Подробнее о том, что такое полный цикл разработки на этом фреймворке, читайте в материале про разработку Laravel под ключ.

Что входит в техподдержку Laravel

Объем работ зависит от формата договора, но стандартный перечень для большинства проектов выглядит так:

• Мониторинг доступности. Автоматические проверки каждые 1-5 минут. При падении сервиса — оповещение команды.
• Устранение ошибок. Баги, которые попали в production: диагностика через Sentry или Laravel Telescope, исправление, деплой патча.
• Обновление фреймворка и зависимостей. Composer-обновления, миграция между версиями Laravel, проверка совместимости после обновления PHP.
• Резервное копирование. Ежедневные бэкапы базы данных и файлов, проверка восстановления по расписанию.
• Контентные правки. Небольшие изменения в тексте, шаблонах, конфигурации — в рамках оплаченных часов.
• Доработки и новый функционал. В зависимости от тарифа — либо включены, либо оцениваются отдельно.
• Безопасность. Аудит прав доступа, проверка на SQL-инъекции и XSS, настройка заголовков безопасности.

Если проект нуждается в более глубоких изменениях — например, переработке архитектуры или миграции на новую версию Laravel, — это ближе к задачам доработки сайта на Laravel, а не к рутинной поддержке.

Тарифы и форматы поддержки

На рынке сложились три рабочих модели. Разница — в цене и в том, что заказчик получает в периоды низкой активности.

Разовые задачи. Вы обращаетесь, когда есть конкретная задача. Подрядчик оценивает ее в часах, выполняет, выставляет счет. Ставка — 2 000-2 500 руб./ч (данные webdoka.ru, 2025). Этот формат подходит, если правки бывают один-два раза в месяц и нет требований к времени реакции. Минус: при инциденте вы в очереди наравне с другими клиентами.

Абонемент. Фиксированный пакет часов в месяц — обычно 10-20 ч. Стоимость: 20 000-50 000 руб./мес (данные makeagency.ru и webdoka.ru, 2026). За это вы получаете приоритет в очереди и фиксированную команду, которая знает ваш проект. Неиспользованные часы, как правило, не переносятся на следующий месяц.

Выделенный разработчик. Один или несколько разработчиков закреплены за вашим проектом на фиксированное количество часов в месяц — от 80 до 200 ч. Стоимость: 160 000-250 000 руб./мес (данные mwi.me и webdoka.ru, 2026). Оптимально для продуктов, которые активно развиваются и требуют нескольких задач в неделю.

Мониторинг и безопасность

Мониторинг для Laravel-проекта строится на нескольких уровнях. Первый — доступность: внешний сервис (Uptime Robot, Better Uptime или аналог) проверяет ответ сервера раз в минуту. Второй — ошибки приложения: Sentry или встроенный Laravel Telescope фиксируют исключения и медленные запросы в реальном времени. Третий — ресурсы сервера: CPU, RAM, дисковое пространство, длина очереди jobs.

По безопасности Laravel имеет хорошие встроенные механизмы — CSRF-защиту, экранирование вывода в Blade, политики авторизации. Но они не заменяют регулярный аудит зависимостей. Команда composer audit проверяет установленные пакеты по базе известных CVE — это минимум, который стоит выполнять при каждом обновлении зависимостей.

Резервные копии нужно проверять на создание и на восстановление. База данных, которая бэкапится каждые 24 часа, но при восстановлении дает ошибку — это не бэкап.

Обновления: Laravel и зависимости

Laravel следует схеме мажорных релизов: версия 10 поддерживается до февраля 2025, версия 11 — до марта 2026, версия 12 — до март 2027. Это предсказуемый цикл, и подрядчик по поддержке должен планировать обновления заблаговременно, а не в авральном режиме.

Обновление с одной мажорной версии на следующую при наличии покрытия тестами занимает 3-7 рабочих дней. Без тестов — сложнее: нужно проверять вручную каждый критичный сценарий. Это еще одна причина, почему качественная поддержка включает написание тестов для нового функционала.

Зависимости Composer обновляются отдельно. Часть обновлений безопасна и обратно совместима (patch-версии), часть требует проверки (minor), часть ломает API (major). Задача команды поддержки — отслеживать этот поток и не допускать накопления технического долга.

Если вас интересует более глубокий контекст — почему Laravel остается выбором для бизнес-приложений, — читайте статью про Laravel для бизнеса.

Как выбрать подрядчика для поддержки Laravel

Выбор команды поддержки отличается от выбора подрядчика для разработки. Важна техническая компетентность, и ещё — как команда ведет себя при инцидентах, как фиксирует изменения и как обеспечивает передачу проекта. Вот семь вопросов, которые стоит задать до подписания договора.

1. Какое время реакции на P0 (сайт лег) вы гарантируете, и чем это подкреплено в SLA?
Расплывчатое «ответим оперативно» — не SLA. SLA содержит конкретное число: «реакция в течение 30 минут в рабочее время, 2 часов — вне рабочего времени». И содержит определение, что считается P0, а что — P1.

2. Сколько проектов одновременно ведет один разработчик в вашей команде?
Если один человек ведет больше 20 проектов, при инциденте вы окажетесь в очереди. Нормальная нагрузка для поддержки — 5-10 активных проектов на разработчика при абонементной модели.

3. Как организована передача проекта при смене исполнителя?
Хорошая команда описывает процедуру передачи заранее: git-репозиторий, документация окружения, список интеграций, доступы. Плохая говорит: «не планируем расставаться». Второй ответ — не успокоение, а сигнал.

4. Ведете ли журнал всех правок?
Минимальный стандарт: git-история с осмысленными коммит-сообщениями на каждое изменение. Хороший стандарт: changelog с описанием задачи, времени выполнения и затронутых компонентов.

5. Каков порядок работы без предоплаты — или она обязательна?
Требование 100% предоплаты за первый месяц без тестового периода — это риск на стороне заказчика. Профессиональные команды предлагают оплату по факту или небольшой страховой депозит с зачетом в следующий месяц.

6. Есть ли у вас опыт с нашей версией Laravel?
Короткое «да, работали» ничего не говорит. Спросите конкретнее: работали ли с легаси-проектами на Laravel 8-9, поднимали ли проекты без документации, мигрировали ли между версиями без покрытия тестами.

7. Что происходит, если задача выходит за оплаченные часы?
Ответ «доделаем бесплатно» — тоже сигнал: значит, кто-то недооценит и потом будет торопиться. Профессиональный ответ: «оценим задачу заранее, при расхождении согласуем доплату до начала сверхурочной работы».

Красные флаги при выборе подрядчика

Несколько признаков, на которые стоит обратить внимание при изучении предложений.

1. Нет фиксированного SLA или «ответим как можно скорее». Без числа это не обязательство. При инциденте у вас не будет рычага для разговора о сроках.
2. Требуют 100% предоплату за первый месяц без тестового периода. Риск целиком на заказчике. Если формат работы вас не устроит — деньги уже потрачены.
3. Не могут назвать, сколько проектов ведут одновременно. Либо их слишком много, либо прозрачности нет. В обоих случаях вы не знаете, какой приоритет получите при инциденте.
4. Нет git-репозитория или говорят «все у нас в голове». Это означает: при смене подрядчика вы теряете историю изменений. А иногда — и сам код.
5. Не готовы подписать NDA или уклоняются от вопросов о хранении ваших данных. Доступы к базе данных и серверам — чувствительная информация. Команда, которая не может объяснить, как она хранится, не должна ее получать.

SLA: что важно прописать

SLA (Service Level Agreement) для Laravel-проекта должен содержать конкретные элементы, а не общие фразы о «качественном сервисе».

Классификация инцидентов. P0 — сайт недоступен, данные не сохраняются, платежная функция не работает. P1 — критичный функционал работает с ошибками. P2 — плановые задачи. Для каждого класса должно быть свое время реакции и время решения.

Рабочее время. Что происходит с инцидентом P0 в субботу в 23:00? Если в договоре нет ответа — значит, никто не знает. Хорошо, если это описано явно: «вне рабочего времени реакция на P0 — в течение 4 часов, оплачивается по коэффициенту 1.5».

Метрики доступности. Реалистичный uptime для веб-проекта на shared-хостинге — 99.5% (около 22 ч простоя в год). На VPS с нормальным мониторингом — 99.9% (около 9 ч). «Гарантия 99.99%» без собственного дата-центра и резервирования — маркетинг.

Что происходит при нарушении SLA. Без описания последствий SLA — это просто текст. Минимум: при превышении времени реакции заказчик получает скидку на следующий месяц или компенсацию часами.

Развитие: новые функции и оптимизация

Граница между поддержкой и развитием размыта, и это нормально. Стабильный проект со временем начинает требовать новых возможностей: интеграции с новым сервисом, изменения в логике отчетов, оптимизации медленных запросов.

Задачи развития обычно выходят за рамки стандартного абонемента и оцениваются отдельно. Важно, чтобы этот процесс был прозрачным: оценка в часах до начала работы, согласование, выполнение, отчет.

Для проектов, которые перешли в активную фазу развития, часто эффективнее перейти от абонемента к формату Laravel-аутсорса с выделенной командой — это дает больший ресурс при сопоставимой стоимости часа.

Смена подрядчика: как передать проект

Смена команды поддержки — рутинная процедура, если обе стороны подготовлены. Проблемы возникают, когда предыдущий подрядчик не вел документацию или намеренно удерживает доступы.

Чек-лист передачи работающего Laravel-проекта:

1. Git-репозиторий с полной историей коммитов
2. .env-файл и документация по переменным окружения (что за что отвечает)
3. Схема базы данных с комментариями к нестандартным таблицам
4. SSH-доступ к серверу, доступ к панели управления хостингом
5. DNS-записи и доступ к регистратору домена
6. Список всех интеграций с API-ключами (платежные системы, почтовые сервисы, маркетплейсы)
7. Описание нестандартных решений — то, что «не очевидно из кода»

При наличии этого пакета передача занимает 1-3 рабочих дня. Без него — недели, и с риском потерять часть функционала. Если текущий подрядчик отказывается предоставить перечисленное — это юридический вопрос, а не технический.

Часто задаваемые вопросы о поддержке Laravel

Нужна помощь специалистов? Техподдержка Laravel-проекта — команда EQ Team готова реализовать проект под ваши задачи.