Сколько RAM нужно для Actual Budget

MAATRIX

Если вы решили вести бюджет по методу envelope (конвертов) и устали от подписки на YNAB или от того, что Firefly III требует отдельную базу данных и PHP-окружение, Actual Budget выглядит соблазнительно просто. Но перед тем как заказывать VPS, хочется понять — хватит ли младшего тарифа на 512 МБ или сразу брать гигабайт с запасом. Разбираемся, из чего складывается расход памяти у сервера синхронизации Actual, и на что реально рассчитывать.

Что за зверь Actual Budget и почему сервер такой лёгкий

Actual Budget — open-source приложение для бюджетирования по envelope-методу: деньги раскладываются по «конвертам»-категориям, каждый рубль получает назначение ещё до того, как будет потрачен. В этом смысле это прямой аналог YNAB, только с открытым кодом и без ежемесячной платы.

Ключевая особенность архитектуры — Actual Budget local-first. Вся логика бюджетирования, расчёт балансов, применение правил и категоризация выполняются на клиенте (в браузере или в десктоп/мобильном приложении), а не на сервере. Сервер синхронизации нужен только для одного: хранить и раздавать зашифрованный (или незашифрованный, по вашему выбору) журнал изменений между вашими устройствами. Это принципиально отличает Actual от классических серверных приложений типа Firefly III, где веб-сервер на PHP считает балансы и рендерит отчёты при каждом запросе.

Официальный образ actualbudget/actual-server написан на Node.js, данные хранит в SQLite (файл на диске, не отдельная СУБД в памяти), а начиная с версии, где в образ встроили и веб-клиент, сервер ещё и раздаёт статику фронтенда. Именно из-за того, что тяжёлые вычисления вынесены на клиент, серверу почти нечего делать — он в основном простаивает и отвечает на короткие HTTP-запросы синхронизации.

Из чего складывается расход памяти на сервере

Прежде чем говорить о цифрах, полезно понимать, что именно ест RAM в контейнере Actual:

• Рантайм Node.js — базовый оверхед виртуальной машины V8, даже без нагрузки съедает несколько десятков мегабайт.
• better-sqlite3 — нативный биндинг для работы с SQLite, лёгкий, но держит открытые файловые дескрипторы и часть страниц базы в кэше ОС.
• HTTP-сервер и обработка запросов синхронизации — каждый клиент, который синхронизируется, шлёт компактные сообщения об изменениях; сервер их валидирует и пишет в SQLite.
• Веб-клиент (если раздаётся тем же контейнером) — статические файлы, память тут почти не расходуется, это просто отдача файлов через диск/кэш.
• Docker-демон и обвязка — если считать не только сам контейнер, а всю VPS, добавьте память на сам Docker, systemd, sshd и, обычно, обратный прокси (Caddy или nginx) перед Actual.

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

Сколько RAM нужно реально

Точных официальных бенчмарков Actual Budget не публикует, а нагрузка сильно зависит от количества одновременных синхронизаций и открытых бюджетов, поэтому дальше — ориентировочные диапазоны, собранные из практики самостоятельного хостинга подобных Node.js-сервисов, а не измеренные лабораторно цифры. У вас может получиться иначе — проверяйте docker stats на своём сервере.

Это память самого процесса Actual. На неё нужно накинуть память ОС, Docker и реверс-прокси — в сумме это обычно ещё 150-300 МБ, если сервер выделен только под Actual.

Отсюда практический вывод:

• 512 МБ RAM — теоретически хватает для одиночного использования, но без запаса: если на той же VPS крутится ещё что-то (панель управления, второй контейнер, cron-бэкапы) — легко упереться в OOM Killer в моменты пиковой синхронизации.
• 1 ГБ RAM — комфортный минимум для соло или семейного использования с реверс-прокси и автоматическими бэкапами. Это тот вариант, который стоит брать по умолчанию.
• 2 ГБ RAM — с запасом, если вы планируете держать на сервере рядом ещё пару лёгких self-hosted приложений (например, тот же Firefly III или Uptime Kuma) либо обслуживать бюджет для нескольких семей.

Если сомневаетесь между 512 МБ и 1 ГБ — берите 1 ГБ. Разница в цене между тарифами обычно меньше стоимости часа на разбор, почему сервер внезапно перезагрузил контейнер под нагрузкой.

