So sánh app quản lý ngân sách tự host: Actual, Firefly III

Câu trả lời ngắn

Các ứng dụng quản lý ngân sách tự host khác nhau ở một điểm quyết định phần lớn quá trình cài đặt: phần mềm tự lấy giao dịch của bạn, hay bạn phải nhập chúng. Actual Budget là lựa chọn mặc định tốt nhất cho ngân sách gia đình. Ứng dụng này dùng phương pháp phong bì và chạy dưới dạng một container duy nhất. Khi bạn yêu cầu, ứng dụng cũng có thể lấy giao dịch từ một nhà cung cấp dữ liệu ngân hàng.

Firefly III phù hợp khi bạn muốn dùng hệ thống tài khoản ghi sổ kép, hoặc muốn các lần import chạy theo lịch mà không cần ai theo dõi. Beancount kết hợp với Fava phù hợp với người muốn lưu sổ cái dưới dạng file văn bản thuần trong hệ thống version control. Wallos chỉ tập trung vào một việc: theo dõi các khoản chi định kỳ trừ khỏi tài khoản của bạn mỗi tháng.

Không ứng dụng nào trong số này tự kết nối với ngân hàng của bạn. Mọi ứng dụng hiển thị giao dịch ngân hàng đều lấy dữ liệu từ một aggregator bên thứ ba, và việc đăng ký tài khoản với aggregator là bước khiến nhiều người dừng lại. Hãy đọc phần đồng bộ trước khi cài đặt bất kỳ ứng dụng nào.

Mỗi ứng dụng chạy gì, đặt cạnh nhau

[
  {
    "tool": "Actual Budget",
    "services": 1,
    "storage": "SQLite files",
    "bank_sync": "Aggregators, manual pull",
    "multi_user": "Needs OpenID",
    "encryption": "Optional end to end"
  },
  {
    "tool": "Firefly III",
    "services": 3,
    "storage": "MariaDB",
    "bank_sync": "Importer, cron capable",
    "multi_user": "Built in accounts",
    "encryption": "None at rest"
  },
  {
    "tool": "Beancount + Fava",
    "services": 1,
    "storage": "Text file",
    "bank_sync": "Import scripts only",
    "multi_user": "No login at all",
    "encryption": "File level, your choice"
  },
  {
    "tool": "Wallos",
    "services": 1,
    "storage": "SQLite file",
    "bank_sync": "Manual entry only",
    "multi_user": "Extra logins in settings",
    "encryption": "None at rest"
  }
]

Actual Budget chạy 1 service chạy lâu dài. Firefly III chạy 3, vì file compose chính thức của ứng dụng khởi chạy app, một database MariaDB và một cron helper dưới dạng các container riêng biệt. Đó là toàn bộ bức tranh tài nguyên của 4 app này: database server là thành phần nặng duy nhất trong nhóm, còn lại chỉ là một process nhỏ lưu một file nhỏ.

Những ứng dụng budgeting self-host nào có thể lấy giao dịch từ ngân hàng của bạn?

Không ứng dụng self-host nào kết nối trực tiếp với ngân hàng. Ngân hàng cung cấp giao dịch thông qua open banking API, còn các API đó được truy cập qua một aggregator: công ty duy trì quan hệ với ngân hàng và bán lại quyền truy cập. Vì vậy, câu hỏi thực tế gồm 2 phần. Ứng dụng có hỗ trợ aggregator không, và bạn có thể tạo tài khoản với một aggregator có hỗ trợ ngân hàng của mình không?

Actual Budget hỗ trợ một số aggregator. Tính đến tháng 8 năm 2026, tài liệu của ứng dụng liệt kê Akahu cho New Zealand, Enable Banking cho châu Âu, GoCardless Bank Account Data cho châu Âu, SimpleFIN Bridge cho Bắc Mỹ và Pluggy.ai cho Brazil. Bạn tự đăng ký với nhà cung cấp, tạo keys và secrets, rồi nhập chúng vào server. Có 2 giới hạn cần lưu ý. Tài liệu nêu rõ Actual không tự động sync dữ liệu ngân hàng, nên người dùng phải bấm nút. Trang đó cũng ghi rằng GoCardless không nhận tài khoản mới, nên tuyến miễn phí tại châu Âu mà các hướng dẫn cũ vẫn khuyến nghị không còn dùng được. SimpleFIN Bridge là dịch vụ subscription có tính phí; nhà cung cấp thu phí trực tiếp từ bạn, không phải Actual.

Firefly III tách việc import vào một container thứ hai là Firefly III Data Importer. Cấu hình mẫu của ứng dụng có các ô credential cho GoCardless (Nordigen), Enable Banking, Spectre và SimpleFIN, cùng với việc import file CSV và CAMT.053. Thiết lập CAN_POST_AUTOIMPORT=true, đặt một giá trị ngẫu nhiên dài vào AUTO_IMPORT_SECRET, rồi cron job trên host có thể trigger việc import mà không cần mở browser. Đây là cơ chế sync thực sự không cần giám sát duy nhất trong phần so sánh này.

Beancount không có sync. Bạn tải file CSV hoặc OFX từ ngân hàng rồi chạy script importer do bạn tự viết hoặc lấy từ nơi khác. Wallos cũng không có sync, theo đúng thiết kế: bạn nhập một subscription một lần và nó tự lặp lại theo lịch riêng.

Import thủ công là cách luôn hoạt động và vẫn dùng được khi ngân hàng của bạn đổi nhà cung cấp. Nếu khả năng kết nối với ngân hàng là yếu tố quyết định, hãy kiểm tra phạm vi hỗ trợ của aggregator cho đúng ngân hàng của bạn trước khi cài đặt bất kỳ thứ gì. Việc kiểm tra này mất 10 phút nhưng có thể giúp bạn tránh mất cả cuối tuần.

Actual Budget: lập ngân sách theo phong bì trên một container

Lập ngân sách theo phong bì nghĩa là phân bổ số tiền bạn đang có vào từng danh mục trước khi chi. Bạn phân bổ 300 cho thực phẩm, 80 cho đi lại, và tổng số tiền đã phân bổ không bao giờ được vượt quá số tiền trong các tài khoản. Actual triển khai phương pháp này. Ứng dụng ưu tiên local: browser hoặc desktop client của bạn giữ một bản sao đầy đủ của ngân sách và đồng bộ với server, nên ứng dụng vẫn hoạt động khi server ngừng hoạt động.

services:
  actual_server:
    image: actualbudget/actual-server:latest
    ports:
      - '5006:5006'
    volumes:
      - ./actual-data:/data
    restart: unless-stopped

Khởi động bằng docker compose up -d rồi mở http://your-server:5006. Data volume tạo thêm 2 thư mục: server-files và user-files. Hai thư mục này chứa ngân sách của bạn. Trước khi truy cập từ bên ngoài mạng riêng, hãy đặt một reverse proxy có TLS (bảo mật lớp truyền tải) ở phía trước. Xem hướng dẫn đầy đủ tại hướng dẫn cài đặt Actual Budget của chúng tôi. Các mẫu compose dùng trong file đó có trong Docker Compose trên VPS.

Nhiều người dùng. Theo mặc định, server có một password dùng chung cho tất cả mọi người. Muốn có tài khoản riêng, bạn cần OpenID Connect. Server hỗ trợ OpenID Connect với các provider như Authentik, Keycloak, Google và GitHub. Người đầu tiên đăng nhập qua OpenID sẽ trở thành owner của server. ACTUAL_USER_CREATION_MODE quyết định các lần đăng nhập sau có tự tạo tài khoản hay không. Hai người có thể mở cùng một file ngân sách cùng lúc. Tuy nhiên, tài liệu cảnh báo rằng các chỉnh sửa xung đột không an toàn. Vì vậy, hai người dùng chung một ngân sách không nên chỉnh sửa cùng một màn hình cùng lúc.

Mã hóa. Actual hỗ trợ mã hóa đầu cuối cho từng file ngân sách. Khi bật tính năng này, server lưu dữ liệu nhưng không thể đọc dữ liệu. Đây là điều bạn muốn khi chạy trên một máy chủ thuê. Có 2 hệ quả. Nếu mất password mã hóa, file sẽ mất vì không có cơ chế reset. Ngoài ra, các token đồng bộ ngân hàng được lưu riêng và không được bảo vệ bằng cơ chế mã hóa này. Vì vậy, bất kỳ ai có quyền truy cập database trên server đều có thể đọc chúng.

Firefly III: kế toán kép và trình import tự động duy nhất ở đây

Kế toán kép nghĩa là mỗi giao dịch có một tài khoản nguồn và một tài khoản đích. Khi mua hàng tạp hóa, tiền được chuyển từ tài khoản thanh toán sang tài khoản chi phí, nên không có khoản tiền nào tự xuất hiện. Khoản tiền không thể giải thích sẽ xuất hiện dưới dạng tài khoản không cân bằng thay vì bị ẩn trong tổng của một danh mục. Đó là lý do chọn Firefly III: nó gần với kế toán hơn là lập ngân sách.

