Клиентская галерея фотографа: отдавать снимки со своего сервера, а не с Диска

MAATRIX

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

Почему ссылка на общую папку работает против бренда фотографа

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

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

Во-вторых, лимиты бесплатных и даже платных тарифов. Свадебная съёмка в RAW и обработанные JPEG легко занимают 20-40 ГБ на один заказ. Если студия работает с несколькими клиентами параллельно, бесплатный тариф диска заканчивается быстро, а платный тариф считается за объём, который не имеет отношения к вашему бизнесу напрямую — вы платите провайдеру диска, а не вкладываете в то, что реально относится к студии: сайт, портфолио, архив.

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

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

Всё это по отдельности не критично. Вместе — это ощущение, что у студии нет своей системы, а есть набор бесплатных инструментов, слепленных на скорую руку. Клиент не формулирует это так явно, но чувствует.

Что должно уметь простое серверное решение для клиентской галереи

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

• Свой домен или поддомен. galereya.вашастудия.ru или gallery.вашдомен.com — клиент видит адрес студии в адресной строке, а не домен облачного сервиса.
• Приватность на уровне конкретного клиента. Каждая галерея — под отдельным неугадываемым адресом и/или паролем, доступ не пересекается с другими заказами.
• Водяные знаки на превью до выбора кадров. Клиент листает и выбирает по превью с лёгким водяным знаком, оригиналы без знака отдаются только после оплаты или явного открытия доступа фотографом.
• Никаких лимитов чужого тарифа. Место на диске — то, за которое вы платите напрямую за аренду сервера, а не втридорога за «премиум»-объём облачного диска.
• Управляемый срок жизни галереи. Через месяц-два после сдачи заказа галерею логично закрыть или удалить — и это должно быть просто, а не «искать, куда делась та папка».
• Не требует от клиента установки приложений или регистрации аккаунта. Ссылка, при необходимости пароль — и всё открывается в обычном браузере на телефоне.

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

Архитектура на своём сервере: домен, reverse proxy, галерея

Базовая схема простая и её можно развернуть за один вечер на небольшом VPS.

Клиент → https://gallery.вашдомен.ru/ivanovy-2026/
              │
              ▼
        Nginx (reverse proxy, TLS, basic auth)
              │
              ▼
   Каталог с превью (с водяным знаком) + каталог с оригиналами
              │
              ▼
        Диск сервера (SSD, объём под ваши заказы)

Что для этого нужно на практике:

1. VPS с SSD-хранилищем. Для студии, которая ведёт 3-6 заказов параллельно с фотографиями (не видео — под видео нужен объём на порядок больше), обычно достаточно небольшого сервера с диском в пределах пары сотен гигабайт с запасом на рост. Точный объём считайте от своей нагрузки: средняя свадьба в JPEG высокого качества — это, ориентировочно, единицы гигабайт на превью-версию галереи, десятки гигабайт, если отдаёте ещё и оригиналы.
2. Домен или поддомен, направленный A-записью на IP сервера.
3. Nginx как reverse proxy с TLS-сертификатом (Let's Encrypt через certbot закрывает это бесплатно и автоматически продлевает сертификат).
4. Структура каталогов по клиентам, где у каждого заказа свой подкаталог с неугадываемым именем.

Пример структуры на сервере:

/var/www/galleries/
├── ivanovy-svadba-a3f9c2e1/
│   ├── previews/          # уменьшенные, с водяным знаком
│   └── originals/         # открывается после оплаты
├── petrova-portret-7d1e88f0/
│   ├── previews/
│   └── originals/

Имя подкаталога — не ivanovy, а ivanovy-svadba-a3f9c2e1, где хвост — случайный набор символов. Это не замена паролю, но серьёзно снижает риск, что кто-то случайно наберёт похожий адрес или найдёт галерею перебором.

Базовый блок конфигурации Nginx для одной галереи с TLS и базовой авторизацией:

server {
    listen 443 ssl;
    server_name gallery.вашдомен.ru;

    ssl_certificate     /etc/letsencrypt/live/gallery.вашдомен.ru/fullchain.pem;
    ssl_certificate_key /etc/letsencrypt/live/gallery.вашдомен.ru/privkey.pem;

    location /ivanovy-svadba-a3f9c2e1/ {
        alias /var/www/galleries/ivanovy-svadba-a3f9c2e1/previews/;
        auth_basic "Галерея Ивановых";
        auth_basic_user_file /etc/nginx/.htpasswd_ivanovy;
        autoindex off;
    }

    location /ivanovy-svadba-a3f9c2e1/originals/ {
        alias /var/www/galleries/ivanovy-svadba-a3f9c2e1/originals/;
        auth_basic "Оригиналы — Ивановы";
        auth_basic_user_file /etc/nginx/.htpasswd_ivanovy_paid;
        autoindex off;
    }
}

Обратите внимание на autoindex off — без него Nginx покажет список файлов каталога всем, у кого есть пароль от превью, включая структуру оригиналов, если её случайно не закрыть отдельно. Про сам reverse proxy и типовые грабли с ним есть отдельный разбор: Nginx как reverse proxy на VPS. А как Let's Encrypt проверяет, что домен действительно ваш, и почему сертификат иногда не выпускается с первой попытки — в статье про подтверждение владения доменом для Let's Encrypt.

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

Водяные знаки на превью и приватный доступ по ссылке или паролю

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

Генерация превью с водяным знаком через ImageMagick — рабочий вариант для автоматизации на сервере:

# устанавливаем ImageMagick, если ещё не стоит
apt install imagemagick -y

# уменьшаем оригинал и накладываем полупрозрачный водяной знак по центру
convert original.jpg -resize 1600x1600 \
  -gravity center \
  -pointsize 42 -fill "rgba(255,255,255,0.45)" \
  -annotate 0 "ВАША СТУДИЯ · ПРЕВЬЮ" \
  previews/original.jpg

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

#!/bin/bash
# generate-previews.sh
SRC="$1"
DST="$SRC/previews"
mkdir -p "$DST"

for f in "$SRC"/*.jpg; do
  name=$(basename "$f")
  convert "$f" -resize 1600x1600 \
    -gravity south -pointsize 36 -fill "rgba(255,255,255,0.4)" \
    -annotate +0+30 "PREVIEW" \
    "$DST/$name"
done

Что касается доступа — есть два рабочих уровня, и их стоит комбинировать, а не выбирать один:

• Неугадываемый URL (случайный хвост в адресе подкаталога) — защищает от случайного обнаружения и от того, чтобы кто-то нашёл галерею через поиск по сайту или перебор понятных адресов вроде /ivanovy/.
• Пароль через Basic Auth — защищает от пересылки ссылки третьим лицам без дополнительных вопросов: даже если адрес утёк, без пароля файлы не откроются.

Для каждого клиента — свой файл паролей и, что важно, свой пароль. Создаётся штатной утилитой:

# первый пользователь создаёт файл (-c), остальные добавляются без этого флага
htpasswd -c /etc/nginx/.htpasswd_ivanovy ivanovy
htpasswd /etc/nginx/.htpasswd_ivanovy_paid ivanovy_paid

Пароль сообщается клиенту лично — в переписке или голосом, а не публикуется рядом со ссылкой. Так закрывается сценарий «клиент переслал ссылку подруге, а та скачала фото в оригинале без ведома фотографа».

Готовые галерейные CMS и вариант «сделать самому» на nginx

Помимо связки «Nginx + статические превью», на рынке существует отдельный класс программного обеспечения — самостоятельно устанавливаемые галерейные CMS для фотографов с открытым кодом. Они добавляют то, что руками писать долго: личный кабинет для выбора кадров клиентом, отметки «нравится», автоматическую генерацию превью с водяным знаком из панели администратора, разграничение альбомов по клиентам через интерфейс, а не через ручное редактирование конфига Nginx.

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

Когда стоит остаться на «ручном» варианте с Nginx и скриптом на ImageMagick, а когда переходить на готовую CMS — вопрос объёма и повторяемости задачи:

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

Что это меняет в восприятии студии и в деньгах

Клиентская галерея на своём домене — это не техническая деталь, это часть того, как клиент воспринимает уровень студии до того, как оценит саму съёмку. Разница ощущается сразу:

• Первое впечатление формируется адресом в браузере. gallery.вашастудия.ru выглядит как продолжение сайта студии. Домен облачного сервиса — как временное решение «на коленке».
• Водяной знак на превью — не только защита, но и реклама. Клиент листает кадры с ненавязчивой подписью студии и, пересылая ссылку друзьям «посмотреть, как меня сфотографировали», невольно показывает бренд ещё до момента, когда те станут вашими клиентами.
• Отсутствие лимитов чужого тарифа снимает тревогу «а вдруг место кончится посреди сезона». Место на арендованном сервере считается заранее, под ваш реальный объём заказов, а не под условия бесплатного тарифа, рассчитанного на частного пользователя, а не на студию с потоком клиентов.
• Контроль над сроком жизни галереи — это и порядок, и экономия. Закрыли доступ через два месяца после сдачи — освободили место под новые заказы, не потеряв возможность восстановить архив из бэкапа при необходимости. Про то, как вообще устроено резервное копирование недорого и без переусложнения, есть отдельный разбор: правило 3-2-1 для бэкапов без лишних трат.

Ничего из этого не заменяет качество съёмки — но подача решает, воспримет ли клиент студию как систему, которой можно доверить следующий заказ и порекомендовать друзьям, или как разовую услугу «сняли, скинули в облако, разошлись».

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