Публикация: домен, сервер, SSL

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

Цель урока — довести то, что вы собрали, до состояния «работает, пока вы спите».

Три вещи, из которых состоит публикация

Место. Сервер, на котором крутится ваш код и база. Он должен быть включён всегда, а не пока открыт ноутбук.

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

Замок. SSL-сертификат и работа по https. Без него браузер честно скажет посетителю, что сайту доверять нельзя, — и на этом знакомство закончится.

Технически всё это делается агентом так же, как остальной код: вы описываете, что должно получиться, и проверяете результат. Этот сайт живёт на связке Next.js, FastAPI, PostgreSQL и Docker — контейнеры собираются одной командой, и точно так же одной командой обновляются.

Сколько это стоит на самом деле

В моей смете сервер стоит 18 000 ₽ в месяц — но это один мощный сервер, на котором одновременно живут разработки моих клиентов и мои собственные проекты. Не входной билет, а инфраструктура под десятки задач сразу. Для учебного проекта и первых клиентских задач всё берётся в разы дешевле.

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

Чек-лист перед тем, как открывать доступ

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

• Секреты не в коде. Токены, пароли, ключи — только в переменных окружения. Если что-то из этого попало в репозиторий, его надо считать скомпрометированным.
• Входные данные валидируются на сервере. Проверка в браузере — удобство для человека, а не защита. Настоящая проверка живёт на бэкенде.
• Публичные формы защищены от ботов. Иначе через неделю после запуска вы будете разгребать спам вместо заявок.
• Есть бэкап базы, и вы его хотя бы раз разворачивали. Бэкап, который никогда не восстанавливали, — это не бэкап.
• Вы знаете, как выкатить исправление. Одной командой, а не «вспомню, как я это делал».

Что начинается после запуска

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

Потом дошло. Поддержка показывает только проблемы. Довольные молчат. Из ленты тикетов невозможно понять, как живёт сервис: это не репрезентативная выборка, это крик души.

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

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

Что бы я сделал иначе, если бы начинал заново

1. Сначала структура, потом код. Час на то, чтобы разложить фичу по кускам, экономит день переделок.
2. Правила проекта — в первый день, а не на сотый.
3. Не гнаться за «одним промптом». Крупная фича рождается серией маленьких задач, каждую из которых вы проверяете.
4. Убирать за собой сразу.

И ещё одно, про масштаб. ПКМаркетинг дожил до 13 000+ пользователей и государственной IT-аккредитации не потому, что я стал усидчивее, а потому что скучное перестало быть моей работой. Аккредитация, кстати, ничего не говорит о том, каким инструментом набран код. Она говорит, что есть работающий продукт и кто-то, кто за него отвечает. Вайбкодинг не мешает ни первому, ни второму.

Практическое задание

1. Опубликуйте то, что собрали на уроках 2–4. Пусть это будет одна страница или один бот — важно, что по ссылке открывается у любого человека, а не только у вас.
2. Пройдите чек-лист выше по пунктам. Каждый — вслух «да» или «нет». На каждое «нет» заведите задачу.
3. Отправьте ссылку одному живому человеку и запишите первые три его сообщения. Разделите их на «индивидуальная ситуация» и «настоящий баг». Это ваша первая пропорция 90/10 — и первый раз, когда вы решаете не по эмоции, а по данным.

На этом мини-курс закончен. У вас есть задача, окружение, способ ставить её агенту, правила проекта и опубликованный результат — то есть весь цикл целиком, только в миниатюре.