Переезд Laravel на VPS: .env, хранилище, очередь и планировщик

Опишите текущую сборку и её зависимости

Сверьте `composer.lock`, версию PHP, расширения, Node-сборку фронтенда, веб-сервер, базу и Redis, если он применяется. Важно знать не только requirements в composer.json, но и фактическую версию, на которой приложение прошло production-проверку. Проверьте системные библиотеки и внешние бинарники, вызываемые кодом, например конвертер изображений или PDF. Список удобно получить вместе с результатом composer check-platform-reqs на копии проекта.

Найдите все точки запуска: веб-запрос, queue worker, scheduler, консольные команды, supervisor или systemd unit. Проверьте каталоги с пользовательскими файлами, журналы и временное хранение. Отдельно запишите внешние интеграции — почту, платёжный API, хранилище и webhooks. На тестовой копии их следует изолировать, чтобы миграционный запуск не создал настоящую отправку, платеж или дублирующее действие.

• Сравните PHP и расширения на обоих VPS.
• Проверьте composer.lock и сборку фронтенда.
• Найдите процессы, работающие вне веб-сервера.
• Опишите внешние зависимости и безопасный тест для каждой.

Подготовьте код, конфигурацию и секреты

Перенесите неизменённый релиз или исходники с фиксацией версии. Не редактируйте код вручную на старом и новом VPS одновременно: это усложняет понимание, какая сборка действительно работает. Подготовьте новый `.env` в безопасном хранилище и сравните обязательные переменные по именам, не копируя значения в обычный документ. Секреты базы, SMTP и сторонних API обновляют через установленный у проекта способ управления конфигурацией.

Не генерируйте новый APP_KEY автоматически, если приложение использует шифрование и cookies, зависящие от существующего ключа: смена может лишить доступа к зашифрованным данным или сессиям. Перенос текущего ключа тоже требует контроля, потому что это чувствительный секрет. Подготовьте доступ к новому ключу только у ответственных процессов и проверьте, что файл конфигурации недоступен через HTTP. После установки зависимостей проверьте владельца и права storage и bootstrap/cache.

• Сверьте перечень переменных окружения без публикации значений.
• Определите, сохраняется ли APP_KEY.
• Проверьте доступность .env только нужному пользователю.
• Сверьте права storage и bootstrap/cache.

Перенесите данные и пользовательские файлы

Скопируйте базу отдельным способом, соответствующим её движку, и выполните проверяемое восстановление. Не объединяйте файлы приложения и единственную копию данных в один неразличимый архив. Путь `storage/app/public` и ссылка `public/storage` требуют внимания: ссылка может указывать не туда после распаковки, а веб-пользователь — не иметь доступа к каталогу. Проверьте, не хранит ли приложение загрузки на отдельном диске или в S3-совместимом хранилище.

Для большого объёма загрузок сделайте раннюю синхронизацию, затем финальный проход при ограничении новых загрузок. Проверьте число файлов, размеры и выборочные контрольные суммы. Если приложение ставит фоновые задачи на обработку загрузки, убедитесь, что новая очередь получит корректные ссылки. Не запускайте очистку устаревших файлов на новом сервере до проверки: команда, которая была безопасной на исходном каталоге, может иметь другое значение при новом пути.

• Проверьте ссылки storage на целевой стороне.
• Сверьте владельца файлов веб-пользователем.
• Перенесите файлы вне контейнера приложения отдельно от кода.
• На время финальной копии определите судьбу новых загрузок.

Перезапустите очередь и планировщик в правильном порядке

Долгоживущие Laravel workers не обязаны перечитать переменные или код при изменении файлов. Обновите и перезапустите их штатным процесс-менеджером только после проверки нового приложения. До cutover убедитесь, что старые workers остановлены или перестали брать задания; иначе одна очередь может одновременно исполняться двумя площадками. Это особенно опасно для оплаты, рассылок, выдачи лицензий и других задач, где повтор имеет последствия.

Scheduler запускается по системному расписанию и обычно вызывает `schedule:run` с коротким интервалом. Сверьте путь к PHP, working directory, пользователя, timezone, окружение и журнал. На новой машине сначала запустите расписание в тестовом режиме или на ограниченной задаче, чтобы убедиться, что команды видны. Если оба VPS запускают одно и то же задание, используйте защиту от перекрытия или включите только один планировщик на период перехода.