Cài đặt từ các file do project cung cấp:

mkdir -p /srv/firefly
curl -fsSL -o /srv/firefly/docker-compose.yml https://raw.githubusercontent.com/firefly-iii/docker/main/docker-compose.yml
curl -fsSL -o /srv/firefly/.env https://raw.githubusercontent.com/firefly-iii/firefly-iii/main/.env.example
curl -fsSL -o /srv/firefly/.db.env https://raw.githubusercontent.com/firefly-iii/docker/main/database.env

Chỉnh sửa .env trước lần khởi động đầu tiên. APP_KEY phải là một chuỗi có đúng 32 ký tự, và project cung cấp sẵn command để tạo chuỗi này:

head /dev/urandom | LC_ALL=C tr -dc 'A-Za-z0-9' | head -c 32 && echo

STATIC_CRON_TOKEN cần thêm một chuỗi 32 ký tự. Cron container trong file compose đó gọi app mỗi ngày một lần. Nếu không có token hợp lệ, request sẽ bị từ chối, khiến recurring transaction và lời nhắc hóa đơn không bao giờ chạy. Đặt SITE_OWNER thành địa chỉ email của bạn, đảm bảo password database trong .env khớp với password trong .db.env, rồi khởi động:

docker compose up -d
docker compose logs -f app

Lần khởi động đầu tiên thành công sẽ kết thúc bằng việc app phục vụ trên port 80 bên trong container và log trở nên ổn định. Một vòng lặp gồm các lỗi kết nối database nghĩa là password trong .env và .db.env không khớp, nên app không thể đăng nhập vào MariaDB.

Import tự động. Data Importer chạy trong container riêng và xác thực với Firefly III bằng personal access token trong FIREFLY_III_ACCESS_TOKEN. Cấu hình một import ở chế độ tương tác, lưu file cấu hình mà nó cung cấp, rồi để cron gửi request đến auto import endpoint theo lịch. Đây là ý của việc nói Firefly III sync: aggregator giữ kết nối với ngân hàng, importer lấy dữ liệu từ đó, còn server của bạn xử lý công việc trong khi bạn ngủ.

Nhiều người dùng. Firefly III lưu các tài khoản thật trong database riêng của nó. Đây là chức năng được AUTHENTICATION_GUARD=web chọn. Thay vào đó, trỏ nó đến remote_user_guard để một proxy có xác thực như Authelia xử lý đăng nhập và truyền username trong header. LDAP không còn được hỗ trợ. Trên instance có thể truy cập từ internet, hãy mở trang administration sau lần đăng nhập đầu tiên và kiểm tra thiết lập single user mode. Thiết lập này quyết định người khác có thể đăng ký hay không.

Mã hóa. Dữ liệu không được mã hóa khi lưu trữ. Các giao dịch nằm trong MariaDB ở dạng có thể đọc được, nên bất kỳ ai có database password hoặc bản sao của volume đều có lịch sử tài chính của bạn. Hãy terminate TLS ở phía trước app, giữ app ngoài open internet nếu có thể và mã hóa các bản backup.

Beancount và Fava: sổ cái của bạn là một file text

Beancount là cú pháp kế toán kép dạng text thuần. Một giao dịch chỉ gồm vài dòng trong file do bạn quản lý:

2026-08-19 * "Supermarket" "Weekly shop"
  Expenses:Food:Groceries   42.10 EUR
  Assets:Bank:Checking

Fava là web interface cho file đó. Nó tạo biểu đồ, bảng cân đối kế toán và báo cáo kết quả kinh doanh, đồng thời có thể chỉnh sửa source. Cài đặt Fava trong virtual environment:

sudo apt update && sudo apt install -y python3-venv
python3 -m venv ~/.venvs/fava
~/.venvs/fava/bin/pip install fava
~/.venvs/fava/bin/fava --read-only ~/ledger/main.beancount

Lệnh pip3 install fava đơn giản sẽ fail trên Ubuntu 24.04 với error: externally-managed-environment vì apt quản lý Python hệ thống. Vì vậy, virtual environment là cách xử lý đúng chứ không phải workaround.

