Когда проект готов локально: как безопасно передать веб-сервис на хостинг клиента

Но в интернете его ещё нет.

Именно в этот момент отношения заказчика и разработчика переходят в совершенно другую фазу.

До этого исполнитель создавал продукт в собственной рабочей среде. Теперь код, база данных, домен, сервер, SSL, переменные окружения, почта, фоновые процессы и резервное копирование должны превратиться в production-систему на инфраструктуре клиента.

Для заказчика это начало эксплуатации.

Для разработчика — момент передачи результата и значительной части контроля над ним.

В WebRuta мы рассматриваем эту границу как отдельный этап проекта, а не как техническую мелочь в духе:

«Ну теперь осталось просто залить сайт на сервер».

Для сложного веб-сервиса «просто залить» почти никогда не бывает.

Разберём, как мы выстраиваем этот процесс, почему окончательный расчёт логично завершать до переноса готового проекта на инфраструктуру заказчика, какие гарантии при этом должен получить клиент и что необходимо проверить уже после запуска.

Сначала определимся, что значит «проект готов»

Одна из главных причин конфликтов между заказчиком и разработчиком — разные представления о слове «готово».

Для заказчика:

Если приложение готово, почему оно ещё не работает на моём домене?

Для разработчика:

Оно готово как программный продукт, но production ещё не развёрнут.

Это действительно разные состояния.

Мы разделяем как минимум три этапа:

Локальная разработка завершена
            ↓
Предрелизная приёмка
            ↓
Production-развёртывание
            ↓
Финальная проверка на инфраструктуре клиента

Первый этап означает, что согласованная функциональность разработана.

Второй — что заказчик получил подтверждение результата и может сверить его с ТЗ и коммерческим предложением.

Третий — что проект переносится на реальный сервер и реальный домен.

И только после четвёртого этапа система становится рабочей production-средой.

Смешивание этих стадий часто и создаёт проблемы.

Почему локально готовый проект ещё не является production

Представим B2B-сервис.

Локально работают:

Frontend
Backend
PostgreSQL
Redis
Background worker
Object Storage
Email
WebSocket

На компьютере разработчика приложение может использовать:

localhost:4173

База:

localhost:5432

Redis:

localhost:6379

Файлы могут храниться в локальном development-контуре.

В production всё будет иначе.

Например:

https://example.ru
        ↓
      Nginx
        ↓
┌───────────────┐
│ Backend       │
│ Worker        │
└───────┬───────┘
        ↓
 PostgreSQL
 Redis
 Object Storage

Появляются реальные DNS, HTTPS, firewall, production secrets, доменная почта, резервное копирование и мониторинг.

Поэтому успешный запуск приложения локально ещё не подтверждает, что production-окружение настроено правильно.

Почему мы не превращаем локальный компьютер разработчика во временный сервер

Технически существует множество способов показать локальное приложение через интернет.

Есть tunneling-сервисы, screen sharing, VPN и временные reverse proxy.

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

Development-машина и production-инфраструктура решают разные задачи.

На локальном компьютере:

• выполняется разработка;
• меняется код;
• запускаются тесты;
• используются development-конфигурации;
• могут существовать диагностические инструменты;
• сервисы периодически перезапускаются.

Production должен быть значительно предсказуемее.

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

Но заказчик не должен платить вслепую

Здесь возникает совершенно справедливый вопрос.

Если проект ещё не находится на сервере клиента, на каком основании заказчик должен выполнить окончательный расчёт?

Ответ — до финального платежа должна существовать предрелизная приёмка.

Клиент должен понимать, что заказанная функциональность действительно создана.

Способов подтвердить это несколько.

Например:

• совместная демонстрация;
• запись основных пользовательских сценариев;
• скриншоты;
• отчёт о тестировании;
• демонстрация административной панели;
• walkthrough по согласованному ТЗ;
• чек-лист реализованных функций;
• результаты mobile/desktop проверок;
• перечень выполненных интеграций.

Для большого проекта мы считаем особенно полезным пройтись непосредственно по требованиям.

Не просто:

Сервис готов.

А:

