Vercel удобен, пока проект не упирается в лимиты деплоя и кэш

Vercel удобен, пока проект не упирается в лимиты деплоя и кэш

За неделю в репах видно один и тот же сценарий: команду заманивает нулевой DevOps, а потом внезапно начинают мешать не фичи, а ограничения платформы. У Vercel сильный старт для фронтенда: preview-окружения, быстрый deploy, простая привязка домена, хороший DX для Next.js.

Но для коммерческого проекта надо смотреть не на «удобно», а на три вещи: где живут статика и SSR, как считаются функции, и что происходит при росте трафика. Частая ошибка — тащить туда всё подряд: тяжёлые API, фоновые задачи, долгие запросы к БД, генерацию файлов. Это почти всегда превращает “быстро стартовали” в “почему стало дорого и медленно”.

Перед миграцией проверь чек-лист: 1) сколько у тебя серверной логики; 2) есть ли фоновые джобы и cron; 3) нужен ли edge runtime или хватит обычных функций; 4) как устроены кэширование и инвалидация; 5) можно ли без боли уехать на другой хостинг, если лимиты станут тесны.

Если проект маленький, Vercel даёт хороший time-to-market. Если уже есть нагрузка и сложный backend, держи фронт отдельно, а критичную логику выноси в сервисы, которые легче масштабировать и переносить.