Сколько на самом деле стоит бесплатный хостинг

MAATRIX

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

Реклама провайдера — вы платите доверием посетителей

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

Для посетителя это выглядит так: он зашёл на ваш сайт, а поверх контента — баннер стороннего бренда, часто вообще не связанного с вашей тематикой, иногда откровенно низкого качества (мигающая графика, сомнительные офферы). Это моментально считывается как «сайт на бесплатном хостинге» — то есть проект без серьёзных вложений, а значит, и без серьёзных обязательств перед пользователем. Для интернет-магазина, лендинга услуги или любого сайта, где решение о доверии принимается за секунды, это прямой удар по конверсии: посетитель уходит, не оставив заявку, просто потому что общее впечатление «несерьёзно».

Есть и техническая сторона: сторонний баннер — это дополнительный HTTP-запрос к чужому серверу, чужой JavaScript, который выполняется в контексте вашей страницы. Он замедляет загрузку (a значит, ухудшает Core Web Vitals и позиции в поиске) и теоретически может быть вектором для рекламных трекеров, о которых вы ничего не знаете и на которые не давали согласия ни вы, ни ваши посетители.

Лимиты ресурсов бьют именно в момент роста

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

Типичные ограничения бесплатных и условно-бесплатных планов:

• Лимит запросов или трафика в месяц — после исчерпания сайт либо отдаёт ошибку, либо принудительно тормозится провайдером.
• Лимит одновременных подключений/воркеров — при всплеске посетителей часть из них просто не достучится до сайта, получив таймаут.
• «Усыпление» бесплатных контейнеров — многие бесплатные PaaS-платформы останавливают неактивное приложение и поднимают его заново по первому запросу, из-за чего первый посетитель после паузы видит сайт, загружающийся 10-30 секунд (порядок цифр у разных платформ отличается, уточняйте у конкретного провайдера).
• Ограничение по CPU-времени или памяти — при превышении процесс просто убивается посреди работы, что для базы данных иногда означает повреждённые записи.

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

Без бэкапов и поддержки — одна ошибка стоит дороже всей экономии

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

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

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

Настроить собственные бэкапы на VPS — не такая уж большая работа. Базовый вариант на большинстве Linux-дистрибутивов:

# простой ежедневный дамп базы + архив файлов, хранить 7 копий
0 3 * * * /usr/bin/mysqldump -u backup_user -p'PASS' mydb | gzip > /backup/db_$(date +\%F).sql.gz
0 3 * * * tar czf /backup/files_$(date +\%F).tar.gz /var/www/mysite
0 4 * * * find /backup -mtime +7 -delete

Это не серьёзное production-решение (для него стоит смотреть на borgbackup или готовый инструмент вроде Duplicati), но даже такой минимум невозможен на площадке, где у вас нет ни cron, ни shell-доступа, ни прав на запись за пределами публичной директории сайта — а это стандартное ограничение бесплатных тарифов.

Нестабильность: бесплатные ресурсы почти всегда переподписаны

Экономика бесплатного хостинга работает только за счёт того, что провайдер продаёт (или раздаёт) сильно больше виртуальных ресурсов, чем физически есть на сервере, рассчитывая, что не все пользователи одновременно упрутся в пик нагрузки. Это нормальная практика и на платных тарифах тоже — но на бесплатных коэффициент переподписки обычно кратно выше, потому что средний бесплатный аккаунт почти не используется, и провайдеру выгодно утрамбовать таких «спящих» пользователей на сервер как можно плотнее.

На практике это означает эффект «шумных соседей» (noisy neighbors): на одном физическом сервере с вами сидят десятки или сотни чужих аккаунтов, и если у кого-то из них внезапно случается всплеск нагрузки — майнящий скрипт, взломанный сайт, начавший рассылать спам, или просто чей-то удачный вирусный пост — CPU и диск отжираются у всех соседей разом. Ваш сайт при этом тормозит или падает без всякой вины с вашей стороны, и без доступа к панели хостинга вы даже не узнаете, что причина не в вас.

Для сравнения — на изолированном VPS с честно выделенными (или хотя бы честно лимитированными per-instance) CPU/RAM чужая нагрузка на соседей физически не может забрать ваши ресурсы, потому что гипервизор жёстко режет квоту каждой виртуальной машины. Разница не в маркетинговой формулировке, а в архитектуре: на бесплатном шаринге лимит мягкий и общий на пул, на нормальном VPS — жёсткий и персональный.

Риск внезапного закрытия сервиса — без компенсации и почти без предупреждения

Бесплатные хостинг-платформы и PaaS с щедрым free tier периодически закрываются или радикально урезают бесплатный план — это происходит регулярно на протяжении всей истории веба и почти всегда работает по одному сценарию: убыточное направление сначала ограничивают, а если это не помогает экономике, закрывают полностью, обычно с уведомлением за несколько недель.

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

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

Считаем цену «бесплатно»: авральный переезд против скромной регулярной платы

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

Ключевая строка здесь — время, а не сама сумма подписки. Если оценить ваш час работы (или час работы фрилансера, которого вы наймёте разбираться) хотя бы в скромную сумму, 10-20 часов аврала уже перекрывают несколько лет платы за самый простой VPS. А если к этому добавить потерю позиций в поиске из-за длительного простоя (переиндексация после возврата сайта — это тоже не мгновенный процесс) и упущенные заявки за дни недоступности — экономия на «бесплатно» задним числом выглядит не экономией, а отложенным и увеличенным счётом.

Это не значит, что VPS сам по себе спасает от всех проблем — на нём тоже можно ничего не бэкапить и всё равно всё потерять. Разница в том, что VPS даёт вам инструменты для защиты (root-доступ, cron, снапшоты, поддержку), которыми можно воспользоваться, а бесплатный тариф чаще всего лишает вас этих инструментов физически, независимо от того, насколько ответственно вы подходите к делу.

Когда бесплатный хостинг всё же оправдан

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

Граница проходит там, где у проекта появляется первый реальный посетитель, которому важно, что сайт работает, — первый заказ, первая заявка, первая цитата в поиске, которую вы хотите удержать. С этого момента цена простоя и цена потери данных перестают быть нулевыми, и тогда лучше сразу перейти на что-то вроде небольшого VPS для тестовой среды — тарифы там начинаются достаточно скромно, чтобы не спорить с логикой «а вдруг не взлетит», но при этом дают root-доступ, snapshot и путь для роста без вынужденного переезда. Если проект уже вырос на бесплатном хостинге и упирается в его лимиты, разумный следующий шаг — спланированный, а не аварийный переход на VPS: перенос сайта можно сделать без простоя, если делать это заранее, а не когда старая площадка уже отказала.

Частые вопросы