Theo mặc định, Fava listen trên localhost port 5000. -H thay đổi host và -p thay đổi port, nhưng hãy cân nhắc trước khi mở rộng phạm vi truy cập: Fava không có login. CLI không có tùy chọn user hoặc password, nên bất kỳ máy nào truy cập được port này đều có thể đọc toàn bộ giao dịch do bạn quản lý. Giữ host mặc định và truy cập qua SSH tunnel, VPN hoặc proxy có authentication. Flag --read-only chặn thao tác ghi từ browser. Nên bật flag này khi bạn chỉnh sửa file trên laptop rồi commit file đó.

Nhiều người dùng và mã hóa. Fava hoàn toàn không có user model. Một instance phục vụ một ledger duy nhất và không gắn với identity nào, nên chia sẻ có nghĩa là chia sẻ thông tin đăng nhập của proxy. Cách mã hóa tùy thuộc vào phương thức bạn áp dụng cho file, chẳng hạn bản sao được mã hóa bằng age hoặc gpg, hoặc một backup repository được mã hóa. Ưu điểm của text ledger là git cung cấp sẵn history, blame và một bản sao remote.

Wallos: ứng dụng nhỏ để theo dõi các khoản chi định kỳ

services:
  wallos:
    image: bellamy/wallos:latest
    ports:
      - "8282:80/tcp"
    volumes:
      - './db:/var/www/html/db'
      - './logos:/var/www/html/images/uploads/logos'
    restart: unless-stopped

Wallos lưu mọi dữ liệu trong một file SQLite duy nhất tại db/wallos.db. Ứng dụng hỗ trợ nhiều loại tiền tệ và tự quy đổi. Ứng dụng có thể gửi cảnh báo qua email, Discord, Telegram, Gotify, Pushover hoặc webhook khi sắp đến kỳ gia hạn. Bạn tạo thêm login từ trang settings. Mỗi login có danh sách riêng.

Cần hiểu rõ Wallos không làm được gì. Wallos không theo dõi chi tiêu hằng ngày và không có khái niệm budget. Ứng dụng chỉ trả lời một câu hỏi: mỗi tháng tôi đang trả những khoản nào, và khoản nào sẽ gia hạn vào tuần tới? Nhiều người chạy Wallos cùng với Actual đúng cho mục đích này. Nếu các khoản định kỳ bạn quan tâm là khoản bạn gửi hóa đơn thay vì khoản bạn thanh toán, hãy xem phần mềm invoicing self-hosted.

Còn Maybe thì sao?

Maybe Finance thường được đề xuất trong nhiều thread, nên cần có câu trả lời. README của dự án cho biết repository không còn được duy trì tích cực, bản release cuối cùng được tag là v0.6.0 và code dùng giấy phép AGPLv3. Phần mềm vẫn chạy. Dữ liệu lập ngân sách là loại dữ liệu bạn lưu trong cả một thập kỷ, còn phần mềm không được duy trì mà chứa schema database và thông tin xác thực ngân hàng là nơi không phù hợp để lưu dữ liệu đó. Đó là đánh giá vào tháng 8 năm 2026, vì vậy hãy tự kiểm tra repository trước khi quyết định sử dụng.

Cần bao nhiêu tài nguyên máy chủ?

Tất cả các ứng dụng này đều nhỏ. Bạn nên tự đo thay vì tin vào một con số trên blog. Chạy lệnh này trên máy của bạn sau một ngày sử dụng bình thường:

docker stats --no-stream

Đọc cột MEM USAGE. Actual, Wallos và Fava mỗi ứng dụng chỉ giữ một file nhỏ phía sau một process nhỏ, nên chúng vẫn chạy thoải mái trên một VPS khiêm tốn cùng các service khác. Firefly III khác ở chỗ stack có MariaDB, và database server vẫn giữ bộ nhớ dù bạn có đang truy vấn hay không. Hãy dự trù phần headroom cho database, không chỉ cho các giao dịch của bạn. Tuy vậy, một ứng dụng quản lý ngân sách hiếm khi là thành phần làm đầy VPS. Nếu bạn định dùng một máy cho toàn bộ stack, mức RAM tối thiểu của PhotoPrism và Immich có khả năng quyết định dung lượng RAM bạn cần mua nhiều hơn.

Dữ liệu gần như không tăng đáng kể. Giao dịch của một hộ gia đình trong 10 năm chỉ chiếm một file tính bằng megabyte, nên disk không phải yếu tố giới hạn. Hệ quả thực sự của việc lưu dữ liệu lâu dài này nằm ở phần tiếp theo.

