Хостинг для сайта и CRM: виртуальный хостинг, VPS или облако — что выбрать

Сайт готов, и подрядчик спрашивает: «Где будем размещать?» Для многих владельцев бизнеса это вопрос, на который хочется ответить «где дешевле». А потом оказывается, что выбранный тариф не поддерживает нужную версию Node.js, сайт падает в пиковые дни, резервные копии хранятся на том же диске, что и сам сайт, а доступ к панели оформлен на личную почту бывшего сотрудника подрядчика. Выбор площадки определяет скорость, надёжность, безопасность и то, насколько легко потом сменить исполнителя. Разберём варианты без жаргона и с критериями, по которым их сравнивать.

Четыре основных варианта размещения

Названия у провайдеров отличаются, но по сути вариантов четыре. Они различаются тем, сколько ресурсов принадлежит именно вам и кто отвечает за настройку сервера.

• Виртуальный (shared) хостинг — на одном сервере живут сотни сайтов разных клиентов. Провайдер обслуживает сервер, вы получаете папку, базу данных и панель управления. Просто и недорого, но ресурсы общие, а набор технологий ограничен тем, что поставил провайдер.
• VPS/VDS — виртуальный сервер с гарантированной долей процессора, памяти и диска. Вы получаете полный доступ и можете установить что угодно, но и настраивать, обновлять и защищать его должен кто-то с вашей стороны.
• Выделенный сервер — целая физическая машина только под ваши задачи. Максимум ресурсов и контроля, но и максимум ответственности за обслуживание.
• Облачная платформа — набор управляемых сервисов: серверы, которые можно увеличить за минуты, управляемые базы данных, объектное хранилище для файлов, балансировщики. Гибко, но архитектуру и расходы нужно продумывать, иначе счёт растёт незаметно.

Виртуальный хостинг: когда он уместен

Виртуальный хостинг исторически рассчитан на сайты на PHP — WordPress, Битрикс, самописные CMS. Для небольшого сайта-визитки на такой платформе его часто достаточно. Ограничения становятся заметны, когда сайт растёт или построен на другом стеке.

• Подходит: статический сайт или небольшая CMS на PHP, невысокая посещаемость, нет тяжёлых фоновых задач.
• Не подходит: сайты и приложения, которым нужен постоянно работающий процесс Node.js, очереди, фоновые обработчики, собственные сервисы. Часть провайдеров предлагает поддержку Node.js и на виртуальном хостинге, но с ограничениями — уточняйте заранее.
• Риск соседей: если на том же сервере другой сайт создаёт нагрузку или попадает под атаку, это может сказаться и на вас.
• Ограниченная гибкость: нельзя поставить нужную версию базы данных, настроить веб-сервер под себя, установить средства защиты.

VPS: золотая середина для большинства бизнес-проектов

Для сайта на Next.js, интернет-магазина с интеграциями или небольшой CRM виртуальный сервер — обычно самый разумный выбор. Вы получаете предсказуемые ресурсы и полный контроль над окружением. Цена этого контроля — администрирование: обновления системы, настройка файрвола, резервные копии, мониторинг. Если этим никто не занимается, VPS через год превращается в сервер с устаревшим ПО и открытыми портами.

• Процессор: для небольшого сайта хватает 1–2 ядер, для CRM с несколькими десятками пользователей и фоновыми задачами — от 2–4. Главное — понимать, что ядра на VPS бывают гарантированными и разделяемыми, а это разные вещи.
• Оперативная память: сборка проекта на Next.js сама по себе требовательна к памяти. На сервере с 1 ГБ сборка может не пройти, хотя готовый сайт там бы работал. Закладывайте запас или собирайте проект в другом месте.
• Диск: SSD или NVMe — обязательно. Смотрите не только объём, но и есть ли ограничения на скорость операций.
• Сеть: какая полоса, считается ли трафик, есть ли базовая защита от DDoS на стороне провайдера.

Выделенный сервер и облако: для кого

Выделенный сервер оправдан, когда нагрузка стабильно высокая и предсказуемая, есть требования к изоляции или нужно много ресурсов за фиксированную цену. Для типичного сайта малого бизнеса это избыточно. Облако интересно в другом случае: нагрузка резко меняется (сезонность, акции, рассылки), нужны управляемые сервисы, которые не хочется администрировать самостоятельно, или система состоит из нескольких частей.

• Управляемая база данных снимает с вас обновления, репликацию и резервное копирование базы, но стоит дороже, чем база на собственном VPS.
• Объектное хранилище удобно для фотографий, документов и резервных копий: файлы не занимают диск сервера и переживают его пересоздание.
• Автомасштабирование помогает пережить пиковую нагрузку, но требует, чтобы приложение было к этому готово: без хранения файлов и сессий на локальном диске.
• Риск облака — непрозрачный счёт. Ставьте лимиты и уведомления о расходах с первого дня.

Условный пример: три проекта — три решения

Условные примеры для иллюстрации логики выбора, не реальные кейсы.

• Сайт-визитка юридической компании на статической генерации: несколько десятков страниц, форма заявки. Подойдёт и недорогой VPS, и площадка для статических сайтов. Главное — чтобы форма отправляла заявки надёжно и были резервные копии.
• Интернет-магазин на Next.js с каталогом в несколько тысяч товаров, оплатой и интеграцией с учётной системой: VPS с запасом по памяти, отдельная база данных, файлы товаров в объектном хранилище, мониторинг доступности и ежедневные копии в другое место.
• CRM для компании с филиалами, где работают сотрудники и хранятся данные клиентов: сервер в российском дата-центре, разграничение доступа к серверу, база данных с регулярными копиями и проверкой восстановления, журналирование входов. Если нагрузка заметно меняется в течение года — облачная платформа с управляемой базой.

