Главная · Frontend
Frontend

как деплоить frontend приложение на сервер

3DH.su3DH.su 23 июня 2026 5 мин чтения
как деплоить frontend приложение на сервер

Когда вы нажимаете npm run dev и видите свое приложение в браузере, возникает иллюзия, что работа закончена. Но настоящий «ад» начинается тогда, когда проект нужно выкатить на реальный сервер так, чтобы он не упал при первом же наплыве пользователей, быстро грузился и обновлялся без даунтайма.

В этой статье я разберу процесс деплоя современного SPA (React, Vue, Angular или Svelte) — от подготовки билда до настройки веб-сервера и автоматизации через CI/CD.

1. Фундамент: Понимаем, что мы деплоим

Главная ошибка новичков — попытка запустить npm run dev прямо на сервере. Запомните: сервер для разработки и сервер для продакшена — это разные вещи.

Frontend-приложение после сборки (npm run build) превращается в набор статических файлов: index.html, .js, .css и картинки. Вам не нужен Node.js на сервере, чтобы отдавать эти файлы. Вам нужен веб-сервер, который будет эффективно передавать эти файлы браузеру клиента.

Что происходит при сборке (Build process):

  1. Минификация: Удаление всех пробелов и комментариев, сокращение имен переменных.
  2. Транспиляция: Преобразование современного JS (ES6+) в старый стандарт, который понимают даже древние браузеры.
  3. Bundle splitting: Разделение кода на части, чтобы пользователь не качал всё приложение сразу, а загружал только нужные модули.
  4. Хеширование: Добавление уникальных строк к именам файлов (например, main.a1b2c3.js), чтобы браузер не кешировал старую версию сайта после обновления.

2. Выбор стратегии размещения

В зависимости от бюджета, нагрузки и требований к безопасности, есть три основных пути.

Вариант А: Статический хостинг (Vercel, Netlify, GitHub Pages)

Это «путь наименьшего сопротивления». Вы подключаете репозиторий, и сервис сам собирает проект и раздает его через CDN.

    • Плюсы: Бесплатно (на старте), автоматический SSL, атомарные деплои (легкий откат).
    • Минусы: Ограниченный контроль над конфигурацией сервера, зависимость от стороннего сервиса

Вариант Б: Свой VPS/VDS (Ubuntu + Nginx)

Классический подход. Вы арендуете «виртуальный компьютер», ставите туда Linux и настраиваете всё руками.

    • Плюсы: Полный контроль, возможность поставить рядом БД или бэкенд, отсутствие лимитов платформы.
    • Минусы: Нужно уметь администрировать Linux, настраивать безопасность и обновлять софт.

Вариант В: Контейнеризация (Docker + Kubernetes)

Стандарт для крупных энтерпрайз-проектов. Приложение упаковывается в образ, который идентичен во всех средах.

    • Плюсы: Изоляция, легкое масштабирование.
    • Минусы: Высокий порог входа, избыточность для маленьких проектов.

3. Практический разбор: Деплой на VPS через Nginx

Разберем самый гибкий вариант — установку на свой сервер. Допустим, у нас есть чистый сервер на Ubuntu.

Шаг 1: Подготовка сервера

Первым делом обновляем пакеты и ставим Nginx — самый быстрый и надежный сервер для раздачи статики.

bash
sudo apt update
sudo apt install nginx -y

Шаг 2: Перенос файлов на сервер

Есть два пути: либо собирать проект локально и кидать файлы через scp или rsync, либо собирать прямо на сервере (что не рекомендуется, так как сборка ест много оперативной памяти и может «положить» сервер).