Регистрация                  ✓
Авторизация                  ✓
Восстановление доступа       ✓
Создание проекта             ✓
Уточнения                    ✓
Уведомления                  ✓
Файлы                        ✓
Роли и разрешения            ✓
Админ-панель                 ✓
Мобильная версия             ✓
Резервное копирование        ✓

Тогда финальная оплата привязывается не к обещанию разработчика, а к понятной контрольной точке.

ТЗ и коммерческое предложение здесь становятся особенно важными

До начала разработки клиент и исполнитель должны договориться как минимум о двух вещах.

Техническое задание отвечает:

Что именно мы создаём?

Коммерческое предложение отвечает:

На каких условиях мы это создаём?

Например:

Этап 1
Согласование требований

Этап 2
Локальная разработка

Этап 3
Предрелизная приёмка

Этап 4
Окончательный расчёт

Этап 5
Production deployment

Этап 6
Финальная проверка

Этап 7
Передача доступов и эксплуатация

Когда такой порядок известен заранее, требование полной оплаты перед production не возникает внезапно в последний день проекта.

Оно является частью согласованного процесса.

Почему окончательный расчёт происходит до переноса проекта на инфраструктуру клиента

Это одна из принципиальных точек нашей модели.

Пока система находится в development-контуре исполнителя, результат ещё фактически не передан заказчику.

После deployment ситуация меняется.

Код уже находится:

на сервере клиента;
на его домене;
под его инфраструктурным контролем.

Может быть создана production-база.

Настроены Docker-контейнеры или systemd-сервисы.

Запущены фоновые процессы.

Привязан домен.

Выпущен SSL-сертификат.

Настроен Nginx.

Подключена почта.

Созданы backup jobs.

Иными словами, заказчик уже получает не демонстрацию, а полноценный развёрнутый продукт.

Если в этот момент значительная часть согласованной стоимости проекта ещё не оплачена, коммерческий риск исполнителя резко возрастает.

Почему схема «сначала отдадим всё, потом попросим оплатить» опасна

Представим худший сценарий.

Проект полностью разработан.

Исполнитель получает доступ к VPS клиента.

Разворачивает backend.

Разворачивает frontend.

Создаёт production-базу.

Настраивает Nginx.

Привязывает домен.

Получает SSL.

Настраивает cron/jobs.

Подключает хранилище.

Проверяет мобильную версию.

Исправляет production-особенности.

После нескольких дней работы сообщает:

Всё готово.

А заказчик отвечает:

Спасибо. Остаток оплачивать не будем.

Технически продукт уже находится в инфраструктуре клиента.

Удалять его или намеренно выводить из строя после коммерческого спора — крайне плохой путь.

Поэтому правильнее не создавать такую ситуацию изначально.

Финансовая граница должна находиться до передачи production-контроля, а не после неё.

Это защищает не только исполнителя

Справедливый процесс должен уменьшать риски обеих сторон.

Поэтому мы не считаем хорошей модель:

Сначала заплатите всё, потом когда-нибудь что-нибудь получите.

До окончательного расчёта клиент должен получить подтверждение того, что agreed scope действительно реализован.

А после расчёта production-этап должен быть чётко определён.

Например:

Полная оплата
      ↓
Получение временных доступов
      ↓
Deployment
      ↓
DNS / HTTPS
      ↓
Production configuration
      ↓
Smoke tests
      ↓
Исправление production-дефектов
      ↓
Финальная передача

Таким образом исполнитель защищён от неоплаты уже переданного результата.

А клиент защищён понятной процедурой приёмки и обязательством довести согласованный продукт до рабочего production-состояния.

Хостинг лучше оформлять на клиента

Мы считаем это принципиально важным.

Если проект принадлежит заказчику, инфраструктурный аккаунт тоже желательно создавать на заказчика.

То есть клиент самостоятельно приобретает:

VPS / hosting

и оплачивает его непосредственно провайдеру.

У этого подхода есть несколько преимуществ.

Во-первых, сервер не зависит от будущих отношений с разработчиком.

Во-вторых, заказчик видит стоимость инфраструктуры напрямую.

