- Опубликовано: 21 июл 2026
- 9
Как выбрать хостинг для сайта и не купить себе вторую работу
Часть 1 из 14 · Серия «Хостинг без магии»
Сайт готов. Домен зарегистрирован. Осталось выбрать хостинг.
Владелец открывает сравнение тарифов и видит знакомый набор характеристик:
- 20 ГБ диска;
- 4 ГБ оперативной памяти;
- 2 ядра процессора;
- неограниченный трафик;
- бесплатный SSL;
- десятки сайтов и баз данных.
Один тариф стоит недорого, другой — в три раза дороже. У второго меньше гигабайт, зато в описании встречаются слова «управляемый», «резервное копирование» и «техническая поддержка».
Кажется, что первый вариант выгоднее. Особенно если это VPS: собственный сервер, гарантированные ресурсы, полный доступ и возможность установить что угодно.
Через неделю выясняется, что «полный доступ» означает ещё и полную ответственность.
Нужно выбрать операционную систему, установить веб-сервер, настроить PHP, создать базу данных, защитить SSH, выпускать сертификаты, следить за свободным местом и устанавливать обновления безопасности. Затем сайт перестаёт открываться, и поддержка отвечает:
Сервер доступен по сети. Администрирование операционной системы в услугу не входит.
Формально всё честно. Провайдер предоставил виртуальную машину, а не готовую среду для сайта.
Покупатель сравнивал гигабайты и ядра, но не сравнил самое важное:
Кто будет выполнять всю работу между выдачей сервера и открывающимся сайтом?
Правильный выбор хостинга начинается не с объёма диска. Сначала нужно определить, какую часть технических обязанностей вы готовы взять на себя.
Вы выбираете не только сервер, но и границу ответственности
Хостинг — это не просто место, куда загружаются файлы.
Чтобы сайт постоянно работал, кто-то должен:
- обслуживать физическое оборудование;
- следить за сетью и электропитанием;
- обновлять операционную систему;
- настраивать веб-сервер;
- устанавливать PHP и базы данных;
- выпускать и продлевать SSL-сертификаты;
- ограничивать доступ между пользователями;
- настраивать резервное копирование;
- следить за диском, памятью и процессами;
- искать причину аварии;
- восстанавливать данные;
- помогать с доменом, почтой и переносом сайта.
Вопрос не в том, нужны ли эти действия. Они нужны в любом случае.
Вопрос в другом:
Какие задачи выполняет хостинг-провайдер, какие — разработчик, а какие останутся владельцу сайта?
Условно ответственность можно разделить на четыре слоя.
Сайт и его содержимое
↓
CMS или приложение
↓
PHP, база, веб-сервер, почта
↓
Операционная система и безопасность
↓
Виртуализация, сеть и оборудование
На виртуальном хостинге провайдер обычно обслуживает нижние слои вплоть до готовой среды исполнения сайта.
На обычном VPS он отвечает в основном за оборудование, сеть и работу виртуализации. Всё внутри операционной системы становится задачей клиента.
Поэтому тариф с большим количеством ресурсов может требовать гораздо больше самостоятельной работы, чем тариф с меньшими цифрами.
Что означает «управляемый» хостинг
Слово «управляемый» используют по-разному, поэтому его нельзя воспринимать как точный технический термин.
У одного провайдера управление может включать:
- готовую панель;
- установленные PHP и MySQL;
- автоматические обновления серверного ПО;
- SSL-сертификаты;
- резервные копии;
- базовую диагностику;
- перенос сайта.
У другого — только установку панели при заказе.
Поэтому вместо вопроса:
Это управляемый хостинг?
лучше задавать конкретные:
- кто обновляет операционную систему;
- кто исправляет уязвимости веб-сервера;
- кто следит за продлением SSL;
- кто настраивает резервные копии;
- кто восстанавливает сайт;
- кто разбирается с переполненным диском;
- кто помогает при ошибке PHP;
- входит ли перенос сайта;
- где заканчивается ответственность поддержки.
Чем точнее ответы, тем меньше неприятных сюрпризов после оплаты.
Почему дешёвый VPS может оказаться дорогим
Предположим, виртуальный хостинг стоит 10 условных единиц в месяц, а VPS с большим объёмом памяти — 7.
По таблице характеристик VPS выглядит выгоднее.
Но для его работы могут понадобиться:
- первоначальная настройка;
- установка панели;
- лицензия на панель;
- настройка резервных копий;
- внешний сервис мониторинга;
- дополнительное хранилище;
- защита от перебора паролей;
- обновление системы;
- регулярная проверка журналов;
- помощь администратора при аварии.
Даже если не покупать отдельные услуги, работа всё равно имеет стоимость.
Допустим, владелец самостоятельно тратит:
2 часа на первоначальную настройку
1 час в месяц на обновления и проверки
3 часа на одну неожиданную аварию
Если это рабочее время разработчика, предпринимателя или сотрудника, реальная цена VPS быстро становится выше стоимости управляемого хостинга.
При этом результат может оказаться менее надёжным: сервер обслуживается время от времени человеком, для которого администрирование не является основной работой.
Дешёвый VPS выгоден не тогда, когда у него много памяти за небольшую цену. Он выгоден, когда:
- проекту действительно нужен полный контроль;
- есть человек, который умеет его обслуживать;
- стоимость этого обслуживания учтена;
- стандартный хостинг ограничивает необходимую архитектуру.
«Я разработчик, значит справлюсь с сервером»
Разработчик сайта и системный администратор решают связанные, но разные задачи.
Разработчик может прекрасно знать:
- PHP;
- Laravel или Symfony;
- SQL;
- JavaScript;
- Git;
- архитектуру приложения;
- внешние API.
При этом ему необязательно регулярно заниматься:
- настройкой firewall;
- обновлением Linux;
- конфигурацией PHP-FPM;
- ограничением системных пользователей;
- журналами systemd;
- ротацией логов;
- резервным копированием базы;
- восстановлением после повреждения диска;
- безопасной настройкой почтового сервера;
- анализом сетевых атак.
Временно разобраться можно почти во всём. Вопрос — стоит ли превращать обслуживание инфраструктуры в ещё одну обязанность проекта.
Если разработчику нужен Composer, SSH и cron, это не означает, что ему обязательно нужен VPS. Современный виртуальный хостинг может предоставлять инструменты разработки, оставляя обслуживание операционной системы провайдеру.
Полный доступ и полный контроль — не бесплатные преимущества. Они приходят вместе с полной ответственностью.
Начните не с тарифа, а с проекта
Перед сравнением хостингов опишите будущий сайт.
Не нужно составлять техническое задание на двадцать страниц. Достаточно ответить на несколько практических вопросов.
На чём работает сайт
Это может быть:
- статическая страница;
- конструктор сайтов;
- WordPress;
- Joomla;
- Drupal;
- интернет-магазин;
- Laravel;
- Symfony;
- Yii;
- самописная CMS;
- Node.js-приложение;
- Python-приложение.
Фраза «поддерживается PHP» не гарантирует поддержку конкретного приложения.
Проекту могут потребоваться:
- определённая версия PHP;
- конкретные расширения;
- Composer;
- SSH;
- Node.js для сборки;
- cron;
- очереди;
- Redis;
- PostgreSQL;
- отдельная публичная директория;
- символические ссылки;
- постоянно работающие процессы.
Кто будет обслуживать проект
Варианты сильно различаются:
- владелец сайта без технического опыта;
- веб-студия;
- штатный разработчик;
- приходящий специалист;
- отдельный системный администратор;
- небольшая команда разработки;
- большая техническая команда.
Тариф, удобный системному администратору, может быть непригоден владельцу небольшого магазина.
И наоборот: среда, удобная для WordPress, может ограничивать команду, которой нужны консольные команды и собственный процесс деплоя.
Насколько сайт важен для бизнеса
Одно дело — личный блог, который может не открываться несколько часов.
Другое — интернет-магазин, где каждый час простоя означает потерянные заказы.
Определите заранее:
- допустим ли простой;
- как быстро сайт нужно восстановить;
- можно ли потерять изменения за последние сутки;
- есть ли сезонные пики;
- кто заметит аварию;
- кому звонить при проблеме;
- существует ли резервная копия вне основного аккаунта.
Чем критичнее сайт, тем важнее не только ресурсы, но и процессы восстановления.
Какие задачи появятся через полгода
Сайт редко остаётся таким же, каким был в день запуска.
Могут появиться:
- интернет-магазин;
- интеграция с CRM;
- импорт товаров;
- фоновые задания;
- автоматическая отправка писем;
- личный кабинет;
- API;
- несколько языков;
- тестовый поддомен;
- Git-деплой;
- Composer-пакеты;
- frontend-сборка;
- очереди.
Необязательно покупать самый дорогой тариф заранее. Но полезно понимать, можно ли перейти на следующий уровень без полного переезда.
Три ошибки при выборе хостинга
Ошибка №1. Выбирать по объёму диска
Большинство обычных сайтов не используют десятки гигабайт.
Небольшой корпоративный сайт может занимать:
500 МБ файлов
300 МБ базы данных
1 ГБ почты
несколько гигабайт резервных копий
При этом он способен работать медленно на тарифе с 100 ГБ диска, если ему не хватает:
- процессорного времени;
- памяти PHP;
- одновременных процессов;
- операций с диском;
- соединений с базой.
Большой диск не делает обработку PHP быстрее.
Подробно разберём это в третьей статье серии.
Ошибка №2. Покупать «на вырост» без плана роста
Иногда владелец небольшого сайта сразу берёт мощный VPS:
Вдруг через год будет миллион посетителей.
Через год посетителей становится не миллион, а сервер всё это время требует обновлений, резервного копирования и контроля.
Рост лучше планировать по этапам:
запуск
↓
появление реальной нагрузки
↓
измерение ограничений
↓
оптимизация
↓
переход на следующий уровень
Масштабирование должно решать существующую или прогнозируемую по данным проблему, а не абстрактный страх будущего успеха.
Ошибка №3. Считать поддержку универсальной
Техническая поддержка хостинга не всегда является службой разработки сайта.
Она может:
- проверить работу сервера;
- помочь подключить домен;
- показать журнал ошибок;
- исправить владельца файлов;
- объяснить лимит тарифа;
- восстановить копию;
- помочь перенести сайт.
Но обычно она не обязана:
- исправлять код приложения;
- обновлять плагины;
- искать ошибку в SQL-запросе;
- разрабатывать интеграцию;
- восстанавливать взломанную CMS вручную;
- оптимизировать тему WordPress;
- объяснять архитектуру Laravel;
- исправлять чужой deploy-скрипт.
До покупки важно понять, где проходит эта граница.
Как отличить хостинг от аренды инфраструктуры
Полезно мысленно представить первый день после оплаты.
Сценарий A
Вы получаете:
- адрес панели;
- готовый файловый менеджер;
- возможность создать сайт;
- базу данных;
- почтовый ящик;
- выбор версии PHP;
- выпуск SSL;
- резервные копии;
- инструменты переноса.
Можно загрузить проект и заниматься сайтом.
Это услуга, ориентированная на размещение сайтов.
Сценарий B
Вы получаете:
IP-адрес
логин root
пароль или SSH-ключ
Дальше нужно самостоятельно решить:
- какой веб-сервер установить;
- как настроить домены;
- где хранить сайты;
- как выпускать SSL;
- как запускать PHP;
- как создать базу;
- как закрыть лишние порты;
- как делать резервные копии;
- как следить за сервером.
Это инфраструктура, из которой ещё предстоит построить хостинг.
Оба варианта нормальны. Ошибка — купить второй, ожидая получить первый.
Что действительно входит в стоимость хостинга
При сравнении тарифов полезно смотреть на пять групп расходов.
1. Ресурсы
- дисковое пространство;
- память;
- процессор;
- количество процессов;
- базы данных;
- почта;
- трафик.
2. Программная среда
- панель управления;
- версии PHP;
- PHP-расширения;
- MySQL или PostgreSQL;
- Composer;
- Git;
- Node.js;
- cron;
- SSH;
- Redis;
- управление фоновыми процессами.
3. Обслуживание
- обновление серверного ПО;
- установка исправлений безопасности;
- мониторинг узлов;
- замена оборудования;
- борьба с сетевыми проблемами;
- изоляция аккаунтов.
4. Защита данных
- резервные копии;
- срок хранения;
- частота создания;
- возможность самостоятельного восстановления;
- внешнее расположение копий;
- копирование баз и почты.
5. Помощь
- перенос сайта;
- помощь с доменом;
- диагностика ошибок;
- поддержка по почте или в чате;
- время реакции;
- работа в выходные;
- платное администрирование.
Тариф нельзя считать дорогим или дешёвым, пока неизвестно, что из этого включено.
Первая развилка: сайт или сервер
Задайте себе один вопрос:
Я хочу управлять сайтом или сервером?
Хочу управлять сайтом
Вам важнее:
- удобная панель;
- готовые версии PHP;
- базы данных;
- SSL;
- почта;
- резервные копии;
- перенос;
- диагностика;
- понятные лимиты;
- возможность быстро увеличить тариф.
В этом случае логично сначала рассматривать виртуальный или другой управляемый хостинг.
Хочу управлять сервером
Вам нужны:
- root-доступ;
- собственная конфигурация;
- системные пакеты;
- нестандартные сервисы;
- отдельный веб-сервер;
- Docker;
- собственная сеть;
- постоянные фоновые процессы;
- полный контроль над безопасностью.
В этом случае VPS или облачный сервер могут быть правильным выбором.
Хочу инструменты разработчика, но не хочу администрировать Linux
Это промежуточный сценарий, который часто упускают.
Проекту нужны:
- SSH;
- Composer;
- Git;
- cron;
- Node.js;
- выбор PHP;
- отдельный Document Root;
- логи.
Но не нужны:
- root;
- собственный nginx;
- Docker;
- системные демоны;
- настройка firewall;
- ручное обновление Linux.
Такой проект может работать на современном виртуальном хостинге с инструментами для разработчиков.
На Siteko под этот сценарий выделены тарифы Master и Expert с SSH, Composer, Git и Node.js; подробно эти инструменты разобраны в восьмой статье серии. Тарифы Start и Optima ориентированы на сайты на CMS, которым консольные инструменты не нужны.
Выбирайте по самому сложному обязательному требованию
Предположим, сайту нужны:
- PHP;
- база данных;
- SSL;
- почта;
- 5 ГБ диска.
Эти условия выполняют почти все PHP-хостинги.
Но дополнительно требуется один постоянно работающий WebSocket-сервер.
Именно он становится определяющим требованием. Можно найти тариф с 100 ГБ диска, но без фоновых процессов проект всё равно не заработает.
Другие примеры определяющих требований:
| Проект | Критичное требование |
|---|---|
| Обычный WordPress | Совместимая версия PHP и удобное восстановление |
| WooCommerce | Производительность PHP, база, cron и почта |
| Laravel | SSH, Composer, public, cron и PHP-расширения |
| Symfony | Composer, консоль, public, права на runtime-каталоги |
| Старый PHP-сайт | Поддержка необходимой старой версии PHP |
| Фотоархив | Диск, inode и резервное копирование |
| Почтовый домен | Лимиты почты, репутация отправки и DNS-записи |
| Приложение с Horizon | Redis и постоянные workers |
| SSR на Node.js | Постоянно работающий Node-процесс |
| Docker-проект | Контроль операционной системы |
Не начинайте с поиска тарифа, который «в целом мощный». Найдите требование, без которого проект не работает вообще.
Разделяйте обязательное и желательное
Составьте две колонки.
Обязательно
Без этого проект не работает или становится небезопасным:
PHP 8.x
MySQL
SSL
cron
Composer
корень домена на public
ежедневные резервные копии
Желательно
Это удобно, но можно решить иначе:
Node.js на сервере
GitHub-импорт из панели
Redis
тестовый поддомен
почта на том же хостинге
автоматический deploy
Например, Node.js не всегда должен работать на хостинге. Frontend можно собрать локально или в CI и загрузить готовые файлы.
Redis, напротив, нельзя заменить одной установленной PHP-библиотекой, если приложение требует именно постоянно работающий Redis-сервер.
Такое разделение не позволяет одной красивой, но необязательной функции заставить купить слишком сложную инфраструктуру.
Попросите разработчика составить требования
Владелец сайта не обязан знать, что такое intl, symlink или worker.
Если проект разрабатывал специалист, попросите его заполнить короткий список:
Язык и версия:
Фреймворк или CMS:
База данных:
Необходимые расширения:
Нужен ли SSH:
Нужен ли Composer:
Нужен ли Node.js:
Нужен ли cron:
Минимальный интервал cron:
Нужны ли очереди:
Нужны ли постоянные процессы:
Нужен ли Redis:
Нужен ли PostgreSQL:
Корневая папка сайта:
Примерный объём файлов:
Примерный объём базы:
Как выполняется деплой:
Это гораздо полезнее запроса:
Посоветуйте самый лучший хостинг.
Лучшего хостинга для всех проектов не существует. Есть услуга, которая соответствует конкретному набору требований и ответственности.
Проверьте возможность переезда до покупки
Хостинг выбирают не навсегда.
Проект может:
- перерасти тариф;
- сменить разработчика;
- перейти на другой стек;
- получить новые требования;
- столкнуться с ограничением;
- переехать в другую страну;
- изменить бюджет.
Поэтому заранее выясните:
- можно ли скачать все файлы;
- можно ли экспортировать базу;
- можно ли получить резервную копию;
- можно ли перенести почту;
- остаётся ли домен под вашим контролем;
- предоставляется ли SSH или SFTP;
- можно ли изменить DNS;
- есть ли ограничения на выгрузку данных;
- как отменяется услуга;
- сколько хранятся данные после окончания тарифа.
Удобный вход не должен сопровождаться невозможным выходом.
Домен, репозиторий, резервные копии и доступы лучше хранить под контролем владельца проекта, а не только подрядчика.
Проверьте поддержку до аварии
Необязательно специально ломать сайт. Достаточно задать несколько вопросов до оплаты.
Например:
Можно ли назначить папку
publicкорнем домена?
Совпадает ли версия PHP в браузере и SSH?
Какой минимальный интервал cron?
Есть ли постоянные фоновые процессы?
Что входит в резервную копию?
Могу ли я самостоятельно восстановить базу?
Помогаете ли вы перенести сайт?
Где находятся PHP-логи?
Что произойдёт при превышении лимита ресурсов?
По качеству ответа можно многое понять.
Хороший ответ конкретен:
Cron можно запускать раз в минуту.
Постоянные процессы на тарифе не поддерживаются.
Корень домена можно изменить в панели.
PHP-лог находится в таком-то разделе.
Плохой ответ состоит из общих обещаний:
Поддерживается всё.
Хостинг очень мощный.
Обычно проблем не бывает.
Честное ограничение полезнее неограниченного маркетингового обещания.
Красные флаги в описании тарифа
«Неограниченные ресурсы»
Физически неограниченных процессора, памяти и диска не существует.
Обычно ограничение просто описано в другом месте:
- правила допустимой нагрузки;
- процессорное время;
- количество процессов;
- inode;
- размер базы;
- лимиты почты;
- ограничения ввода-вывода.
Этому будет посвящена четвёртая статья серии.
Указан только объём диска
Для динамического сайта важны также:
- CPU;
- память;
- процессы;
- PHP-лимиты;
- база;
- диск;
- число файлов.
Если сравнение тарифов почти полностью состоит из гигабайт и числа сайтов, информации недостаточно.
«Полная поддержка» без границ
Нужно понимать, включает ли она исправление:
- серверной конфигурации;
- CMS;
- плагинов;
- кода;
- базы;
- взлома;
- почты;
- DNS.
Нет описания резервных копий
Фраза «делаем бэкапы» не отвечает на вопросы:
- как часто;
- сколько хранятся;
- где находятся;
- что именно копируется;
- как восстановить;
- можно ли скачать;
- гарантируется ли успешность копирования.
Нельзя найти технические лимиты
Если они отсутствуют на странице тарифа, запросите их у поддержки до оплаты.
Когда самый дешёвый тариф — правильный выбор
Не каждому сайту нужны SSH, Composer и отдельный сервер.
Недорогой базовый тариф может быть оптимален, если:
- используется обычная CMS;
- сайт небольшой;
- нет нестандартных фоновых задач;
- обновления выполняются через панель CMS;
- почта и база укладываются в лимиты;
- не требуется собственная конфигурация;
- проект можно быстро восстановить;
- провайдер обслуживает серверную среду.
Покупать VPS для сайта-визитки только ради «запаса мощности» — всё равно что приобретать грузовик для поездок в магазин.
Избыточная инфраструктура не делает сайт автоматически быстрее или надёжнее. Иногда она лишь добавляет места, где можно допустить ошибку.
Когда нужно смотреть выше базового тарифа
Более функциональный виртуальный хостинг нужен, когда появляются:
- несколько сайтов;
- интернет-магазин;
- повышенная нагрузка;
- большой объём почты;
- Composer;
- Git;
- SSH;
- cron каждую минуту;
- frontend-сборка;
- тестовое окружение;
- отдельная публичная директория;
- более высокие лимиты процессов.
Переход на старший тариф внутри той же управляемой среды часто проще, чем преждевременный переезд на VPS.
Когда VPS действительно оправдан
VPS имеет смысл, когда ограничением является не только размер тарифа, но и сама модель виртуального хостинга.
Например, проекту нужны:
- root-доступ;
- собственные системные пакеты;
- Docker;
- постоянные workers;
- Supervisor;
- Laravel Horizon;
- WebSocket-сервер;
- Redis-сервер;
- Elasticsearch или Meilisearch;
- нестандартная конфигурация nginx;
- собственные правила сети;
- специальная версия базы;
- несколько изолированных сервисов;
- системный демон;
- предсказуемо высокая нагрузка.
Но даже тогда нужно решить, кто будет администрировать сервер:
- собственный специалист;
- веб-студия;
- системный администратор;
- платная услуга провайдера;
- внешний подрядчик.
Фраза «возьмём VPS» без ответа на этот вопрос — незаконченный план.
Минимальный чек-лист перед оплатой
О проекте
- Какая CMS или какой фреймворк используется?
- Какие версии языка и базы нужны?
- Нужны ли SSH, Composer, Git и Node.js?
- Нужны ли cron, очереди или постоянные процессы?
- Сколько занимают файлы, база и почта?
- Есть ли пользовательские загрузки?
- Как выполняется обновление сайта?
О тарифе
- Какие реальные лимиты CPU, памяти и процессов?
- Есть ли ограничение количества файлов?
- Можно ли менять версию PHP?
- Где находятся логи?
- Можно ли назначить произвольный Document Root?
- Какие базы и расширения доступны?
- Как увеличивается тариф?
Об обслуживании
- Кто обновляет серверное ПО?
- Кто следит за SSL?
- Кто диагностирует сбои?
- Входит ли перенос сайта?
- Где заканчивается ответственность поддержки?
О данных
- Как часто создаются копии?
- Сколько они хранятся?
- Что входит в копию?
- Можно ли восстановиться самостоятельно?
- Можно ли скачать копию отдельно?
- Кто отвечает за проверку восстановления?
О переезде
- Можно ли выгрузить все файлы и базы?
- Есть ли SFTP или SSH?
- Можно ли перенести почту?
- Остаётся ли домен под контролем владельца?
- Что происходит с данными после окончания услуги?
Если на несколько критичных вопросов нет ответа, покупать тариф рано.
Грабли при выборе хостинга
| Грабля | Что происходит | Как избежать |
|---|---|---|
| Выбор только по цене | Дешёвая услуга требует дорогого администрирования | Считать стоимость владения, а не абонентскую плату |
| Выбор только по диску | Места много, а сайт упирается в CPU или процессы | Проверять все ресурсные лимиты |
| VPS покупается «на вырост» | Сервер простаивает, но требует обслуживания | Масштабироваться по реальным данным |
| Root воспринимается как бонус | Владелец неожиданно становится администратором | Заранее определить ответственного за сервер |
| «Поддержка PHP» считается достаточной | Проекту не хватает Composer, cron или расширения | Составить требования приложения |
| Поддержка воспринимается как разработчик | Провайдер не исправляет код и плагины | Уточнить границы помощи |
| Бэкап считается автоматической гарантией | При аварии копия оказывается старой или неполной | Проверять состав и восстановление |
| Домен оформлен на подрядчика | Владелец теряет контроль над адресом сайта | Регистрировать домен на владельца проекта |
| Все доступы знает один человек | После его ухода сайт невозможно обслуживать | Хранить доступы в контролируемом месте |
| Тариф выбирается без учёта роста | Любая новая функция требует переезда | Проверить возможности повышения тарифа |
| «Безлимит» принимается буквально | Сайт блокируется по скрытому ограничению | Читать правила нагрузки |
| Сначала покупается тариф, потом спрашивают разработчика | Среда не соответствует проекту | Получить технические требования заранее |
Какой выбор обычно разумен
Небольшой сайт на CMS
Начните с управляемого виртуального хостинга.
Проверьте:
- совместимость PHP;
- резервные копии;
- SSL;
- почту;
- возможность восстановления;
- лимиты процессов;
- поддержку переноса.
Интернет-магазин
Смотрите не только на диск.
Важны:
- производительность PHP;
- база данных;
- cron;
- почта;
- резервные копии;
- логи;
- возможность увеличить ресурсы;
- помощь при переносе.
Laravel, Symfony или другой PHP-фреймворк
Ищите виртуальный хостинг для разработчиков либо управляемый сервер.
Минимально могут понадобиться:
- SSH;
- Composer;
- Git;
- cron;
- выбор PHP;
- необходимые расширения;
publicкак корень домена;- Node.js для сборки;
- символические ссылки;
- доступ к логам.
Подробно эти требования разобраны в восьмой статье серии.
Приложение с собственными сервисами
Если нужны Redis, постоянные workers, WebSocket, Docker или системные пакеты, рассматривайте VPS.
Но одновременно выбирайте способ его администрирования.
Как это устроено на Siteko
Для простых сайтов на CMS предусмотрены тарифы Start и Optima: панель, выбор версии PHP, базы данных, почта, SSL и резервные копии — без консоли, которая таким сайтам не нужна.
Для проектов, которым нужны консольные инструменты, выделены Master и Expert:
- SSH;
- глобальный Composer;
- Git;
- Node.js через nvm;
- cron;
- произвольный Document Root;
- символические ссылки;
- окружение для современных PHP-фреймворков.
Постоянные worker-процессы, Supervisor, Laravel Horizon и отдельный Redis-сервер на виртуальном хостинге мы сознательно не обещаем: такие задачи честнее решать на VDS, и мы прямо говорим об этом до покупки, а не после.
А перенос сайта с текущего хостинга поддержка выполняет за клиента под ключ — файлы, базу и проверку работы, — а не ограничивается подсказками.
Разделение выглядит так:
обычный сайт на CMS
↓
управляемый виртуальный хостинг
современный PHP-проект
↓
виртуальный хостинг с инструментами разработчика
собственные постоянные сервисы
↓
VDS
Выбирается не самый «мощный» вариант, а минимально достаточная среда, которая поддерживает обязательные функции проекта.
Что в итоге
Выбор хостинга — это выбор не только характеристик, но и обязанностей.
Диск, процессор и память важны. Но до них нужно определить:
- кто обслуживает операционную систему;
- кто обновляет сервер;
- кто настраивает SSL;
- кто делает копии;
- кто восстанавливает сайт;
- кто следит за безопасностью;
- кто разбирается с аварией;
- кто отвечает за код приложения.
Для большинства обычных сайтов разумная отправная точка — управляемый виртуальный хостинг. Он позволяет заниматься сайтом, а не превращать владельца или разработчика в системного администратора.
VPS нужен не потому, что он выглядит мощнее или дешевле по таблице. Он нужен, когда проекту действительно необходимы полный контроль, собственные сервисы или нестандартная конфигурация — и есть человек, готовый за них отвечать.
Главный принцип первой статьи можно сформулировать так:
Покупайте не максимум серверных возможностей, а минимально достаточную среду с понятной границей ответственности.
Теперь остаётся разобраться, где именно проходит эта граница между виртуальным хостингом, VPS и облаком.
В следующей части сравним эти варианты по конкретным сценариям: сайт-визитка, WordPress, интернет-магазин, Laravel-приложение, API и несколько сайтов.
Была статья полезной:
