Где вы запускаете проекты: на серверах или в контейнерах

Что проверяют

Понимаете ли вы, что происходит с фронтендом после npm run build, или деплой для вас чёрный ящик. Следом обычно спрашивают, как в сборку попадают переменные окружения и как вы откатываете неудачный релиз.

Как отвечать

Отвечайте про свои проекты и сразу разделите случаи, потому что для фронтенда они устроены по-разному:

• статика (SPA на Vite, React, Vue): после сборки это папка dist с HTML, JS и CSS. Её можно отдать через nginx на сервере, но чаще кладут в объектное хранилище за CDN, контейнер тут не обязателен;
• SSR (Next.js, Nuxt): нужен работающий Node.js-процесс. Его запускают в контейнере (у Next.js для этого есть output: "standalone"), на виртуалке под PM2 или systemd, либо на платформе вроде Vercel;
• контейнер: многоэтапный Dockerfile, где первый этап ставит зависимости и собирает проект, а финальный образ содержит только результат: nginx:alpine для статики или облегчённый node для SSR. Дальше образ уезжает в Kubernetes или в docker compose на сервере;
• окружения: переменные с префиксом VITE_ или NEXT_PUBLIC_ вшиваются в бандл при сборке. Значит, либо образ собирается под каждое окружение, либо конфиг подгружается при старте из отдельного файла.

Назовите, что делали сами: писали Dockerfile, настраивали пайплайн в GitLab CI или GitHub Actions, заголовки кэширования. Нужны ваши реальные детали, а не общий список плюсов Docker.

Если деплоем занимался DevOps, так и скажите: «сборку и конфиг писал я, выкладку делала команда инфраструктуры», и покажите, что понимаете схему целиком.

Где спотыкаются

Не различают статику и SSR и предлагают поднимать Node.js-сервер ради папки с файлами, которую отдаст любой CDN.

Кладут в VITE_ или NEXT_PUBLIC_ ключи и токены. Всё, что попало в бандл, видит любой посетитель в DevTools.

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