Firefly III или Actual Budget: что выгоднее и когда

MAATRIX

Когда решаете вести личные финансы на своём сервере, а не в облачном сервисе с иностранным биллингом, выбор почти всегда сужается до двух проектов — Firefly III и Actual Budget. Оба open-source, оба бесплатны, оба разворачиваются на скромном VPS за полчаса. Но это разные философии учёта: один — классический бухгалтерский журнал с двойной записью и отчётами, второй — конвертная система планирования бюджета, знакомая тем, кто пользовался YNAB. Разбираемся, чем они отличаются на практике и какой выбрать под ваш сценарий.

Что у них общего

И Firefly III, и Actual Budget решают одну задачу — заменить облачный финансовый сервис на приложение, данные которого не покидают ваш сервер. У обоих:

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

На этом сходство заканчивается — дальше начинаются принципиально разные модели данных и разный опыт использования изо дня в день.

Метод учёта: двойная запись против конвертов

Это главное отличие, и от него стоит отталкиваться в первую очередь.

Firefly III — классическая система двойной записи (double-entry bookkeeping). Каждая транзакция — перевод денег между двумя счетами: с зарплатного счёта на карту, с карты — в категорию расхода. Это даёт точную картину движения средств, детальные отчёты по каждому счёту и категории, поддержку сложных сценариев (несколько банковских счетов, инвестиции, долги между людьми). Подходит тем, кто хочет видеть финансы «как бухгалтер» — с историей, графиками и возможностью выгрузить отчёт за любой период.

Actual Budget реализует envelope budgeting — метод конвертов, тот же принцип, что и в YNAB: каждый поступивший рубль вы сразу распределяете по «конвертам» (категориям) на месяц вперёд, и тратите строго в рамках выделенного. Система толкает к дисциплине планирования, а не к постфактум-анализу трат. Отчётов меньше, зато сам процесс бюджетирования нагляднее и требует меньше кликов в повседневном использовании.

Если вам важно понять, куда делись деньги за прошлый год — ближе Firefly III. Если важнее не превысить бюджет на продукты в этом месяце — ближе Actual Budget.

Технологический стек и требования к серверу

Actual Budget архитектурно проще для self-хостинга: один контейнер с встроенной SQLite-базой, без отдельного сервера СУБД и миграций между сервисами. Firefly III тянет за собой полноценную реляционную базу — MySQL/MariaDB или PostgreSQL — что даёт гибкость для отчётов и внешних интеграций ценой лишних движущихся частей.

Разница в требованиях к RAM на практике не критична — оба приложения комфортно работают на минимальных тарифах VPS с 1 ГБ памяти при личном использовании. Ощутима разница не в ресурсах, а в количестве сервисов, которые нужно поддерживать и обновлять синхронно.

Установка: сколько шагов и что получится

Firefly III в Docker Compose — минимум два сервиса (firefly_app + firefly_db), плюс опциональный cron-контейнер для повторяющихся транзакций. Мы разбирали это пошагово в статье про установку Firefly III на Ubuntu 24.04 — там же переменные окружения, docker-compose.yml целиком и настройка обратного прокси.

Actual Budget разворачивается заметно компактнее — официальный образ actualbudget/actual-server поднимает всё в одном контейнере:

services:
  actual:
    image: actualbudget/actual-server:latest
    container_name: actual
    restart: unless-stopped
    ports:
      - "127.0.0.1:5006:5006"
    volumes:
      - actual_data:/data

volumes:
  actual_data:

mkdir -p ~/actual-budget && cd ~/actual-budget
# сохраните docker-compose.yml выше
docker compose up -d

Никакой отдельной базы данных настраивать не нужно — SQLite-файл создаётся автоматически внутри volume /data. При первом заходе на http://127.0.0.1:5006 (через обратный прокси — на домен) Actual Budget попросит задать пароль сервера и создать первый бюджет.

Для HTTPS-обвязки в обоих случаях подходит одна и та же схема — Nginx на хосте как обратный прокси плюс Let's Encrypt, но у Actual Budget конфиг важно дополнить блоком апгрейда протокола:

server {
    listen 80;
    server_name budget.example.com;

    location / {
        proxy_pass http://127.0.0.1:5006;
        proxy_set_header Host $host;
        proxy_set_header X-Real-IP $remote_addr;
        proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
        proxy_set_header X-Forwarded-Proto $scheme;

        # Actual Budget использует WebSocket для realtime-синхронизации
        proxy_http_version 1.1;
        proxy_set_header Upgrade $http_upgrade;
        proxy_set_header Connection "upgrade";
    }
}

Без блока Upgrade/Connection клиент Actual Budget будет постоянно переподключаться — в отличие от Firefly III, который ходит по обычному HTTP без WebSocket. Дальше — стандартно: sudo certbot --nginx -d budget.example.com. Если раньше не настраивали прокси с апгрейдом протокола, общие принципы разобраны в статье про Traefik как reverse proxy для Docker.

Мобильный доступ и офлайн-работа

Здесь разница между архитектурами становится ощутимой на практике, а не только на бумаге.

Firefly III — это веб-интерфейс, который открывается в браузере (в том числе мобильном) или через сторонние клиенты на его REST API. Официального нативного приложения с полноценным офлайном нет; без соединения с сервером приложение недоступно.

Actual Budget изначально спроектирован как local-first: клиент (веб или desktop на Electron) хранит полную копию бюджета локально и работает без сети — вносите траты в метро без связи, а при появлении интернета изменения синхронизируются с сервером через CRDT-механизм слияния, обычно без ручного разрешения конфликтов. Есть официальные приложения для iOS и Android с той же логикой офлайн-работы.

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

Отчётность и глубина анализа

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

Actual Budget делает акцент на самом процессе распределения денег по категориям здесь и сейчас — отчётов меньше (баланс категорий, история за период), зато интерфейс планирования бюджета продуман тщательнее: перенос неизрасходованного остатка в следующий месяц, быстрое перераспределение между категориями drag-and-drop, наглядный «to be budgeted» — сколько денег ещё не распределено.

Если задача — разобраться, сколько вы потратили на такси за прошлый год и как это соотносится с зарплатой, берите Firefly III. Если задача — не выйти за рамки месячного бюджета на конкретные статьи расходов, Actual Budget справится с меньшим количеством лишних действий.

Бэкапы и обслуживание

Модель бэкапа напрямую следует из архитектуры хранения.

Firefly III: дамп реляционной базы (mysqldump или pg_dump) плюс volume с загруженными файлами (чеки, вложения). Два разных типа данных, два шага в скрипте бэкапа — подробный пример скрипта и cron-задачи есть в статье про установку Firefly III.

Actual Budget: весь бюджет — это один SQLite-файл внутри volume. Бэкап сводится к копированию файла или архивации директории данных:

mkdir -p ~/actual-budget/backups
cat > ~/actual-budget/backup.sh <<'EOF'
#!/bin/bash
set -e
cd ~/actual-budget
TIMESTAMP=$(date +%Y%m%d_%H%M%S)
docker compose exec -T actual sh -c "tar czf - -C /data ." > backups/actual_${TIMESTAMP}.tar.gz
find backups/ -name "actual_*.tar.gz" -mtime +14 -delete
EOF
chmod +x ~/actual-budget/backup.sh
(crontab -l 2>/dev/null; echo "0 3 * * * /home/$USER/actual-budget/backup.sh") | crontab -

Простота SQLite — не только плюс: на очень больших объёмах транзакций реляционная СУБД с индексами и оптимизатором запросов, как в Firefly III, масштабируется предсказуемее. Для личного и семейного бюджета этот порог практически недостижим, но стоит иметь в виду для учёта малого бизнеса.

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

Когда выбрать что

Если сомневаетесь — поднимите оба на одном недорогом VPS параллельно (благо ресурсов на это хватает с запасом) и попробуйте вести один и тот же месяц в каждом. Через неделю станет ясно, какой процесс — «разбор полётов по отчётам» или «распределение конвертов на старте месяца» — вам ближе. Мигрировать данные между ними в готовом виде не получится: у проектов разные модели данных, и импортировать историю придётся вручную через CSV-экспорт транзакций.

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