• Перезапустите workers через выбранный менеджер процессов.
• Отключите старое расписание до запуска нового.
• Проверьте рабочую директорию и путь к PHP.
• Отметьте задачи, которые нельзя запускать дважды.

Проверьте приложение до и после переключения

На временном домене проверьте маршруты, авторизацию, загрузку файлов, экспорт, API и очередь. Выполните пользовательский сценарий от начала до результата, а не ограничивайтесь статусом главной страницы. Подключите тестовый режим сторонних систем и исключите отправку настоящих писем или платежей. Проверьте журнал PHP, приложения, веб-сервера, очереди и базы за один и тот же промежуток времени.

В день переключения остановите запись или фоновые изменения по плану, завершите перенос дельты, затем переведите входящий трафик. Следите за частотой ошибок, размером очереди, количеством свежих строк и загрузкой диска. Подготовьте конкретное условие отката, например отсутствие новых заказов или рост ошибок выше согласованного порога. Если возврат на старый VPS нужен, предусмотрите передачу данных, созданных после переключения.

• Проверьте тестовую авторизацию и отправку формы.
• Сверьте очередь задач и последний timestamp обработанного задания.
• Проверьте HTTPS, публичные файлы и API.
• Зафиксируйте критерии остановки перехода и возврата.

Подберите VPS под рабочую нагрузку Laravel

Смотрите на реальное распределение нагрузки: PHP-FPM, база, очередь, планировщик и файловая обработка. Если все компоненты на одной машине, оставьте запас для импорта и сборки. Если база или Redis вынесены отдельно, учитывайте внутреннюю сетевую задержку и ограничения firewall. Перед арендой VPS проверьте, подходит ли тариф по версии PHP, объёму диска, обновлению ресурсов и способу управлять сервисами.

Порядок в рейтинге ниже сохранён по <a href="https://impossible-studio.com/vps-vds/vps-vds-dlya-proekta-s-vebhukami-kak-ne-teryat-vhodyashhie-sobytiya-i-obrabatyvat-ih-bez-zaderzhek/">обзору VPS/VDS для проекта с вебхуками</a>. Для Laravel сравните условия, влияющие на ежедневную эксплуатацию: резервирование, восстановление, работа поддержки, доступ к консоли и трафик. Это поможет выбрать VPS для переноса без предположений о свойствах провайдера, которых нет в подтверждённых условиях тарифа.

• Учитывайте пиковую память web и queue workers.
• Сверьте лимиты и поддержку нужной версии PHP.
• Проверьте, как быстро увеличить диск или RAM.
• Заложите место для сборки и резервного архива.

После переключения Laravel проверьте очереди и расписание отдельно

Проверьте выполнение одного безопасного задания из очереди, затем сравните время обработки и сообщения об ошибках. Убедитесь, что worker читает новую базу и Redis, а не старые адреса из процесса, который был запущен до обновления конфигурации. Долгоживущий worker часто нужно перезапустить штатным способом приложения; одного изменения `.env` недостаточно для процессов, уже работающих в памяти.

Для расписания проверьте владельца системного cron, команду запуска, рабочий каталог и версию PHP CLI. Запланированная команда может использовать иной PHP, чем веб-сайт. До cutover избегайте запуска одинакового расписания на двух VPS одновременно, если задачи отправляют письма, списывают оплату или меняют остатки. Для каждой такой задачи определите единственный активный узел, время переключения и способ убедиться, что работа не повторилась.

• Проверьте worker на тестовом задании.
• Сверьте PHP CLI и веб-версию.
• Не запускайте побочные cron-задачи на двух узлах одновременно.
• Проверьте идемпотентность платежей и уведомлений.

Частые вопросы

Нужно ли менять APP_KEY при переносе Laravel?

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

Когда запускать queue worker на новом VPS?

После восстановления базы и файлов, проверки конфигурации и остановки старого обработчика. Не допускайте параллельного исполнения неидемпотентных заданий.

Нужно ли запускать scheduler на обоих серверах?

Обычно на период переноса это создаёт риск повторного запуска. Выберите один активный узел или примените механизм распределённой блокировки, который проверен для проекта.

Документация и полезные источники

• Laravel: deployment
• Laravel: очереди

Материал проверен 12 ноября 2026 года. Условия провайдеров, версии программ и DNS-настройки могут меняться — сверяйте актуальные данные перед выполнением переноса.