Docker Compose с адекватными лимитами памяти

Вот рабочий docker-compose.yml для Actual Budget с явными лимитами памяти — это не даёт контейнеру разрастись бесконтрольно и упасть системе целиком, если что-то пойдёт не так:

services:
  actual_server:
    image: docker.io/actualbudget/actual-server:latest
    restart: unless-stopped
    ports:
      - "5006:5006"
    volumes:
      - ./actual-data:/data
    environment:
      - ACTUAL_PORT=5006
      # Увеличить лимит размера синхронизируемого файла бюджета (по умолчанию небольшой)
      - ACTUAL_UPLOAD_FILE_SYNC_SIZE_LIMIT_MB=50
      - ACTUAL_UPLOAD_SYNCED_FILE_LIMIT_MB=50
    deploy:
      resources:
        limits:
          memory: 300M
        reservations:
          memory: 100M

Если вы запускаете не через docker compose со Swarm-подобным deploy, а обычным docker run или без Swarm-режима, лимит deploy.resources можно заменить на классический флаг:

docker run -d \
  --name actual_server \
  --restart unless-stopped \
  -p 5006:5006 \
  -v $(pwd)/actual-data:/data \
  --memory=300m \
  --memory-swap=600m \
  docker.io/actualbudget/actual-server:latest

Лимит --memory=300m со swap 600m даёт контейнеру немного пространства для маневра в пиках, но не позволяет ему съесть весь сервер. Подробнее про то, как вообще работают лимиты CPU и памяти в Docker и почему без них один контейнер может уронить соседние, разобрано в статье про лимиты ресурсов Docker.

Обязательно поставьте Actual за реверс-прокси с HTTPS (Caddy — самый простой вариант, он сам получает сертификат Let's Encrypt), не открывайте порт 5006 напрямую в интернет без TLS: в бюджете лежат данные о ваших счетах и тратах.

Какой тариф VPS выбрать

Для сравнения — как выглядят типовые конфигурации VPS применительно именно к Actual Budget:

Диск для самого Actual нужен небольшой — файл бюджета SQLite редко превышает десятки мегабайт даже за годы, но 10-15 ГБ стоит держать не столько под Actual, сколько под ОС, Docker-образы и место под бэкапы. Если вы одновременно хостите на этом же сервере сайт, почту или другие сервисы — смотрите на лучший VPS для хостинга сайтов, там разбор конфигураций под смешанную нагрузку.

Бэкапы, swap и что делать, если памяти не хватает

Даже при небольшом расходе памяти на бюджетных VPS с 512 МБ-1 ГБ RAM полезно завести swap-файл — он не ускорит работу, но подстрахует от OOM Killer в момент пиковой синхронизации нескольких устройств одновременно:

sudo fallocate -l 1G /swapfile
sudo chmod 600 /swapfile
sudo mkswap /swapfile
sudo swapon /swapfile
echo '/swapfile none swap sw 0 0' | sudo tee -a /etc/fstab

Если контейнер всё же периодически перезапускается сам собой — первым делом смотрите docker stats actual_server и dmesg | grep -i oom: если видите там killer по вашему контейнеру, это почти всегда значит, что лимит памяти выставлен слишком туго либо на сервере одновременно работает что-то ещё прожорливое. Общий разбор диагностики и решений при дефиците оперативной памяти на сервере — в статье что делать при нехватке RAM.

Бэкапы для Actual — это по сути просто копирование папки /data (там лежат файлы SQLite бюджетов). Простейший вариант — cron-задача с tar и выгрузкой в объектное хранилище или на другой сервер по rclone/restic. Не полагайтесь только на встроенный экспорт бюджета из интерфейса — делайте отдельные снимки самой директории с данными на регулярной основе, желательно вне сервера, где крутится сам Actual.

Actual Budget vs Firefly III: если для сравнения нужен другой self-hosted трекер

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

Firefly III удобнее для тех, кому нужна подробная бухгалтерская отчётность и интеграция с банковскими выписками через сторонние импортёры, но за это придётся платить более тяжёлым сервером — там отдельно веб-часть на PHP и отдельно СУБД. Если интересно поднять его — есть отдельная инструкция по установке Firefly III на VPS с разбором конфигурации и типичных проблем.

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