Переезд с Vercel на VPS: Next.js, изображения, кеш и функции

MAATRIX · 17 октября 2026 · 8 мин чтения

Переезд Next.js с Vercel обычно ломается в деталях, которые раньше были незаметны. Главная страница открывается, разработчик выдыхает, а через час выясняется: изображения долго обрабатываются, письмо с восстановлением пароля ведёт на preview-домен, обновлённая цена не появилась в каталоге. Приложение перенесено, окружение — лишь частично.

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

Три вопроса, которые определяют маршрут

Первый: есть ли у проекта серверная логика? Если сайт полностью статический, можно рассмотреть static export. Если используются серверный рендеринг, обработчики запросов или действия на сервере, нужен работающий процесс Node.js. От выбора зависит схема размещения, а не только команда сборки.

Второй: какие сервисы подключены помимо Next.js? Проверьте хранилище файлов, базу, очередь, почту, аналитику и расписания. Наличие SDK в зависимостях — повод найти места его использования. Перенос приложения не переносит автоматически данные из этих сервисов.

Третий: будет один экземпляр приложения или несколько? Начинать проще с одного, если нагрузка позволяет. Несколько процессов требуют согласованного кеша, общих секретов и продуманного обновления. Копирование контейнера не делает состояние общим.

Для общей подготовки полезен материал о Next.js на VPS. Здесь сосредоточимся на особенностях ухода с Vercel и проверке функций, которые легко забыть.

Что остаётся внутри Next.js

По официальному руководству self-hosting обычный запуск Next.js поддерживает серверные возможности фреймворка, включая обработку изображений. Перед процессом рекомендуется обратный прокси. Он принимает публичные подключения, завершает TLS и ограничивает проблемные запросы.

Это означает, что next/image не обязательно заменять другим компонентом только из-за переезда. Однако ресурсы для обработки изображений теперь расходуются на вашей стороне. Сайт с десятком маленьких картинок и каталог с тысячами фотографий высокого разрешения создают разную нагрузку.

Составьте таблицу функций, которыми реально пользуется приложение. Для каждой укажите проверку: серверный рендеринг отдаёт содержательный HTML, обработчик API отвечает ожидаемым JSON, загрузка сохраняет файл, обновление товара сбрасывает нужный кеш. Такая таблица полезнее списка всех возможностей Next.js, большинство которых вашему проекту может быть не нужно.

Сборка: обычный запуск или standalone

Сохраните текущую рабочую версию Next.js и Node.js. Убедитесь, что установка зависимостей использует lock-файл. Сначала перенесите существующий выпуск, затем отдельно планируйте обновление фреймворка: иначе станет трудно отличить ошибку миграции от изменения поведения новой версии.

Для контейнера часто выбирают output: 'standalone'. В описании standalone объясняется, какие зависимости включаются в результат. Каталоги public и .next/static требуют отдельного внимания: их нужно доставить вместе со сборкой либо обслуживать предусмотренным внешним способом.

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

Собирайте выпуск один раз и переносите один и тот же артефакт на тестовую и рабочую среду, когда это допускает схема переменных. Иначе «проверенная версия» и «опубликованная версия» могут оказаться двумя разными сборками с одинаковым названием.

Переменные, которые нельзя просто скопировать все сразу

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

Удалите ненужные платформенные значения и задайте собственный публичный адрес. Проверьте разрешённые OAuth callback-адреса, домен cookies и адреса вебхуков. Секреты храните отдельно от образа и репозитория. Если нескольким экземплярам нужны общие ключи для согласованной работы, задавайте их одинаково защищённым способом.

Особенно внимательно посмотрите на код, выбирающий поведение по признаку preview или production. На VPS переменная, автоматически добавлявшаяся платформой, может отсутствовать. Тогда приложение внезапно включит тестовую оплату или сформирует внутренний адрес в письме.

Изображения: красота расходует процессор

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

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

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

Кеш должен обновлять именно то, что изменилось

Проверьте поведение после изменения данных, а не только после первого открытия страницы. Измените тестовую цену, выполните предусмотренную приложением инвалидацию и посмотрите результат в новом сеансе браузера. Отдельно проверьте кеш обратного прокси: он может удерживать ответ, который Next.js уже обновил.

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

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

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

Чем заменить платформенные удобства

Расписания перенесите в отдельный планировщик с журналом выполнения. Вебхук от платёжной системы должен проверять подпись независимо от площадки. Фоновые задачи выполняйте отдельным работником, если их длительность и надёжность выходят за рамки обычного HTTP-запроса.

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

Аналитику и сбор ошибок подключайте осознанно. После миграции нужно видеть частоту ошибок, задержку ответа и состояние диска. Красная лампочка в старом кабинете Vercel уже не следит за новым сервером.

Переключение без потери новых записей

Поднимите копию на тестовом домене и пройдите основные пользовательские действия. Проверьте прямое открытие вложенных URL, загрузку файлов, оплату в тестовом режиме и восстановление пароля. Перезапустите приложение и сервер: данные и службы должны остаться на месте.

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

Сохраните предыдущий выпуск. Откат кода должен учитывать миграции базы: удалённую колонку нельзя вернуть одним переключением Docker-образа. Для рискованных изменений используйте поэтапную схему, где старая версия некоторое время остаётся совместимой с новой структурой.

VPS под фактическую нагрузку

Для пилота небольшого Next.js-приложения MAATRIX Uab Start с 2 vCPU и 4 ГБ памяти может быть достаточной отправной точкой. Если сборка, обработка изображений и PostgreSQL работают вместе, рассмотрите Heka Standard с 4 vCPU и 8 ГБ. Более тяжёлому проекту может понадобиться отдельная база или конфигурация Maat Pro; решение принимайте после измерений.

Поддерживаемые Ubuntu и Debian позволяют выбрать привычное окружение. Диск рассчитывайте с учётом файлов, кеша, логов и свободного места для обновлений. VPS MAATRIX здесь становится управляемой площадкой для вашего приложения. Успех переезда измеряется работой каталога, входа и заказов — именно этих вещей посетитель ждёт от сайта, независимо от логотипа хостинга.