Сколько RAM нужно для Firefly III

MAATRIX

Firefly III — один из самых лёгких self-hosted сервисов, который вообще имеет смысл разворачивать на отдельном VPS: классическое Laravel-приложение без очередей задач, без Elasticsearch и без тяжёлых фоновых воркеров. Именно из-за этого легко ошибиться в обе стороны — взять сервер на 4 ГБ «на вырост» для домашнего бюджета одного человека, либо наоборот, впихнуть его на самый дешёвый тариф вместе с базой, которая после года истории транзакций начинает просить больше памяти на буфер. Разберём, из чего складывается расход по компонентам, что происходит при импорте выписки за несколько лет и какой сервер брать под личный бюджет и под бюджет семьи или небольшой компании.

Из чего состоит Firefly III и что реально ест память

Firefly III — веб-приложение на PHP (Laravel), которое разворачивается связкой из трёх-четырёх компонентов, если ставить официальным Docker-образом:

• PHP-FPM — обрабатывает запросы: страницы бюджета, отчёты, графики, API. Каждый воркер держит в памяти загруженный Laravel-контейнер — основной потребитель под нагрузкой, но у личного трекера этой нагрузки объективно немного.
• MySQL/MariaDB или PostgreSQL — хранит счета, транзакции, категории, правила автокатегоризации. Растёт со временем не от числа пользователей, а от объёма истории и количества правил, которые база прогоняет при каждом импорте.
• Nginx или Apache — веб-сервер перед PHP-FPM, по памяти почти не заметен.
• Cron — раз в сутки нужен внешний вызов (artisan firefly-iii:cron) для повторяющихся транзакций, напоминаний о счетах и курсов валют. Не демон, а разовый процесс, но в момент запуска он поднимает полноценный PHP-процесс поверх уже работающего FPM-пула.

Отдельно стоит Firefly III Data Importer — приложение для импорта банковских выписок (CSV, camt.053, GoCardless/Nordigen). Это отдельный Docker-контейнер, а не часть основного образа, и именно он чаще всего оказывается неожиданной статьёй расхода у тех, кто считал только основной сервис.

Ключевая особенность для расчёта: Firefly III не держит долгоживущее состояние между запросами и не требует Redis или очередей по умолчанию. Аппетит к памяти растёт не линейно с числом счетов, а скачком в моменты импорта большой выписки и построения годовых отчётов с сотнями правил.

Короткий ответ: сколько закладывать

Ориентир для связки nginx + PHP 8.3-FPM + MariaDB (или PostgreSQL 16) на Ubuntu 24.04. Это не измеренный бенчмарк, а практический диапазон — конкретные цифры сдвинутся в зависимости от числа правил и глубины истории.

Строчку вниз двигает не число «пользователей» (в Firefly III обычно один аккаунт на семью с несколькими счетами), а глубина истории и число активных правил автокатегоризации — каждое правило прогоняется по каждой новой транзакции при импорте. Диск не имеет прямого отношения к оперативной памяти: база данных с десятилетней историей занимает считаные сотни мегабайт на диске, а в память попадает лишь то, что реально запрашивается.

Почему официальный минимум обманчив

В документации Firefly III указан скромный минимум по железу — около 512 МБ RAM для самого приложения, и формально это правда: PHP-код и веб-сервер в простое действительно укладываются в эти рамки. Но в требованиях не учтена база данных рядом, и это то же расхождение, что и у многих PHP-приложений: минимум описывает код, а не систему целиком.

MariaDB с настройками по умолчанию плюс пара воркеров PHP-FPM, nginx, systemd и SSH на 512 МБ почти не оставляют запаса — свободного места на импорт выписки за несколько лет уже не остаётся. Типичная картина в dmesg -T | tail:

mariadbd invoked oom-killer: gfp_mask=0x140cca, order=0, oom_score_adj=0
Out of memory: Killed process 1142 (mariadbd) total-vm:612340kB,
anon-rss:298120kB, file-rss:0kB, shmem-rss:0kB, UID:111 oom_score_adj:0

Убивает ядро обычно не сам PHP-процесс, вызвавший скачок, а самый прожорливый сосед — то есть базу. Отсюда типичная жалоба «Firefly III перестал открываться после импорта выписки»: в логах Laravel (storage/logs/laravel.log) может быть чисто, процесс убили снаружи, а не изнутри приложения.

SQLite снижает требования, но не для всех сценариев. Firefly III поддерживает SQLite как альтернативу полноценной СУБД — не нужен отдельный процесс базы. Но SQLite плохо переживает параллельный доступ (веб-интерфейс плюс запрос от Data Importer) и официально не рекомендуется при нескольких клиентах — только для строго единоличного использования.

Как замерить память своей установки

В контейнерной установке docker stats даёт быструю оценку по каждому контейнеру:

docker stats --no-stream --format "table {{.Name}}\t{{.MemUsage}}\t{{.MemPerc}}"

NAME                    MEM USAGE / LIMIT
firefly_iii_core        180MiB / 1.909GiB
firefly_iii_db          210MiB / 1.909GiB
firefly_iii_importer    95MiB / 1.909GiB

Это снимок в простое — под нагрузкой (страница отчёта с графиками за год, идущий импорт) цифры для firefly_iii_core и firefly_iii_db вырастут в полтора-два раза, и именно этот пик нужно закладывать в тариф, а не состояние покоя.