В-третьих, после завершения сотрудничества не требуется переносить проект только потому, что сервер зарегистрирован на чужую компанию.

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

С доменом действует тот же принцип

Домен проекта желательно регистрировать на клиента.

Не на разработчика.

Не на сотрудника.

Не на временную учётную запись исполнителя.

Именно клиент должен оставаться владельцем доменного имени.

Разработчику нужен только технический доступ, необходимый для настройки DNS.

Например, потребуется создать:

A
AAAA
CNAME
MX
TXT

в зависимости от архитектуры проекта.

Но право собственности на домен должно оставаться у заказчика.

Это защищает его даже в случае полного прекращения сотрудничества с исполнителем.

Передавать основной пароль от регистратора необязательно

У многих сервисов существуют:

• приглашения пользователей;
• делегированный доступ;
• дополнительные администраторы;
• API-токены с ограниченными правами;
• временные учётные записи.

Если такой механизм есть, он предпочтительнее передачи основного логина и пароля.

То же относится к хостингу.

Лучше:

отдельный временный администратор

чем:

главная учётная запись клиента + постоянный пароль

После завершения deployment временный доступ можно удалить.

Если временный доступ невозможен

Иногда панель управления слишком простая и позволяет использовать только одну учётную запись.

Тогда клиент может временно передать пароль, но после окончания работ его следует обязательно сменить.

Процесс:

Клиент создаёт временный пароль
        ↓
Разработчик выполняет настройку
        ↓
Проект принят
        ↓
Клиент меняет пароль

У исполнителя не должно быть причины хранить старые credentials после передачи проекта.

Какие доступы могут понадобиться для production

Для сложного проекта это может быть не только SSH.

Например:

VPS / SSH
DNS
регистратор домена
S3 / object storage
SMTP
платёжная система
Telegram Bot
OAuth providers
CDN
аналитика
почтовый сервис

При этом действует принцип минимальных привилегий.

Если для работы нужен доступ только к DNS, нет смысла выдавать полный доступ к финансовому аккаунту регистратора.

Если приложение только отправляет письма, ему не нужен пароль от личной почты клиента.

Production secrets создаются отдельно

Development-секреты нельзя просто перенести из локальной среды.

Для production должны быть созданы собственные значения.

Например:

DATABASE_URL
REDIS_URL
JWT_SECRET
SESSION_SECRET
ENCRYPTION_KEY
S3_ACCESS_KEY
S3_SECRET_KEY
SMTP_PASSWORD
ADMIN_SECRET

В production они не должны находиться:

в Git;
в публичном архиве;
во frontend;
в документации без необходимости.

Обычно они передаются приложению через environment variables или защищённое хранилище секретов.

Отдельный вопрос — исходный код

В зависимости от договора передача исходников может происходить по-разному.

Например, после полной оплаты заказчик получает:

исходный код;
production release;
миграции БД;
конфигурационные примеры;
deployment-инструкцию;
техническую документацию.

Но порядок должен быть заранее зафиксирован.

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

Так обе стороны понимают момент, когда продукт окончательно переходит заказчику.

Что именно происходит после полной оплаты

После того как локальная версия принята и расчёты по согласованной стоимости завершены, начинается deployment.

Мы разделяем его на несколько шагов.

1. Проверка инфраструктуры

Сначала проверяется VPS.

Например:

CPU
RAM
disk
операционная система
свободные порты
firewall
Docker/systemd
DNS

Если архитектура рассчитана условно на:

2 CPU
4 GB RAM

а клиент приобрёл:

1 CPU
512 MB RAM

проблему лучше обнаружить до установки PostgreSQL.

2. Подготовка сервера

В зависимости от стека устанавливаются:

Nginx
Docker
PostgreSQL
Redis
Node.js
runtime dependencies

или используется контейнеризированный deployment.

Создаются каталоги приложения.

Например:

/opt/project
/var/log/project
/var/lib/project

Настраиваются права доступа.

3. Развёртывание базы данных

База создаётся отдельно от development.

После этого выполняются migrations:

001_init.sql
002_users.sql
003_projects.sql
...

