НКО: грант требует отчётности, бюджета на SaaS нет — что поднять на одном VPS

MAATRIX

Грант выигран, деньги пришли — и тут же выясняется, что грантодатель хочет не просто отчёт «на что потратили», а построчную разбивку расходов по статьям бюджета, сканы первички и подтверждение, что проект вообще существует и виден публично. У штатной бухгалтерии НКО обычно нет, у координатора проекта — экселька и папка на телефоне с фото чеков. Купить под это три-четыре платных сервиса (учёт, хранилище документов, сайт) — значит потратить на подписки заметную часть тех же грантовых денег, которые должны были пойти на программную деятельность. Разберём, как закрыть все три задачи открытыми инструментами на одном недорогом VPS — без ежемесячных счетов от SaaS-провайдеров.

Грант требует отчётности, а бюджета на инструменты нет — суть проблемы

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

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

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

Технически все три задачи не требуют трёх разных облачных подписок. Это три относительно лёгких веб-приложения, которые прекрасно уживаются на одном сервере с общим Docker и одним обратным прокси.

Три задачи, которые правда нужны НКО, и почему их не пять

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

1. Учёт расходов по проекту — нужна не полноценная бухгалтерия с проводками и балансом (для этого в России юридически всё равно требуется 1С или бухгалтер на аутсорсе), а инструмент, который позволяет разнести операции по статьям бюджета, прикрепить сумму к конкретной строке сметы и в конце периода выгрузить отчёт «план vs факт» по каждой статье.
2. Хранилище и документооборот для отчётности — место, куда координатор проекта фотографирует чек прямо на месте, документ автоматически распознаётся (OCR), помечается тегами (проект, статья бюджета, дата) и лежит там, где его не потеряют при смене телефона или увольнении волонтёра.
3. Сайт проекта — не интернет-магазин и не сложный портал, а простая витрина: о проекте, о команде, новости, контакты, иногда форма для пожертвований или подписки на новости. Задача — существовать в интернете и быть проверяемым, а не конкурировать по функциональности с корпоративным сайтом.

Ключевой момент: все три задачи — это классические self-hosted веб-приложения на PHP/Python с базой данных, каждое из которых спокойно работает в собственном Docker-контейнере. Ни одному из них не нужен отдельный сервер — они делят один и тот же VPS, потому что нагрузка на НКО-масштабе (штат из нескольких человек и волонтёров, десятки-сотни операций и документов в месяц) для современного сервера ничтожна.

Какой VPS взять, если бюджет ограничен

Для связки «учёт бюджета + архив документов с OCR + лёгкий сайт» с запасом хватает конфигурации среднего уровня: 2 vCPU, 4 ГБ RAM, 40–60 ГБ SSD. Это ориентир, а не жёсткий расчёт — нагрузка зависит от того, сколько документов в месяц прогоняется через распознавание и сколько человек одновременно работает в системе учёта. Если сомневаетесь — начните с этой конфигурации и следите за памятью первые пару недель: проще вырасти на тариф выше, чем переплачивать за мощности, которые НКО не выберет.

Важные для НКО практические моменты при выборе сервера:

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

Учёт расходов по проекту: Firefly III вместо экселя и платного сервиса

Firefly III — открытый инструмент учёта финансов с двойной записью, категориями, бюджетами по периодам и тегами. Изначально он делался для личных финансов, но для НКО это удобная база под грантовую отчётность: заводите «счёт» на каждый источник финансирования (транш гранта, членские взносы, пожертвования), категории — под статьи утверждённого бюджета, а бюджеты Firefly III (не путать с бюджетом гранта) используйте как лимит по статье на период, с индикатором «сколько уже потрачено из выделенного».

Готовый docker-compose для Firefly III и разбор его переменных окружения есть в отдельном материале — см. Firefly III в Docker Compose. Минимальный набор сервисов — сам Firefly III и база MySQL/MariaDB:

services:
  firefly-db:
    image: mariadb:11
    restart: unless-stopped
    environment:
      MYSQL_RANDOM_ROOT_PASSWORD: "yes"
      MYSQL_DATABASE: firefly
      MYSQL_USER: firefly
      MYSQL_PASSWORD_FILE: /run/secrets/firefly_db_password
    volumes:
      - firefly_db:/var/lib/mysql
    secrets:
      - firefly_db_password

  firefly:
    image: fireflyiii/core:latest
    restart: unless-stopped
    depends_on:
      - firefly-db
    env_file: firefly.env
    volumes:
      - firefly_upload:/var/www/html/storage/upload
    expose:
      - "8080"

volumes:
  firefly_db:
  firefly_upload:

secrets:
  firefly_db_password:
    file: ./secrets/firefly_db_password.txt