Пик, а не текущее значение. При установке через systemd-юниты ядро Ubuntu 24.04 (cgroup v2) хранит исторический пик по каждому сервису:

systemctl show -p MemoryCurrent --value php8.3-fpm
cat /sys/fs/cgroup/system.slice/php8.3-fpm.service/memory.peak

available, а не free. На загруженной несколько дней машине колонка free покажет мало — Linux отдал остаток под дисковый кеш:

               total        used        free      shared  buff/cache   available
Mem:            1968         612         84         38        1272        1180
Swap:           2047           0        2047

Занято 612 МБ, свободно всего 84, но реально доступно 1180 МБ — колонка available и есть та цифра, за которой стоит следить. Тревожный сигнал — не «мало free», а падение available ниже 15% от total и рост Swap used изо дня в день.

Что реально удваивает потребление

У Firefly III список «прожорливых опций» короткий — большинство функций встроены и почти не влияют на RAM. Но три вещи заметно двигают цифру.

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

Рабочий конфиг под 1 ГБ

Расклад для одного человека или семьи из 2-3 счетов, MariaDB как СУБД: 1024 МБ минус система и SSH (150 МБ) минус MariaDB (300 МБ) минус nginx (20 МБ) — остаётся около 550 МБ на PHP-FPM.

; /etc/php/8.3/fpm/pool.d/firefly.conf
pm = ondemand
pm.max_children = 5
pm.process_idle_timeout = 15s
pm.max_requests = 300
php_admin_value[memory_limit] = 256M

ondemand вместо dynamic — воркеры поднимаются под запрос и умирают через 15 секунд простоя, что экономит память в часы, когда сервисом никто не пользуется.

База — консервативно:

[mysqld]
innodb_buffer_pool_size = 192M
innodb_log_file_size    = 48M
max_connections         = 20
performance_schema      = OFF

Если предпочитаете PostgreSQL (поддерживается официально), аналогичная логика применима к shared_buffers и max_connections — подробнее в статье про установку и настройку PostgreSQL на VPS. Выбор между MySQL/MariaDB и PostgreSQL здесь — вопрос личных предпочтений, а не производительности: обе базы для объёма данных личного бюджета работают с большим запасом.

Ещё две вещи, которые окупаются на 1 ГБ:

• Swap на 1-2 ГБ. На старых образах VPS файла подкачки часто нет вообще — проверьте swapon --show, если пусто: fallocate -l 2G /swapfile && chmod 600 /swapfile && mkswap /swapfile && swapon /swapfile плюс строка в /etc/fstab. Подробнее — в статье про правильный размер swap для VPS. Это подушка на пик импорта, а не замена оперативной памяти.
• Data Importer — по требованию, а не постоянно. Если импорт выписки разовый (раз в неделю), контейнер firefly_iii_importer можно поднимать командой docker compose up importer только на время импорта и останавливать после — освобождённые 80-150 МБ на слабом тарифе заметны.

Если после этих настроек сервис всё равно подтормаживает без явной причины, не факт, что дело в памяти — общий чек-лист в статье что делать при нехватке RAM.

Какой сервер под Firefly III взять в MAATRIX

Честный минимум: 1 vCPU, 1 ГБ RAM, 20 ГБ NVMe. Для одного человека или небольшой семьи, отслеживающих бюджет по нескольким счетам, этого достаточно с запасом, если не импортировать одним файлом сразу несколько лет истории. MariaDB, пять воркеров PHP-FPM в режиме ondemand, cron раз в сутки — всё укладывается комфортно.

Комфортный вариант: 1 vCPU, 2 ГБ RAM, 40 ГБ NVMe. Подходит, если держите Data Importer постоянно запущенным, регулярно импортируете выписки через GoCardless/Nordigen по расписанию или строите отчёты за несколько лет с десятками правил категоризации.

Общий бюджет компании или большой семьи: 2 vCPU, 4 ГБ RAM, 80 ГБ NVMe. Если сервисом пользуются 5-10 человек с общим доступом, историей за много лет и десятками активных правил, второе ядро снимает конкуренцию между построением отчётов и обработкой текущих запросов.

Локация — по расположению основных пользователей. Firefly III не требователен к сетевой задержке — это не сервис реального времени, а веб-интерфейс с редкими обращениями. Для российской аудитории логичнее локация в России; для тех, кто хочет данные о личных финансах физически за пределами страны, Лондон не создаст заметной разницы в отзывчивости даже при RTT 40-50 мс.

Firefly III из каталога apps.maatrix.io разворачивается на сервер автоматически при заказе — вручную поднимать Docker Compose не нужно. Адрес, логин и данные доступа появляются в личном кабинете сразу после установки. Оплата — картами российских банков, по СБП, криптовалютой или токеном MAAT, иностранная карта не требуется даже для зарубежных локаций.

Сомневаетесь между 1 и 2 ГБ — критерий простой: держите ли Data Importer постоянно включённым и импортируете ли выписки большими файлами. Держите — берите 2 ГБ, для разового импорта раз в месяц хватит минимального тарифа. Из смежного пригодится статья про оптимизацию MySQL под 1 ГБ RAM — большинство советов оттуда применимо и к базе Firefly III.

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