Production schema должна создаваться воспроизводимо.

Подход:

Сейчас руками добавим пару колонок

плохо масштабируется уже после нескольких обновлений.

4. Production environment

Создаётся отдельная конфигурация:

NODE_ENV=production
PUBLIC_URL=https://example.ru

а также подключения к production-сервисам.

Важно не смешивать development и production credentials.

5. Запуск backend и worker

Если система состоит из нескольких процессов, каждый запускается и проверяется отдельно.

Например:

API
Worker
Scheduler

Недостаточно убедиться:

Процесс существует.

Нужно проверить:

Он действительно способен работать с инфраструктурой.

Поэтому полезно иметь:

/health
/ready

health отвечает:

Процесс жив?

ready:

Он может работать с БД, Redis и другими обязательными зависимостями?

6. Настройка Nginx

Nginx принимает внешний HTTPS-трафик и передаёт его приложению.

Например:

Internet
   ↓
HTTPS
   ↓
Nginx
   ↓
Node.js API

Одновременно он может обслуживать статические ресурсы, выполнять gzip/brotli, устанавливать security headers и реализовывать rate limiting.

7. Привязка домена

После готовности backend можно переключать DNS.

Например:

example.ru
    ↓
A record
    ↓
IP VPS

Если используется:

www.example.ru

необходимо решить, какой адрес считается canonical.

Например:

www.example.ru
    ↓ 301
example.ru

Чтобы поисковые системы не рассматривали их как два разных сайта.

8. HTTPS

После того как DNS указывает на сервер, выпускается SSL/TLS-сертификат.

После этого:

http://example.ru

обычно перенаправляется на:

https://example.ru

Проверяется:

• сертификат;
• цепочка;
• срок действия;
• автоматическое обновление;
• редирект HTTP → HTTPS.

9. Production storage

Если приложение принимает пользовательские файлы, необходимо проверить не только загрузку.

Нужно убедиться:

файл загружается;
файл сохраняется;
правильно проверяются права;
файл скачивается;
ссылка не становится публичной случайно;
backup учитывает файловое хранилище.

Для S3-совместимой инфраструктуры отдельно проверяются bucket, credentials и policy.

10. Почта и уведомления

То, что email работает локально через тестовый SMTP, ещё ничего не говорит о production.

После привязки домена могут понадобиться:

SPF
DKIM
DMARC

Затем тестируются:

регистрация;

восстановление пароля;

уведомления;

служебная почта.

После запуска начинается production QA

И это очень важный момент договора.

Полная оплата перед deployment не означает, что после появления проекта на сервере исполнитель перестаёт отвечать за собственные дефекты.

После запуска необходимо пройти реальные сценарии уже на production.

Например:

регистрация;
логин;
logout;
восстановление пароля;
создание проекта;
загрузка файлов;
уведомления;
административная панель;
мобильная версия;
background jobs.

Именно здесь иногда обнаруживаются environment-specific проблемы.

Например:

• неправильный CORS;
• отличие filesystem;
• DNS;
• SMTP;
• размер upload;
• права на каталог;
• timezone;
• proxy headers;
• cookie Secure;
• WebSocket proxying.

Это часть нормального production deployment.

Исправление дефекта и новая функция — разные вещи

После запуска необходимо заранее различать два типа работ.

Дефект

Согласованная функция должна работать, но не работает.

Например:

Клиент согласно ТЗ должен загружать PDF, но production возвращает 500.

Такой дефект должен исправляться в рамках доведения согласованного результата до рабочего состояния.

Новое требование

После запуска клиент говорит:

Теперь давайте ещё добавим автоматическую отправку PDF в 1С.

Если этого не было в утверждённом scope, это уже изменение проекта.

Для него формируется отдельная оценка.

Иначе production-этап очень быстро превращается в бесконечное:

Раз вы ещё что-то исправляете, добавьте заодно ещё вот это.

Именно поэтому после ТЗ нужен change request

Если после утверждения ТЗ клиент хочет изменить проект, хороший процесс выглядит так:

Запрос клиента
      ↓
Анализ
      ↓
Влияние на сроки
      ↓
