Event-агентство: тайминги, подрядчики и файлы мероприятия в одном месте без SaaS

MAATRIX

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

Почему инструмент на каждую задачу — это дорого и неудобно

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

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

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

Тайминг: расписание дня, которое видят все участники

Тайминг мероприятия — это не просто список задач, а расписание с точным временем: 09:00 заезд бригады декора, 11:30 саундчек, 14:00 доставка кейтеринга, 15:00 приезд гостей, 15:45 начало церемонии. У каждой позиции — ответственный, и у каждого ответственного должна быть возможность отметить «сделано» без звонка координатору.

Для такой задачи хорошо ложится связка календаря и канбан-доски. На своём сервере это, например, Nextcloud с приложениями Calendar и Deck (или Tasks): в календаре — минутный тайминг дня как события с точным временем начала, в Deck — доска по стадиям подготовки («Забронировано» → «Подтверждено» → «Оплачено» → «На площадке»). Отдельно можно поднять Vikunja или Plane — более специализированный таск-трекер с представлением в виде диаграммы Ганта, что удобно для многонедельной подготовки крупного мероприятия, где важно видеть зависимости («декор монтируется после того, как сцена собрана»).

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

# Пример структуры календарей в Nextcloud для одного агентства
Календари:
  - "Тайминги — активные мероприятия"   (общий, видят все координаторы)
  - "Тайминг: Свадьба Ивановых 12.09"    (детальный, только команда проекта)
  - "Бронирования площадок"              (общий ресурс, видят все)
  - "Личные дедлайны"                    (индивидуальный на сотрудника)

Подрядчики: кейтеринг, звук, декор — статусы и контакты в одном месте

На среднее мероприятие агентство привлекает от пяти до пятнадцати подрядчиков: кейтеринг, звукооператор, диджей или ведущий, декоратор, флорист, фотограф, видеооператор, аренда мебели, транспорт, охрана. У каждого — свой контакт, свои условия оплаты, свой статус («договорились устно» → «выставлен счёт» → «оплачен аванс» → «подтвердил дату»). Держать это в переписке в мессенджере означает терять статус подрядчика в тот момент, когда он нужнее всего — за три дня до мероприятия, когда надо быстро понять, кто ещё не подтвердил приезд.

Здесь хорошо работает табличная база данных вместо классического таск-трекера — потому что подрядчик это не задача, а сущность с набором атрибутов и связью с конкретным мероприятием. На своём сервере это NocoDB или Baserow: разворачиваете один контейнер, получаете интерфейс в духе Airtable, где заводите таблицы «Мероприятия», «Подрядчики», «Контракты», связываете их между собой (одно мероприятие — много подрядчиков, один подрядчик — много мероприятий за сезон, значит видно историю сотрудничества и можно быстро найти проверенного декоратора вместо поиска нового).

# docker-compose.yml — минимальный NocoDB для базы подрядчиков
version: "3"
services:
  nocodb:
    image: nocodb/nocodb:latest
    restart: unless-stopped
    ports:
      - "8080:8080"
    volumes:
      - ./nocodb-data:/usr/app/data
    environment:
      NC_DB: "pg://postgres:5432?u=nocodb&p=CHANGE_ME&d=nocodb"

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

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

Файлы мероприятия: сметы, договоры, макеты без потери версий

Файлы одного мероприятия — это смета в трёх редакциях (черновая, согласованная с клиентом, финальная с учётом правок), подписанный договор, бриф для декоратора, макеты пригласительных и баннеров, фотографии площадки для флориста, а после самого мероприятия — фотоотчёт от фотографа, который может весить десятки гигабайт. Если часть этого лежит в почте, часть — в личном облаке менеджера, а часть — в переписке с клиентом, найти актуальную версию через полгода, когда клиент возвращается с повторным заказом, реально тяжело.