Оптимальный вариант: сборка в CI/CD (об этом ниже), но для ручного теста используйте scp:
bash
scp -r ./dist/* user@your_server_ip:/var/www/my-app

Шаг 3: Настройка Nginx (Конфигурация)

Самая большая проблема SPA — это ошибка 404 при перезагрузке страницы. Поскольку роутинг в React/Vue работает на стороне клиента, сервер не знает про ваши пути /about или /profile и ищет такие папки на диске.

Нужно создать конфиг /etc/nginx/sites-available/my-app:

nginx
server {
listen 80;
server_name yourdomain.com www.yourdomain.com;

root /var/www/my-app;
index index.html;

location / {
    try_files $uri $uri/ /index.html;
}

# Кеширование статики для ускорения загрузки
location ~* \.(js|css|png|jpg|jpeg|gif|ico|svg)$ {
    expires 30d;
    add_header Cache-Control "public, no-transform";
}

}

Ключевая строка здесь — try_files $uri $uri/ /index.html;. Она говорит серверу: «Если не нашел файл по этому адресу, просто отдай index.html, а клиентский роутер сам разберется».

После этого создаем симлинк в sites-enabled и перезагружаем сервис:
bash
sudo ln -s /etc/nginx/sites-available/my-app /etc/nginx/sites-enabled/
sudo nginx -t
sudo systemctl restart nginx

4. Безопасность и SSL (HTTPS)

Сайт без замочка в адресной строке в 2024 году — это приговор. Используем Let’s Encrypt и утилиту certbot для получения бесплатного сертификата.

bash
sudo apt install certbot python3-certbot-nginx -y
sudo certbot —nginx -d yourdomain.com -d www.yourdomain.com

Certbot сам изменит конфиг Nginx, добавит редирект с HTTP на HTTPS и настроит автопродление сертификата.

5. Автоматизация: CI/CD пайплайны

Ручной деплой — это путь к ошибкам. Чтобы не заходить на сервер по SSH каждый раз, настраиваем GitHub Actions или GitLab CI.

Логика пайплайна выглядит так:

  1. Trigger: Вы делаете git push в ветку main.
  2. Build: GitHub Actions запускает виртуальную машину, ставит Node.js, делает npm install и npm run build.
  3. Deploy: Сборка (папка dist) переносится на сервер по SSH/SFTP.

Пример упрощенного .github/workflows/deploy.yml:
yaml
name: Deploy Frontend
on:
push:
branches: [ main ]
jobs:
build-and-deploy:
runs-on: ubuntu-latest
steps:

    • uses: actions/checkout@v3
    • name: Install & Build
      run: |
      npm install
      npm run build
    • name: Deploy to Server
      uses: appleboy/scp-action@master
      with:
      host: ${{ secrets.HOST }}
      username: ${{ secrets.USERNAME }}
      key: ${{ secrets.SSH_KEY }}
      source: «dist/*»
      target: «/var/www/my-app»

Все секреты (IP, ключи) хранятся в настройках репозитория (Settings -> Secrets), а не в коде.

6. Чек-лист перед запуском в прод

Прежде чем давать ссылку заказчику, проверьте следующие пункты:

  1. Переменные окружения (.env): Убедитесь, что приложение стучится на продакшн-API, а не на localhost:5000.
  2. Gzip/Brotli сжатие: Включите сжатие в Nginx, чтобы текстовые файлы (JS, CSS) передавались в сжатом виде. Это ускорит загрузку в 2-3 раза.
  3. Анализ размера бандла: Используйте webpack-bundle-analyzer, чтобы увидеть, не прилетает ли в клиентский код огромная библиотека, которую можно вынести в отдельный чанк.
  4. SEO и Meta-теги: Проверьте, что title и description настроены, а для SPA (если нужно) используется SSR (Next.js, Nuxt.js) или пререндеринг.
  5. Очистка кеша: Убедитесь, что при обновлении версии приложения пользователи не видят старую версию из-за агрессивного кеширования браузера (хеширование имен файлов решает эту проблему).

Итог

Деплой фронтенда — это не просто «залить файлы на сервер». Это выстраивание цепочки от коммита в Git до момента, когда пользователь получает оптимизированный контент через HTTPS.

Для пет-проектов идеально подходят Vercel или Netlify. Для коммерческой разработки среднего размера — VPS с Nginx и настроенным CI/CD. Для гигантов — Docker и K8s. Главное — помнить про разделение окружений, оптимизацию сборки и автоматизацию всех рутинных действий.