Self-Host Firefly III: Your Own Private Budget App (2026)

Why Self-Host Financial Software?

A hosted budgeting application can be convenient, particularly when it includes automatic bank synchronization. It also means that account names, balances, transaction descriptions, categories, and spending history are stored on infrastructure governed by the provider's pricing, retention, and security policies.

With Firefly III, the primary application database and uploaded files remain on the server you operate. You decide when to update the software, where to store backups, whether to enable optional integrations, and how the service can be reached. That control comes with responsibility: you must install security updates, protect credentials, monitor storage, and verify that backups can actually be restored.

Self-hosting improves control, but it is not an automatic guarantee of privacy or security. Review Firefly III's current telemetry settings and any optional data import, exchange-rate, email, or other external integrations before assuming the server makes no outbound requests.

What Is Firefly III?

Firefly III is a free, open-source personal finance manager maintained by James Cole and contributors under the GNU Affero General Public License version 3. Its accounting model represents transactions as movements between source and destination accounts. This supports consistent balance calculations and more detailed financial reports than a simple list of expenses.

Install Firefly III With Docker Compose

This example binds Firefly III to the Docker host's loopback interface. That keeps port 8080 from being exposed directly on every LAN or public interface while still allowing a Localtonet client running on the same host to reach it. Replace all placeholder credentials, restrict access to the environment file, and compare the example with the current Firefly III Docker documentation before deployment.

mkdir firefly-iii && cd firefly-iii
head /dev/urandom | LC_ALL=C tr -dc A-Za-z0-9 | head -c 32; echo

APP_KEY=replace_with_generated_32_character_key
DB_PASSWORD=replace_with_a_long_random_database_password
APP_URL=http://localhost:8080

chmod 600 .env

services:
  app:
    image: fireflyiii/core:latest
    restart: unless-stopped
    depends_on:
      - db
    environment:
      APP_KEY: ${APP_KEY}
      DB_CONNECTION: pgsql
      DB_HOST: db
      DB_PORT: 5432
      DB_DATABASE: firefly
      DB_USERNAME: firefly
      DB_PASSWORD: ${DB_PASSWORD}
      APP_URL: ${APP_URL}
      TRUSTED_PROXIES: "**"
    volumes:
      - firefly_upload:/var/www/html/storage/upload
    ports:
      - "127.0.0.1:8080:8080"

  db:
    image: postgres:16
    restart: unless-stopped
    environment:
      POSTGRES_DB: firefly
      POSTGRES_USER: firefly
      POSTGRES_PASSWORD: ${DB_PASSWORD}
    volumes:
      - firefly_db:/var/lib/postgresql/data

volumes:
  firefly_upload:
  firefly_db:

docker compose up -d
docker compose ps
docker compose logs --tail=100 app

Remote Access With Localtonet

Localtonet exposes a service through an outbound connection from its client to a relay server. This avoids inbound router port forwarding, firewall changes, VPN setup, and the need for a public IP address. The tunnel works only while the selected Localtonet client is connected and the tunnel is running.

docker compose up -d --force-recreate app

🔒 Securing Your Financial Data

🔑 Keep Firefly III authentication enabled

Do not expose an account without a strong, unique password. If the current Localtonet dashboard or your own access gateway provides additional authentication, IP restrictions, or access-control options, apply them using least privilege. Verify compatibility with the Firefly III API and Data Importer before placing an extra interactive login screen in front of the application.

🔐 Enable multi-factor authentication

Firefly III supports multi-factor authentication. Enable it for each user account and store recovery material securely. An extra factor reduces the impact of a compromised password, but it does not replace software updates or secure host configuration.

🧱 Keep the origin private

The example publishes port 8080 only on 127.0.0.1. This prevents a remote user from bypassing the tunnel and reaching Firefly III directly through the Docker host's network interface. If a separate Localtonet device must connect over a LAN, permit only that private source where practical.

🔄 Patch intentionally

Monitor Firefly III, PostgreSQL, Docker, and host operating-system security updates. Back up first, read release notes, and test upgrades. A self-hosted application does not receive maintenance unless you perform it.

💾 Back up the database and uploaded files

Transaction records and application configuration are stored in PostgreSQL, while uploaded attachments are stored in the upload volume. Back up both firefly_db and firefly_upload, encrypt off-host copies, and perform periodic restore tests. A backup that has never been restored is not yet a verified recovery plan.

Importing Your Bank Data

Firefly III's separate Data Importer can import supported file formats, including CSV and CAMT.053, and can work with supported third-party financial-data providers when explicitly configured. Provider names, regional availability, authentication requirements, and capabilities can change, so consult the current Data Importer documentation before choosing an automated connection.

Using a third-party provider means relevant financial or authentication data is processed outside your Firefly III server under that provider's terms. Manual file import provides a different privacy and convenience trade-off. In either case, review an import configuration with a small sample before processing years of records, and use duplicate-detection options supported by the importer.

Keep the Deployment Recoverable

The Compose services use restart: unless-stopped, which asks Docker to restart them after a daemon or machine restart unless an administrator intentionally stopped them. Docker itself must also be configured to start with the operating system. This setting does not guarantee application availability if the database is corrupt, the disk is full, or an upgrade fails.

Localtonet tunnels are available only while the selected client is connected and the tunnel is running. Use the current Localtonet client documentation for background-service installation on your operating system. Do not copy undocumented service commands or expose an AuthToken in shell history. After every reboot, verify both the Firefly III application and the public tunnel rather than assuming they recovered.

Firefly III vs. Hosted Budgeting Apps

The trade-off is straightforward. A hosted service may provide easier onboarding and integrated bank synchronization. Firefly III gives you greater control over storage, accounting workflows, retention, and integrations, but requires ongoing system administration. Neither model is automatically appropriate for every user.

🛠 Tips for Getting the Most Out of Firefly III

Troubleshooting Common Issues

Frequently Asked Questions