Влияние на стоимость
      ↓
Подтверждение клиента
      ↓
Разработка

Так первоначальная стоимость проекта и новые пожелания не смешиваются.

Это особенно важно непосредственно перед запуском.

Почему нельзя считать production-сервер средой бесконечной разработки

После запуска приложение уже может использоваться клиентами.

Поэтому правило:

быстро исправим прямо на сервере

опасно.

Лучше сохранять нормальный цикл:

изменение
    ↓
development
    ↓
test
    ↓
release
    ↓
production

Даже если основная разработка закончена.

После запуска сервер не должен превращаться в редактор исходного кода.

Перед первым production deployment нужен backup plan

Даже новый сервер нуждается в плане восстановления.

Если создаётся production-БД, нужно понимать:

когда создаётся backup;
где он хранится;
сколько копий сохраняется;
как происходит restore.

Сам факт наличия файла .dump ещё не гарантирует возможности восстановления.

Для важных систем желательно хотя бы один раз проверить реальный restore.

Нужен и rollback

Представим:

Release A
работает

↓ deployment

Release B
не запускается

У разработчика должен быть ответ не:

Сейчас будем разбираться прямо на production.

А:

вернуть Release A

и уже после восстановления сервиса исследовать проблему.

Это может быть Docker tag, предыдущий release directory или другой механизм.

Конкретная технология вторична.

Главное — возможность отката должна быть предусмотрена до аварии.

Перед передачей полезно составить production checklist

Например:

[ ] DNS работает
[ ] HTTPS работает
[ ] HTTP → HTTPS
[ ] Backend ready
[ ] Database ready
[ ] Redis ready
[ ] Worker ready
[ ] Upload работает
[ ] Email работает
[ ] Backup создан
[ ] Restore проверен
[ ] Admin login работает
[ ] User login работает
[ ] Mobile QA пройден
[ ] 404 работает
[ ] robots.txt проверен
[ ] sitemap проверен
[ ] Monitoring работает

Чем сложнее система, тем опаснее полагаться на память разработчика.

Когда клиент меняет пароли

После завершения deployment и финальной проверки наступает момент инфраструктурной передачи.

Клиент может:

сменить пароль регистратора;
сменить пароль хостинга;
удалить временную учётную запись;
перевыпустить временные API tokens.

Это нормальный этап.

Если после этого клиент заказывает дальнейшую поддержку, доступ можно организовать уже отдельно.

Например, создать специальную учётную запись:

developer@project

с только необходимыми правами.

Что остаётся у клиента после передачи

Хорошая передача должна оставлять клиенту не только работающий домен.

В зависимости от проекта это может быть:

домен;
VPS;
исходный код;
production release;
база данных;
пользовательские файлы;
ключевые конфигурации;
backup;
инструкция deployment;
административный доступ;
документация.

То есть исчезновение разработчика не должно автоматически означать исчезновение продукта.

Что остаётся у разработчика

После передачи не должны без необходимости храниться:

пароли клиента;
production database dumps;
личные пользовательские данные;
master tokens.

Если поддержка продолжается, доступы лучше организовать осознанно и ограниченно.

Если нет — удалить.

Это полезно обеим сторонам.

Почему мы связываем окончательный расчёт именно с локальной готовностью

Теперь вся схема становится понятнее.

Слишком рано

Если требовать 100% оплаты до разработки, почти весь риск ложится на заказчика.

Слишком поздно

Если требовать остаток уже после полной передачи кода и production-инфраструктуры, почти весь коммерческий риск оказывается у исполнителя.

Контрольная точка между ними

Мы считаем логичным момент:

Согласованный scope реализован
            ↓
Проект прошёл внутреннее QA
            ↓
Клиент получил подтверждение готовности
            ↓
Есть согласование на production
            ↓
Финальный расчёт
            ↓
Deployment на инфраструктуру клиента

Это достаточно поздно, чтобы заказчик видел реальный результат.

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

Пример полного жизненного цикла проекта

В упрощённом виде процесс можно представить так.

1. Первичное обращение

Клиент описывает задачу.

2. Уточнение требований