Khía cạnh mobile và những điểm gây thất vọng

Đây là điểm các ứng dụng tài chính tự host kém hơn ứng dụng thương mại. Vì vậy, hãy cân nhắc thực tế trước khi chuyển cả gia đình sang một ứng dụng như vậy.

Tài liệu chính thức hiện cho biết các ứng dụng mobile đã deprecated. Thay vào đó, bạn dùng phiên bản web. Tài liệu của dự án mô tả đây là progressive web app responsive, có thể cài vào home screen và sử dụng như app native. Nó hoạt động tốt. Tuy nhiên, đây không phải app trên app store, dù cộng đồng vẫn duy trì các native client không chính thức.

Firefly III cũng không phát hành app chính thức. API của nó đã tạo điều kiện cho 2 app không chính thức có đầy đủ tính năng. Waterfly III là app Android, được phát hành trên Google Play và F-Droid. Abacus chạy trên iPhone, iPad và Android, đăng nhập bằng OAuth2, đồng thời lưu token trong iOS keychain. Cả hai đều yêu cầu instance của bạn có thể truy cập được từ điện thoại.

Fava và Wallos chỉ cung cấp một trang web responsive. Chúng không có gì khác. Đọc ledger trên điện thoại thì ổn. Nhập một transaction Beancount bằng bàn phím điện thoại thì không.

Một điểm áp dụng cho tất cả các ứng dụng này: điện thoại dùng mobile data không nằm trong home network. Bạn phải publish app trên một domain có TLS và authentication mạnh, hoặc kết nối điện thoại vào VPN. Không nên publish một app tài chính lên open internet rồi chỉ bảo vệ bằng một password dùng chung. Nếu cả hai cách trên đều không phù hợp, đặt instance phía sau onion service v3 là một cách thứ ba để truy cập. Cách này không cần public DNS record và không cần mở port với internet bên ngoài, nhưng bạn phải truy cập qua Tor Browser trên điện thoại.

Sao lưu: phần quan trọng nhất trong danh mục này

Mất một thư viện media chỉ khiến bạn phải tải lại. Mất dữ liệu giao dịch đã phân loại của 5 năm khiến bạn mất thứ không thể tải lại. Hãy thiết lập việc này ngay từ ngày đầu tiên.

Những gì cần sao chép cho từng app:

• Actual Budget: toàn bộ data volume, cả server-files và user-files.
• Firefly III: database dump, cùng với .env, .db.env và upload volume.
• Beancount: file sổ cái, tốt nhất là đặt trong git repository có remote.
• Wallos: db/wallos.db và thư mục logo đã upload.

Sao chép một file SQLite đang được sử dụng là cách kinh điển để tạo ra một bản backup không thể restore. SQLite lưu các lần ghi gần đây trong một write ahead log file riêng, nên bản sao chỉ có file .sqlite có thể thiếu các giao dịch mới nhất hoặc hoàn toàn không mở được. Hãy stop container trong vài giây cần thiết để sao chép:

cd /srv/actual
docker compose stop actual_server
tar czf /srv/backups/actual-$(date +%F).tgz -C /srv/actual actual-data
docker compose start actual_server

Firefly III cần database dump thay vì sao chép file. Hãy tạo dump từ bên trong database container để password không xuất hiện trong shell history:

cd /srv/firefly
docker compose exec -T db sh -c 'mariadb-dump -u firefly -p"$MYSQL_PASSWORD" firefly' > /srv/backups/firefly-$(date +%F).sql

Các MariaDB image cũ cung cấp cùng công cụ đó dưới tên trước đây là mysqldump. Hãy lưu .env và .db.env cùng với dump, vì restore database vào một install mà bạn không còn configuration là một bài toán phải giải vào ngày tệ nhất.

Bản sao trên cùng VPS bảo vệ bạn khỏi một lần chỉnh sửa sai. Nó không bảo vệ bạn khỏi việc mất server hoặc server bị breach. Hãy dùng restic để đẩy backup directory lên object storage. restic mã hóa repository trước khi dữ liệu rời khỏi server:

export RESTIC_REPOSITORY=s3:s3.example.com/money-backups
export RESTIC_PASSWORD_FILE=/root/.restic-pass
restic init
restic backup /srv/backups
restic forget --keep-daily 7 --keep-weekly 8 --keep-monthly 12 --prune

restic snapshots hiện phải liệt kê một snapshot có timestamp là ngày hôm nay. Cách lập lịch, credential và systemd timer được trình bày trong guide về encrypted restic backup trên VPS của chúng tôi.

