Свой файловый портал для дизайнеров: большие макеты, версии и согласование

Файл «финал_новый_точно.psd» лежит в папке рядом с «финал_новый_точно2.psd» и «финал_правки_Маша.psd». Клиент написал в мессенджере: «Да, согласовано». Вопрос: что именно? Тот файл, который вы отправили в четверг? Или тот, что поправили в пятницу и положили под тем же именем? Имя файла в такой ситуации ничего не доказывает: оно изменяемо, и каждый, у кого есть доступ, может сохранить под ним что угодно.

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

Рабочий файл и то, что ушло на согласование — это разные вещи

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

Практичное разделение выглядит так. У проекта две зоны:

• Рабочая зона — папка, куда дизайнеры сохраняют исходники. Клиент сюда не попадает. Имена файлов здесь могут быть любыми, ведь это ваша кухня.
• Зона выдачи — папка, куда вы кладёте только то, что осознанно отправляете на согласование: экспорт для просмотра и, при необходимости, исходники. Каждая редакция получает собственное имя с номером раунда, например logo-r1, logo-r2.

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

Обратите внимание на тонкость с правами. В документации по общему доступу Nextcloud есть пункт Others with access: он показывает доступ, который объект получил через родительскую общую папку. Из этого следует практическое правило: нельзя оценивать, кто видит файл, глядя только на сам файл. Если вы положили макет в папку, к которой уже открыт доступ у подрядчика или у другого клиента, он увидит и этот макет. Поэтому зону выдачи лучше строить отдельным деревом для каждого проекта и не вкладывать её в общие папки с широким доступом. Прежде чем отправлять ссылку, откройте сведения о доступе у самого файла и у его папки-родителя. Источник: Nextcloud: File sharing.

Две ссылки на один макет: «посмотреть» и «забрать исходники»

Клиент обычно хочет двух разных вещей. Арт-директору заказчика нужно открыть превью и написать, нравится ли. Его подрядчику-верстальщику потом нужны исходники. Смешивать эти сценарии в одной ссылке неудобно: либо превью открыто слишком широко, либо исходники уходят раньше согласования.

Nextcloud позволяет делать публичные ссылки и общий доступ для пользователей и групп; набор доступных опций зависит от настроек администратора, так что часть описанного ниже может быть выключена на вашем сервере. Публичной ссылке можно задать пароль и срок действия, а по истечении срока доступ по ней отключается. Это удобный механизм для нашей задачи: срок ссылки превращает «открыто навсегда, потому что забыли закрыть» в «открыто до такой-то даты».

Рабочая схема из двух ссылок:

1. Ссылка на просмотр. Ведёт на экспорт (PDF или PNG). Срок — до конца раунда согласования, обычно несколько дней. Пароль передаётся отдельным каналом.
2. Ссылка на исходники. Создаётся только после того, как клиент подтвердил конкретную редакцию. Срок короткий: достаточно, чтобы человек успел скачать архив.

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

Когда клиент сам должен прислать материалы

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

Что делает история Versions — и чего она не обещает

Теперь о самом интересном. Когда дизайнер пересохраняет файл с тем же именем, Nextcloud не затирает предыдущее содержимое безвозвратно: прежние версии доступны в разделе Versions у файла. Их можно скачать или восстановить. Для нашей задачи это существенно, потому что даже если файл перезаписан под тем же именем, прошлую редакцию часто можно достать.

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

Есть и выход: в описанной в документации схеме именованные версии исключены из автоматического удаления. То есть версию, которую вы осознанно пометили именем, политика хранения не трогает. Однако здесь стоит сделать оговорку на практике: возможность именовать версии и точная работа этого механизма зависят от установленной у вас версии Nextcloud, поэтому проверьте на своём сервере: пометьте тестовую версию и убедитесь, что соответствующая функция в интерфейсе есть. Источник: Nextcloud: Version control.

Пример: две редакции одного макета

Возьмём условный пример. Дизайнер делает лендинг, файл landing.psd лежит в зоне выдачи. В понедельник загружена первая редакция, и клиенту уходит ссылка на её превью. Во вторник клиент просит поменять заголовок, дизайнер сохраняет landing.psd заново. В среду клиент пишет: «Согласовано». А в четверг выясняется, что он имел в виду вариант с понедельника, потому что новый заголовок не понравился его коллеге.

Что у нас есть? В Versions у файла лежит понедельничная редакция. Если мы заранее дали ей имя вроде «r1, показана клиенту в понедельник», она не пропадёт по сроку хранения. Мы можем скачать её или восстановить, и спор решается фактами, а не памятью.

А теперь представим другую беду: в пятницу кто-то случайно удалил весь проект вместе с папкой, или диск сервера испортился. Здесь история версий уже не поможет: она живёт внутри той же установки Nextcloud и пропадает вместе с ней. Эту задачу решает только резервная копия, лежащая в другом месте.

Получается, что два механизма отвечают на разные вопросы:

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

Согласование привязывается к редакции, а не к имени

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

Практичный порядок:

1. Дизайнер кладёт экспорт редакции в зону выдачи под именем с номером раунда: landing-r2.pdf.
2. Если рядом лежит исходник, его текущую версию помечают именем в Versions (если эта функция есть в вашей установке), например «r2, отправлено клиенту».
3. Клиент получает ссылку на просмотр со сроком и паролем и видит имя файла с номером раунда.
4. Ответ клиента фиксируется письменно и содержит номер редакции: «Согласуем landing-r2». Фраза «согласовано» без номера не принимается — её вежливо уточняют.
5. В простом журнале проекта (таблица или текстовый файл в самой рабочей папке) появляется строка: дата, номер редакции, кто согласовал, где ответ.