Исполнитель и клиент вместе доводят требования до состояния, пригодного для оценки.

3. Техническое задание

Фиксируются:

функции;
роли;
бизнес-процессы;
интеграции;
ограничения;
критерии готовности.

4. Коммерческое предложение

Фиксируются:

стоимость;
этапы;
срок;
порядок оплаты;
условия передачи;
scope.

5. Подтверждение

Клиент принимает ТЗ и КП.

6. Локальная разработка

Создаются:

frontend;
backend;
database;
admin;
integrations;
tests.

7. Внутреннее QA

Проверяются согласованные сценарии.

8. Предрелизная демонстрация

Клиент получает подтверждение реализации.

9. Приёмка локальной версии

Закрываются вопросы относительно первоначального scope.

10. Полный расчёт по проекту

Финансовые обязательства по согласованной разработке закрываются.

11. Клиент предоставляет инфраструктуру

Домен и хостинг принадлежат клиенту.

Исполнитель получает временные технические доступы.

12. Production deployment

Проект разворачивается.

13. Домен и HTTPS

Проект становится доступным по рабочему URL.

14. Production QA

Проверяются реальные пользовательские сценарии.

15. Исправление выявленных дефектов

В рамках согласованной функциональности.

16. Финальная передача

Клиент меняет временные пароли и получает контроль над инфраструктурой.

А если клиент отказывается оплачивать готовый проект?

Именно для этого финансовая граница должна быть определена заранее.

Если проект завершён локально, результат продемонстрирован, но клиент не выполняет согласованный окончательный платёж, deployment не начинается.

То есть приложение:

не удаляется;
не блокируется после передачи;
не ломается;

Оно просто ещё не передано в production.

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

И обратная ситуация: что защищает клиента?

Процесс должен быть симметричным.

Клиенту не следует оплачивать неизвестный результат только на основании обещания:

Всё готово, поверьте.

До контрольной точки у него должны быть:

ТЗ;
КП;
список реализованных требований;
демонстрация;
результаты проверки;
зафиксированные замечания.

А порядок production-работ должен быть заранее описан.

Чем прозрачнее процедура, тем меньше коммерческие отношения зависят от личного доверия.

Что особенно важно для сложной веб-разработки

Для лендинга deployment действительно может занимать несколько минут.

Для большой системы production-этап может включать:

PostgreSQL
Redis
S3
Nginx
SSL
Docker
workers
queues
WebSocket
SMTP
OAuth
Web Push
Telegram
backups
monitoring
cron
SEO

Поэтому фраза:

Сайт уже написан, осталось выложить

может сильно недооценивать объём последнего этапа.

В сложных продуктах deployment сам по себе является инженерной работой.

Передача проекта — это не одна кнопка

В какой момент проект действительно передан?

Когда клиент получил ZIP?

Когда код появился на сервере?

Когда заработал домен?

Когда выполнены migrations?

Когда появился HTTPS?

Когда заработали письма?

Когда сделан первый backup?

На практике мы считаем передачу завершённой, когда существует воспроизводимая рабочая production-система, а не просто набор файлов на VPS.

Именно поэтому этот этап нужно проектировать так же внимательно, как саму разработку.

Главный принцип

Заказчик и исполнитель по-разному рискуют на разных этапах проекта.

В начале больше рискует клиент: он ещё не получил результат.

После полной передачи больше рискует разработчик: результат уже контролируется клиентом.

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

Для нашей модели такой точкой является:

завершённый и принятый локальный release — полный расчёт — production deployment на инфраструктуру клиента.

При этом:

• домен принадлежит клиенту;
• хостинг принадлежит клиенту;
• клиент получает подтверждение готовности до окончательной оплаты;
• разработчик не передаёт завершённый production до закрытия согласованной стоимости;
• после оплаты проект обязательно доводится до рабочего production-состояния;
• ошибки согласованной функциональности исправляются;
• новые требования оформляются отдельно;
• временные доступы после передачи отзываются.

В результате платёж перестаёт быть вопросом:

Кто кому больше доверяет?

Он становится частью технически и организационно понятного процесса.

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