Một bản backup mà bạn chưa từng restore chỉ là phỏng đoán. Hãy test ngay một lần, khi mọi thứ vẫn đang hoạt động:

restic restore latest --target /tmp/restore-test

Giải nén Actual archive vào một scratch directory, start container thứ hai sử dụng directory đó trên một port khác, rồi mở app. Bạn phải thấy các account cùng số dư tại thời điểm backup được tạo. Với Firefly III, hãy load dump vào một scratch database và đếm số row trong bảng transactions. Nếu các con số khớp với instance đang chạy, bản backup là bản backup thực. Sau đó xóa các scratch copy, vì một test instance bị bỏ quên với dữ liệu tài chính thật cũng là một vấn đề riêng.

Hãy chọn một app, chạy app đó trong 1 tháng với dữ liệu thật trước khi migrate bất kỳ history nào, và hoàn tất backup trong cùng tuần. Nếu bạn vẫn đang cân nhắc phần nào trong cuộc sống nên được self-host trên server của mình, bài tổng hợp về những gì đáng self-host trong 2026 của chúng tôi trình bày các phần còn lại của stack.

FAQ

Ứng dụng lập ngân sách tự host nào có thể kết nối với ngân hàng của tôi?

Actual Budget và Firefly III đều có thể làm việc này thông qua một aggregator bên thứ ba, thay vì kết nối trực tiếp với ngân hàng. Actual hỗ trợ các provider như SimpleFIN Bridge cho Bắc Mỹ, Enable Banking cho châu Âu, Akahu cho New Zealand và Pluggy.ai cho Brazil. Tài liệu của Actual cũng nêu rõ rằng Actual không tự động đồng bộ dữ liệu ngân hàng, nên bạn phải bấm nút để chạy. Firefly III dùng một container Data Importer riêng. Bạn có thể kích hoạt container này bằng cron, nên đây là lựa chọn thực sự có thể chạy không cần giám sát. Beancount và Wallos hoàn toàn không có kết nối ngân hàng. Hãy kiểm tra aggregator có hỗ trợ đúng ngân hàng của bạn trước khi chọn, vì phạm vi hỗ trợ thường quyết định lựa chọn nhiều hơn các tính năng.

Tôi có thể dùng các ứng dụng lập ngân sách này trên điện thoại không?

Có, nhưng không có app chính thức. Tài liệu của Actual cho biết các ứng dụng mobile chính thức đã bị deprecated và hướng người dùng đến phiên bản web. Đây là một progressive web app responsive mà bạn có thể cài vào màn hình chính. Firefly III có 2 client không chính thức nhưng ổn định: Waterfly III trên Android và Abacus trên iOS và Android. Fava và Wallos chỉ là các trang web responsive, không có gì hơn. Trong mọi trường hợp, điện thoại phải truy cập được server của bạn. Vì vậy, hãy dùng một domain có TLS và authentication mạnh, hoặc kết nối điện thoại vào VPN.

Làm cách nào để backup ứng dụng lập ngân sách tự host mà không làm hỏng database?

Không bao giờ tự copy một file SQLite đang được sử dụng. SQLite lưu các ghi gần đây trong một write ahead log riêng, nên bản copy được tạo giữa lúc đang ghi có thể thiếu transaction hoặc không mở được. Hãy stop container, copy data directory rồi start lại container. Với các app nhỏ như vậy, quá trình này chỉ mất vài giây. Với Firefly III, hãy chạy mariadb-dump bên trong database container thay thế, đồng thời giữ các environment file cùng với dump. Gửi kết quả ra ngoài máy chủ vào một encrypted restic repository và restore một lần để xác nhận backup hoạt động.

Firefly III có quá nặng đối với một VPS nhỏ không?

Đây là lựa chọn nặng nhất trong danh sách này. Lý do duy nhất là compose file chính thức của nó chạy một MariaDB server cùng với các container app và cron. Dữ liệu tài chính cá nhân rất nhỏ, nên phần memory chủ yếu dành cho database process đang idle, không phải cho transaction của bạn. Hãy chạy docker stats --no-stream trên máy chủ của bạn sau một ngày sử dụng bình thường và đọc cột MEM USAGE, thay vì tin vào một con số được công bố sẵn. Nếu muốn footprint nhỏ nhất có thể, Actual Budget và Wallos mỗi app chỉ chạy một process trên một file.