Единое файловое хранилище с версионированием закрывает это одним приёмом: структура папок по мероприятиям, где у каждого файла видна история изменений и автор правки. В Nextcloud версии файлов хранятся автоматически при каждом сохранении, а Groupfolders позволяет создать общую папку на команду с ролями («менеджер проекта — редактирование», «подрядчик — только просмотр своей подпапки», «клиент — просмотр финального макета по ссылке»).

/Мероприятия/
  /2026-09-12_Свадьба-Ивановых/
    /01_Договор/
    /02_Смета/
      смета_v1_черновик.xlsx
      смета_v2_согласовано_с_клиентом.xlsx
      смета_v3_финал.xlsx
    /03_Макеты/
      пригласительные_финал.pdf
    /04_Бриф_подрядчикам/
    /05_Фотоотчет/

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

Важный нюанс с фотоотчётами: если агентство само нанимает фотографа и получает от него отснятый материал, объём за сезон легко переваливает за несколько терабайт. Держать это на диске VPS с NVMe — не всегда экономически оправдано; для архива готовых фотоотчётов имеет смысл отдельный более дешёвый блочный или объектный диск, подключённый к тому же серверу, а рабочие файлы текущих мероприятий — на быстром SSD.

Как собрать это на своём сервере: конкретный стек

Для агентства, которое ведёт одновременно 5-15 активных мероприятий, разумный стартовый стек — три компонента поверх одной СУБД:

Все три можно поднять как отдельные Docker-контейнеры на одном VPS через docker-compose, с общим reverse-proxy (например, Caddy или Traefik) и отдельными поддоменами: files.ваш-домен.ru, tasks.ваш-домен.ru, crm.ваш-домен.ru. Единая точка входа для сотрудников — просто закладка на три ссылки; авторизацию можно унифицировать через Keycloak или через встроенный LDAP-модуль Nextcloud, если хочется единого логина, но для агентства из 5-15 человек это обычно избыточно — проще завести отдельные аккаунты в каждом сервисе один раз.

# docker-compose.yml — каркас на три сервиса + Postgres
version: "3.8"
services:
  db:
    image: postgres:16
    restart: unless-stopped
    environment:
      POSTGRES_PASSWORD: CHANGE_ME
    volumes:
      - ./pgdata:/var/lib/postgresql/data

  nextcloud:
    image: nextcloud:latest
    restart: unless-stopped
    depends_on: [db]
    ports: ["8081:80"]
    volumes:
      - ./nextcloud-data:/var/www/html

  vikunja:
    image: vikunja/vikunja:latest
    restart: unless-stopped
    depends_on: [db]
    ports: ["3456:3456"]
    volumes:
      - ./vikunja-files:/app/vikunja/files

  nocodb:
    image: nocodb/nocodb:latest
    restart: unless-stopped
    depends_on: [db]
    ports: ["8080:8080"]
    volumes:
      - ./nocodb-data:/usr/app/data

По железу для такого набора на 5-15 активных мероприятий с несколькими сотнями гигабайт файлов достаточно VPS среднего уровня — несколько ядер, 8 ГБ памяти хватает под три сервиса и Postgres с запасом, диск подбирается уже под объём фотоотчётов и макетов, а не под саму нагрузку сервисов. Дальнейший рост — это в первую очередь диск под архив, ресурсы CPU/RAM трём этим сервисам нужны скромные даже при активном использовании командой из десяти-пятнадцати человек.

Доступ команде и подрядчикам в день мероприятия

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

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

Доступ снаружи стоит закрыть через reverse-proxy с TLS-сертификатом (Let's Encrypt через Caddy поднимается автоматически) и минимум — через fail2ban на форму логина, чтобы не ловить перебор паролей на публично доступной панели. Для сотрудников, которые ходят в систему только из офиса, разумно дополнительно ограничить доступ по IP или через WireGuard-туннель, оставив снаружи открытыми только те публичные ссылки, которые вы сами выдали.

# Caddyfile — пример TLS и проксирования для трёх сервисов
files.example.ru {
    reverse_proxy nextcloud:80
}
tasks.example.ru {
    reverse_proxy vikunja:3456
}
crm.example.ru {
    reverse_proxy nocodb:8080
}

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