Фрилансер показывает демо: свой стенд вместо «зайдите ко мне на ноутбук»

MAATRIX

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

Почему «зайдите ко мне на ноутбук» — это не показ, а неудобство для всех

Формально созвон с шарингом экрана решает задачу — заказчик видит интерфейс. Но по факту это стоит вам и ему больше, чем кажется:

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

Отдельная и более частая ситуация — не созвон, а короткая переписка: «дай доступ, я гляну». И тут начинается вариант номер два.

Второй вариант: временный проброс порта с ноутбука наружу

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

У подхода есть реальные плюсы — это быстро, не требует отдельного сервера и подходит для показа за пять минут до звонка. Но есть и системные проблемы, которые не решаются выбором более удобной утилиты:

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

Туннель — это нормальный инструмент для отладки вебхуков и разовой проверки с телефона. Но выдавать такую ссылку заказчику как постоянный доступ к демо — значит закладывать в процесс лишний источник нервотрёпки на пустом месте.

Что реально меняется, когда демо стоит на постоянном сервере

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

Что это даёт на практике:

• Ссылка не меняется. demo.вашдомен.ру или client1.вашдомен.ру — заказчик добавляет её в закладки один раз и возвращается когда угодно.
• Демо не зависит от вашего ноутбука. Вы можете уехать, сменить компьютер, уйти в отпуск — сервис продолжает отвечать, потому что крутится на арендованном сервере, а не на устройстве, которое вы вечером закрываете.
• Можно показывать прогресс без созвона. Заказчик открывает ссылку сам, когда ему удобно, и пишет фидбэк в переписке — вы экономите время на статус-звонках.
• Несколько проектов не мешают друг другу. У каждого клиента свой поддомен, свой процесс, своя база — один сервер спокойно держит демо-стенды пяти-шести активных заказчиков одновременно.
• Это часть портфолио. Ссылка на живой рабочий стенд — куда убедительнее в переписке с новым заказчиком, чем скриншот или репозиторий, который надо ещё запускать локально.

Дальше — конкретная схема, как это собрать: от голого сервера до рабочей ссылки для конкретного клиента.

Схема: домен, поддомены и структура на сервере

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

Домен и поддомены. Заведите один домен под демо-стенды (или используйте существующий рабочий домен с отдельной зоной), например demo.example.com, и выдавайте каждому проекту свой третий уровень:

client1.demo.example.com   -> проект заказчика №1
client2.demo.example.com   -> проект заказчика №2
staging.demo.example.com   -> ваш личный черновой стенд для тестов

В DNS-панели регистратора добавляете либо отдельные A-записи на IP сервера для каждого поддомена, либо один wildcard:

*.demo.example.com.  A  203.0.113.10

Wildcard-запись удобнее — не нужно возвращаться в DNS-панель при каждом новом клиенте, достаточно добавить блок в nginx на сервере. Если пока не занимались доменом и DNS с нуля, это отдельная тема — при желании сначала разберитесь с базовой настройкой сервера для себя как фрилансера: пошаговая настройка VPS под самозанятого и фрилансера с нуля.

Структура на сервере. Каждый проект — своя папка, свой системный пользователь для процесса (или хотя бы отдельная директория с чёткими правами), свой файл окружения:

/srv/demo/client1/
  ├── app/              # код проекта (git clone / git pull)
  ├── .env               # переменные окружения демо-версии
  └── deploy.sh           # скрипт обновления

/srv/demo/client2/
  ├── app/
  ├── .env
  └── deploy.sh

Так вы всегда знаете, где лежит демо конкретного клиента, и можете снести его одной командой rm -rf, когда проект закрыт и доступ больше не нужен.

Настройка: от процесса к рабочей ссылке

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

1. Процесс должен жить сам по себе, без вашего терминала. Если это Node.js, Python-приложение или что-то ещё, что не умеет форкаться в демон само, заведите systemd-юнит:

# /etc/systemd/system/demo-client1.service
[Unit]
Description=Demo stand for client1
After=network.target

[Service]
Type=simple
User=demo
WorkingDirectory=/srv/demo/client1/app
EnvironmentFile=/srv/demo/client1/.env
ExecStart=/usr/bin/node server.js
Restart=on-failure
RestartSec=5

[Install]
WantedBy=multi-user.target

sudo systemctl daemon-reload
sudo systemctl enable --now demo-client1

Теперь процесс переживёт перезагрузку сервера и автоматически перезапустится при падении — то, чего локальный запуск через npm run dev в принципе дать не может.

Если проект уже упакован в Docker — то же самое проще сделать через docker compose, указав restart: unless-stopped для каждого сервиса и свой набор портов на каждый demo-проект, чтобы они не конфликтовали друг с другом.

2. Nginx как точка входа на поддомен. На каждый проект — отдельный server-блок, который проксирует запрос на локальный порт процесса:

# /etc/nginx/sites-available/client1.demo.example.com
server {
    listen 80;
    server_name client1.demo.example.com;

    location / {
        proxy_pass http://127.0.0.1:3001;
        proxy_set_header Host $host;
        proxy_set_header X-Real-IP $remote_addr;
        proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
        proxy_set_header X-Forwarded-Proto $scheme;
    }
}

sudo ln -s /etc/nginx/sites-available/client1.demo.example.com /etc/nginx/sites-enabled/
sudo nginx -t && sudo systemctl reload nginx

Если раньше не настраивали nginx как обратный прокси — есть отдельный подробный разбор: как установить и настроить nginx как реверс-прокси на VPS.

3. HTTPS обязателен, даже для демо. Современные браузеры и так пугают пользователя, если сайт открывается по http://, а заказчик не должен разбираться, безопасна ли ссылка, которую вы прислали. Для поддомена с уже настроенным DNS сертификат ставится одной командой:

sudo certbot --nginx -d client1.demo.example.com

Certbot сам допишет нужные строки в конфиг nginx и настроит автопродление. Если сертификат не выпускается или nginx его не подхватывает — разбор частых причин есть тут: как установить и настроить Let's Encrypt SSL на VPS.

4. Скрипт обновления демо. Когда вносите правки локально и хотите обновить демо-версию — не нужно заходить руками и разбираться, что перезапустить. Один скрипт на проект:

#!/bin/bash
# /srv/demo/client1/deploy.sh
cd /srv/demo/client1/app
git pull origin main
npm install --production
sudo systemctl restart demo-client1

chmod +x /srv/demo/client1/deploy.sh

Дальше это можно вызывать вручную по SSH за десять секунд или повесить на git-хук, если код лежит в собственном репозитории на том же сервере.

Как не запутаться, когда демо-проектов становится много

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

Именование без импровизации. Заведите единое правило с самого начала — например, поддомен всегда равен короткому имени проекта в вашей системе учёта (папка, системный юнит, ветка в git — всё называется одинаково). Через полгода вы не будете гадать, какой из proj-a, test2 и newdemo — это активный клиент, а какой — забытый черновик.

Закрывайте демо, когда проект закрыт. У каждого поддомена должен быть срок жизни. Проект сдан, деньги получены, доступ заказчику больше не нужен — снимаете systemd-юнит, удаляете server-блок nginx, чистите папку. Иначе за год набирается десяток мёртвых демо, которые едят ресурсы и оставляют открытыми доступы, о которых вы уже забыли.

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

sudo apt install apache2-utils
sudo htpasswd -c /etc/nginx/.htpasswd_client1 client1

location / {
    auth_basic "Demo access";
    auth_basic_user_file /etc/nginx/.htpasswd_client1;
    proxy_pass http://127.0.0.1:3001;
}

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

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

Сравнение трёх способов показать демо заказчику

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

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