Где физически стоит сервер: 152-ФЗ

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

Что проверить у провайдера до заключения договора

• Где находится дата-центр и можно ли выбрать конкретный.
• Что входит в тариф: гарантированные или разделяемые ресурсы, ограничения на трафик и операции с диском.
• Есть ли резервное копирование на стороне провайдера, где хранятся копии, сколько дней и сколько стоит восстановление.
• Какой уровень доступности обещан в договоре (SLA) и что вы получаете при его нарушении.
• Есть ли базовая защита от DDoS и что происходит с сервером при атаке — фильтрация или отключение от сети.
• Как работает поддержка: каналы, время ответа, работает ли она ночью и в выходные.
• Можно ли сделать снимок (snapshot) сервера перед обновлением и быстро откатиться.
• Как оформляется аккаунт: на юрлицо, с закрывающими документами, с возможностью добавить нескольких пользователей с разными правами.
• Насколько просто уехать: можно ли выгрузить образ диска, базу и файлы.

Администрирование: кто будет обслуживать сервер

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

Кому принадлежит аккаунт хостинга

Самая болезненная проблема с хостингом связана не с технологиями, а с владением. Подрядчик покупает сервер на свой аккаунт «для удобства», через два года отношения заканчиваются — и выясняется, что у компании нет доступа к серверу, на котором работает её сайт и лежит клиентская база. Аккаунт у провайдера, как и домен, должен быть оформлен на компанию, а исполнителю выдаётся отдельный доступ. Подробный список того, что должно быть у владельца на руках, — в статье о приёмке веб-проекта.

Минимальная настройка сервера после покупки

VPS «из коробки» не готов к работе с реальными данными. Даже если администрирование берёт на себя подрядчик, полезно знать, что должно быть сделано в первые дни:

• Обновлена операционная система, включены автоматические обновления безопасности.
• Вход по SSH только по ключам, вход под root по паролю отключён.
• Файрвол открывает только нужные порты: веб (80 и 443) и SSH, причём SSH желательно ограничить по адресам.
• База данных не доступна из интернета напрямую — только с самого сервера или из внутренней сети.
• Настроен HTTPS с автоматическим продлением сертификата.
• Резервные копии базы и файлов уходят на другую площадку, а не лежат на том же сервере.
• Настроен мониторинг доступности и уведомление, если сайт перестал отвечать или заканчивается место на диске.
• Пароли и ключи доступа хранятся в менеджере паролей компании, а не в переписке.

Расположение сервера и скорость сайта

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

• Время ответа сервера (TTFB) зависит от того, насколько загружен сервер и насколько тяжёлые запросы к базе выполняются при открытии страницы.
• Статические файлы — картинки, скрипты, шрифты — разумно отдавать с кэшированием на длительный срок, а при широкой географии аудитории — через CDN.
• Страницы, которые не меняются каждую минуту, лучше генерировать заранее или кэшировать: тогда даже скромный сервер выдерживает заметную нагрузку.
• Измеряйте результат после переезда: Core Web Vitals в отчётах поисковых систем и время ответа в мониторинге — до и после.

Как переехать на другой хостинг без простоя

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

• Заранее снизьте время жизни DNS-записей (TTL) до нескольких минут — за сутки-двое до переезда, чтобы переключение разошлось быстро.
• Разверните проект на новом сервере по инструкции и проверьте его по временному адресу или через локальную подмену адреса в файле hosts.
• Перенесите базу и файлы. Для сайтов, где данные постоянно меняются (заказы, заявки, записи), запланируйте короткое окно, когда приём изменений приостановлен, и сделайте финальную синхронизацию.
• Переключите DNS на новый адрес и проверьте формы, оплату, отправку писем, интеграции с CRM и учётной системой.
• Не удаляйте старый сервер сразу: оставьте его на несколько дней как запасной вариант для отката.
• После переезда убедитесь, что резервные копии и мониторинг настроены уже на новой площадке, а не остались на старой.

Типичные ошибки при выборе

• Выбор только по цене. Разница в стоимости тарифов обычно несопоставима с потерями от простоя сайта в сезон.
• Сервер «впритык». Сайт работает, пока не наступает пик посещаемости или пока не нужно пересобрать проект.
• Резервные копии только средствами того же провайдера. Если проблема с аккаунтом или дата-центром, копии недоступны вместе с сервером.
• Сайт, база, почта и CRM на одном небольшом сервере без разделения. Одна проблема роняет всё.
• Никто не отвечает за обновления. Сервер настроили при запуске и забыли.
• Нет плана переезда. Когда провайдер повышает цены или меняет условия, переезд превращается в проект на несколько недель.

Сравнение: что выбрать

• Небольшой сайт на PHP-CMS без интеграций — виртуальный хостинг, при условии нормальных резервных копий.
• Сайт или магазин на Next.js, сайт с интеграциями и формами — VPS с запасом по памяти и администрированием.
• CRM, ERP, личный кабинет с данными клиентов — VPS или облако в российском дата-центре, отдельная база, резервные копии вне основной площадки.
• Проект с резкими пиками нагрузки или из нескольких сервисов — облачная платформа с лимитами расходов.
• Стабильно высокая нагрузка и особые требования к изоляции — выделенный сервер.

Вывод и следующий шаг

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