Где разместить готовый сайт из архива или GitHub

Перед началом

Сайт уже готов: разработчик прислал архив или ссылку на GitHub. Теперь хочется получить простой результат — сайт открывается по вашему домену, страницы работают, заявки доходят. Но одинаковые снаружи сайты могут требовать разного размещения. Одному достаточно папки с файлами. Другому нужны PHP и база данных. Третьему — постоянно работающая программа.

Начните с устройства проекта. Так вы избежите покупки сервера, который некому обслуживать, или тарифа, на котором сайт вообще не запустится.

Что именно вам передали

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

Если видите package.json, это ещё не повод покупать VPS. JavaScript может использоваться только для сборки: программа создаёт готовые HTML, CSS и JS, после чего сервер Node.js сайту не нужен. Найдите README и инструкции сборки. Названия dist и build встречаются часто, но правильную папку нужно установить по настройкам именно вашего проекта.

Файлы wp-config.php, папки wp-content и wp-admin указывают на WordPress. Для обычной установки понадобятся совместимые версии PHP и базы данных. Перенос только файлов без базы обычно не восстановит такой сайт.

Если проект обрабатывает запросы на сервере, авторизует пользователей, выполняет фоновые задачи или работает с собственной базой, потребуется соответствующая среда выполнения. Наличие красивой главной страницы об этом ничего не говорит.

Не удалось определить? Отправьте разработчику четыре вопроса:
— Какой командой собирается проект и какую папку публиковать?
— Должен ли после сборки постоянно работать серверный процесс?
— Куда отправляется форма заявки и кто оплачивает этот сервис?
— Какие база данных и переменные окружения нужны для запуска?
Ответ «всё лежит на GitHub» эти вопросы не закрывает.

Три подходящих пути

Путь А: статический хостинг или обычный хостинг с публикацией файлов

Подходит для лендинга, портфолио, небольшой витрины без собственной серверной логики. Статическая площадка может обновлять сайт из Git или принимать готовую папку. Обычный хостинг удобен, если вы хотите работать через файловый менеджер и получать поддержку по домену и размещению в одном кабинете.

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

Бесплатный вариант может закрыть задачу. Но бесплатность не отменяет правил: GitHub Pages ограничивает использование для онлайн-бизнеса, электронной торговли и сайтов, преимущественно обслуживающих коммерческие операции или SaaS. Поэтому его нельзя рекомендовать как универсальное бесплатное размещение коммерческого проекта. Ограничения описаны в официальной документации [1].

Cloudflare Pages документирует публикацию статического HTML из репозитория [2]. Это пример другого способа размещения, а не подтверждение доступности, оплаты и пригодности сервиса для конкретного российского бизнеса. Эти условия нужно проверить перед выбором.

Путь Б: обычный хостинг для PHP/CMS

Подходит, если у сайта есть совместимая CMS и база данных, а постоянные отдельные процессы ему не нужны. Сравнивайте не только объём диска. Нужны подходящие версии PHP и базы, достаточные ограничения ресурсов, резервное копирование с понятным восстановлением и доступ к журналам ошибок.

Спросите, включены ли почта, HTTPS и резервные копии, за какой период указана цена и сколько стоит продление. Надпись «в месяц» может означать месячный эквивалент при оплате сразу за год. Запишите полную сумму заказа до регистрации и сравнивайте предложения за одинаковый период.

Для небольшого совместимого сайта это разумный первый вариант. Переход на VPS оправдан требованиями проекта или измеренными ограничениями, а не самим фактом коммерческого использования.

Путь В: платформа приложений или VPS

Подходит, если нужен постоянный Node.js/Python-процесс, собственное окружение, контейнеры или специальные службы. Платформа приложений берёт часть задач эксплуатации на себя, но имеет собственные ограничения и правила тарификации. VPS даёт больше контроля, вместе с которым появляются обновления, настройка доступа, перезапуск процессов и восстановление.

До покупки ответьте: кто будет обслуживать сервер? Если ответственного нет, сравните управляемую платформу и услугу администрирования. Дешёвая виртуальная машина может оказаться дорогим способом содержать простой лендинг.

Что записать в сравнении двух тарифов

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

Не складывайте годовую цену со стоимостью месячного дополнения: сначала приведите всё к одному периоду. Бесплатный бонус считайте временной скидкой, а не постоянной ценой.

Пример выбора

Допустим, у вас лендинг из готовых HTML-файлов, один домен и форма обращения. Личного кабинета и базы нет. Начальная развилка — статическая площадка или обычный хостинг, а не характеристики VPS. Затем выясняем, где работает форма. Если её обработчик остался в аккаунте разработчика, смена хостинга эту зависимость не устранит.

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

Следующий шаг

Если у вас готовая папка HTML, переходите к инструкции «Как опубликовать HTML-сайт на своём домене и проверить заявки». Если требуется CMS или серверная программа, сначала получите список требований от разработчика и только потом выбирайте тариф.

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