Ecommerce-скрипт на своём хостинге

Ecommerce-скрипт на своём хостинге ставится как обычный PHP-проект: файлы в корень или поддомен, база MySQL, конфиг с доступом, админка. Вы контролируете каталог, заказы и ключи оплаты. Облачный конструктор удобнее на старте — пока не упрётесь в тариф, комиссию и чужой поддомен в письмах клиентам.

Практика первого заказа — мануал магазина. Обзор PHP-магазина — интернет-магазин PHP.

Когда свой хостинг выгоднее SaaS

• Нужен свой бренд и домен без витрины на чужой платформе.
• Не хотите процент с оборота «за воздух» при росте продаж.
• Нужны доработки под нишу: свои поля, свои роли, своя выгрузка.
• Важны данные: выгрузки, бэкапы, хранение у себя / у вашего хостера.
• White label для франшизы или нескольких витрин с общей логикой.

Минусы честно: сами следите за PHP, SSL, бэкапами, обновлениями скрипта. Нет «кнопки поддержки платформы 24/7», если не купили SLA отдельно.

Чем ecommerce-скрипт отличается от «сайта с формой»

Форма «хочу купить» в Telegram — не ecommerce. В скрипте должны быть:

1. Каталог и карточка с ценой.
2. Корзина как состояние сессии/аккаунта.
3. Checkout с фиксацией заказа.
4. Статусы оплаты и сборки.
5. Админка, где менеджер не лезет в phpMyAdmin.

Дальше — доставка, промокоды, варианты SKU, онлайн-оплата. Без базового контура остальное бессмысленно. Checkout — здесь, каталог — здесь.

Развёртывание на хостинге: короткий регламент

1. PHP по требованиям + расширения (pdo_mysql, gd/imagick, mbstring, openssl).
2. Создать БД и пользователя с правами только на неё.
3. Прогнать установщик, удалить/закрыть install при необходимости.
4. Выставить права на upload и cache.
5. Включить https и проверить смешанный контент на карточках.
6. Настроить почту или хотя бы логирование писем.
7. Сделать тестовый заказ и бэкап «чистой» установки.

На VDS добавляются php-fpm, nginx root, cron для очисток и статусов. Не держите shopId и секрет ЮKassa в публичном репозитории.

Оплата и вебхуки на своём домене

Плюс своего хостинга — return URL и webhook смотрят на ваш HTTPS. Минус — если сертификат протух или firewall режет callback, заказы зависнут в «ожидает оплаты». ЮKassa разобрана в интеграции. Правило: статус «оплачен» только из проверенного уведомления, не из того, что пользователь вернулся на success-страницу.

Каталог, склад, доставка

На своём сервере вы вольны завести атрибуты и SKU как нужно нише — варианты. Зоны доставки и порог «бесплатно от» — доставка. Промо для рассылок — промокоды. Всё это крутится локально в вашей БД, без лимита «тариф Start: 50 товаров».

Операционные риски, о которых молчат лендинги

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

Заведите простой регламент: бэкап раз в сутки, кто меняет цены, кто отвечает за сверку оплат по утрам.

Итог выбора

Ecommerce-скрипт на своём хостинге — контроль и ответственность. SaaS — скорость и чужие ограничения. Если бренд, данные и доработки важнее «открыться за вечер», берите PHP-магазин и закрывайте контур заказа по чеклисту. Если нужен один лендинг с тремя товарами и оплатой по ссылке — возможно, вам пока рано усложнять.

Обновления и кастомы

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

• Список кастомов в заметке у владельца (что меняли и зачем).
• Версия PHP после обновления хостинга совместима с скриптом.
• Ключи оплаты после переноса не указывают на старый webhook URL.

Когда SaaS всё же честнее

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

Для старта я прошу заказчика ответить письменно: кто делает бэкап, кто сводит оплаты, кто меняет цены. Пустые ответы = рано на свой хостинг, сначала процессы. Когда ответы есть — ecommerce-скрипт отрабатывает своё: каталог, корзина, заказ, касса на вашем домене.

Мониторинг после запуска

Минимум сигналов: доступность сайта, ошибка 500 в логах, очередь писем, вебхуки оплаты без ответа 200, диск выше порога. Не обязательно сразу строить «космос» — хватит писем/Telegram админу. Раз в неделю — тестовый заказ на стейдже после любых правок шаблонов. Ecommerce-скрипт на своём хостинге прощает отсутствие красивого дашборда, но не прощает отсутствие привычки проверять кассу и бэкап.

Если через месяц 80% заказов всё ещё приходят «напишите нам в WhatsApp» с витрины — ищите трение в checkout или доставке, а не покупайте новый слайдер. Скрипт уже даёт контур; конверсию дожимают ясными тарифами, остатками и скоростью ответа менеджера. Свой хостинг тут ни при чём — при чём операционка магазина.

Безопасность контура

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

Логи доступа периодически глядите после увольнений. Смените пароли кассы и админки одним днём. Это скучно и обязательнее любого нового модуля скидок. Контроль данных — главный аргумент своего хостинга; не обесценивайте его дырявой операционкой паролей.