Ключевые настройки в firefly.env, на которые стоит обратить внимание для НКО-сценария: APP_URL — на реальный поддомен, TRUSTED_PROXIES=** при работе за реверс-прокси, и DEFAULT_LANGUAGE=ru для комфорта волонтёров, которые не обязаны знать английский бухгалтерский жаргон. Заведите отдельного пользователя Firefly III на каждого, кто вносит операции — так в конце отчётного периода видно, кто и что провёл, что снимает часть вопросов при внутренней проверке перед сдачей отчёта.

Если структура расходов у вас проще — один общий счёт, без разбивки по нескольким источникам одновременно — присмотритесь к более лёгкой альтернативе, Actual Budget: она заметно легче по ресурсам и проще в освоении для человека без опыта работы с учётными системами. Сравнение подходов и того, когда какой инструмент оправдан, разобрано в статье Firefly III или Actual Budget: что выгоднее и когда.

Хранилище и документооборот для отчёта перед грантодателем: Paperless-ngx

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

Paperless-ngx — открытая система архивирования документов с автоматическим OCR (распознаванием текста со сканов и фотографий), полнотекстовым поиском и тегами. Рабочий сценарий для НКО: волонтёр фотографирует чек на телефон, скидывает фото в папку синхронизации (вход через email-ящик или consume-папку с автоподхватом файлов), система распознаёт текст, дату и сумму, а координатор проставляет тег со статьёй бюджета и названием гранта.

Готовый docker-compose и разбор используемых томов — в статье Paperless-ngx в Docker Compose. Для НКО-сценария важны три момента при настройке:

• Тегирование по гранту и статье бюджета с первого дня. Заводите тег на каждый действующий грант отдельно — когда грантов у организации несколько одновременно (а это обычная ситуация), смешанный архив без чёткой разметки при подготовке отчёта превращается в отдельный проект по разбору документов.
• Consume-папка через WebDAV или Nextcloud-клиент, а не только веб-загрузка вручную — тогда волонтёр в поле может просто сохранить фото в общую папку с телефона, не заходя в веб-интерфейс.
• Срок хранения — том с оригиналами документов (PAPERLESS_CONSUMER_POLLING и каталог media/documents/originals) должен попадать в бэкап-политику отдельно и с более длинным сроком хранения архивных копий, чем у остальных данных: условия гранта могут требовать доступности документов через несколько лет после закрытия проекта, когда сама организация уже, возможно, не будет активно вести эту систему.

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

Сайт проекта и как всё это уживается на одном сервере

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

Три приложения на одном VPS — это не хаос, если развести их по поддоменам через общий обратный прокси. Практическая схема:

budget.example-nko.org   → Firefly III  (только для сотрудников, доступ по паролю + желательно IP-фильтр)
docs.example-nko.org     → Paperless-ngx (только для сотрудников)
example-nko.org          → сайт проекта (публичный)

Caddy в роли реверс-прокси берёт на себя и маршрутизацию по поддоменам, и выпуск TLS-сертификатов Let's Encrypt автоматически — заводить их вручную для каждого поддомена не нужно:

budget.example-nko.org {
    reverse_proxy firefly:8080
}

docs.example-nko.org {
    reverse_proxy paperless-webserver:8000
}

example-nko.org, www.example-nko.org {
    root * /var/www/site
    file_server
}

Общая логика разнесения сервисов по поддоменам на одном VPS и типовые грабли (конфликты портов, общая база vs отдельные базы на контейнер) разобраны в статье Настройка нескольких сайтов на одном VPS — она написана не под НКО-сценарий конкретно, но принцип тот же самый: один сервер, общий Docker, общий прокси, изолированные контейнеры с отдельными базами данных под каждое приложение.

Отдельно про безопасность: Firefly III и Paperless-ngx содержат финансовые и персональные данные, поэтому им не место в открытом доступе. Простейшая защита — Basic Auth на уровне Caddy поверх штатной авторизации приложения плюс ограничение доступа по IP, если у сотрудников НКО статичные адреса или VPN. Двойная защита не избыточна: одного логина-пароля от веб-приложения, слитого фишингом, недостаточно, чтобы получить доступ к архиву чеков и договоров всей организации.

И последнее по важности, но не по значимости: бэкапы. Потеря базы Firefly III перед сдачей отчёта или архива Paperless-ngx с оригиналами документов — это не просто неудобство, это риск не подтвердить целевое расходование гранта и испортить отношения с грантодателем на будущее. Ежедневный дамп баз данных и еженедельный полный бэкап файловых томов на отдельное хранилище (не на тот же диск, где крутится VPS) — это буквально несколько строк в cron и одна переменная окружения для шифрования архива. На это стоит закладывать время при первичной настройке сервера, а не откладывать «после отчёта».

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