Так связь «решение — конкретная версия» держится не на хрупком имени финал.psd, а на трёх вещах: номере раунда, именованной версии и записи в журнале. Если клиент через месяц скажет «а я ведь соглашался на другое», у вас есть дата, номер и файл.

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

Тяжёлые макеты: почему загрузка упирается не туда, куда думаешь

Исходники дизайнеров быстро вырастают до сотен мегабайт и гигабайт: многослойные PSD, видео, наборы шрифтов, фотографии в высоком разрешении. Тут портал впервые проявляет капризы, и логика у них неочевидная.

По документации Nextcloud, предел загрузки зависит сразу от нескольких звеньев: способа передачи файла, веб-сервера, PHP и временного хранилища. Поэтому «поднять один параметр» не всегда помогает. Кроме того, клиент синхронизации передаёт файлы частями, и значения upload_max_filesize и post_max_size могут не действовать на такую передачу так же, как на обычную загрузку через веб-форму. Практический вывод: если дизайнеры работают через десктопный клиент, они могут успешно залить файл, который браузер отвергает, и наоборот, клиенту, который грузит через веб-ссылку, потребуются другие настройки. Проверять нужно оба пути с реальным файлом нужного размера. Источник: Nextcloud: Uploading big files.

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

Условный расчёт для понимания масштаба. Допустим, максимальный файл — 4 ГБ, а в пик одновременно идут три таких загрузки. Тогда временного места понадобится порядка 12 ГБ, а не 4, и это ещё без учёта того, что в итоге файлы окажутся в основном хранилище. Если же на небольшом диске остаётся 10 ГБ свободных, то третья загрузка может оборваться на 90%, и клиент решит, что портал «ненадёжный». Это не гадание на цифрах: сложите ожидаемые параллельные загрузки, прибавьте запас и сравните со свободным местом на вашем диске.

Что это значит для выбора VPS

Портал для дизайнеров упирается прежде всего в диск и оперативную память, а процессор тут вторичен. Диск нужен под сами файлы, под историю версий (она тоже занимает место, и чем больше крупных файлов правится, тем быстрее она растёт), под временные данные загрузок и под резервные копии, если вы храните их рядом перед отправкой наружу. На VPS MAATRIX это лежит на NVMe-диске: в линейке тарифов от Ba (1 vCPU, 2 ГБ RAM, 40 ГБ NVMe) до Djed (16 vCPU, 32 ГБ, 320 ГБ) объём диска растёт вместе с остальными ресурсами. Для небольшой студии с несколькими проектами в работе реалистично смотреть на средние варианты вроде Uab (2 vCPU, 4 ГБ, 80 ГБ) или Heka (4 vCPU, 8 ГБ, 160 ГБ), а для студии с видео и тяжёлыми исходниками — на Maat (8 vCPU, 16 ГБ, 240 ГБ) и выше. Это ориентиры по ресурсам, а не обещание ёмкости: сколько клиентов и проектов выдержит ваш портал, покажет только замер на ваших файлах. Подробности и точную доступность Nextcloud с установкой, а также ОС и локации, стоит смотреть в форме заказа на странице аренды VPS MAATRIX: там указаны Nextcloud среди предлагаемых приложений, root-доступ и варианты оплаты картой РФ и СБП.

Закрытие проекта: срок ссылок, копия и проверка восстановления

Проект закончился, акт подписан. Что делать с порталом? Здесь легко оставить мусор, из-за которого через год кто-то неожиданно получит доступ к старым макетам.

Порядок закрытия, который имеет смысл:

• Отключить или дать истечь ссылкам. Ссылки со сроком отключатся сами, но проверьте, не остались ли бессрочные: пройдите по общим ссылкам проекта и по сведениям о доступе у папок.
• Пометить итоговую версию. Именованная версия финального исходника — та, которую политика хранения не удаляет (проверьте это на своей версии Nextcloud).
• Упаковать итог. Финальные экспорты, исходники и журнал решений складываются в одну архивную папку без доступа клиента.
• Убедиться, что проект есть в резервной копии.

О копии стоит сказать подробнее, потому что именно она остаётся, когда все остальные механизмы подвели. По документации Nextcloud, в перечень резервируемых частей входят config, custom apps (если они есть), data, theme и database. Если сохранить только папку data, при потере сервера вы получите файлы, но потеряете связь между ними и пользователями, ссылками и историей, которая хранится в базе. Для восстановления нужен весь набор. На время создания копии рекомендуется включать maintenance mode: он блокирует сессии и новые входы, чтобы данные не менялись в процессе и копия не получилась несогласованной. Для дизайнеров это означает договорённость: копию делаем ночью, когда никто не выгружает исходники. И наконец, документация рекомендует хранить резервные данные за пределами окружения Nextcloud: копия на том же диске не переживёт потерю этого диска. Источник: Nextcloud: Backup.

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

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

Через месяц: найти согласованное без угадывания

Вернёмся к началу. Прошёл месяц, клиент пишет: «Мы же утверждали логотип — пришлите, пожалуйста, ту версию, мне нужно в типографию». Раньше начинался квест: открыть папку, увидеть пять «финалов», сверить даты изменения, позвонить дизайнеру и спросить, какой же из них.

Теперь последовательность другая. Вы открываете журнал проекта и находите строку: «r2, согласовано, дата, письмо клиента». В зоне выдачи лежит logo-r2.pdf с таким же номером. У исходника в Versions есть именованная версия «r2, отправлено клиенту», и она не удалена политикой хранения. Вы создаёте ссылку на скачивание с коротким сроком и паролем, отправляете её клиенту и закрываете вопрос за несколько минут. Никто никого не угадывал: номер редакции, дата и ответ клиента сходятся в одном месте.

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