Hosta Firefly III på en Managed VPS: din privatekonomi på din egen server

Det Firefly III gör

Firefly III är ett program för privatekonomi, gjort för självhosting. Det följer dina utgifter och inkomster, med budgetar, kategorier och etiketter, så att du ser vart pengarna tar vägen. README-filen beskriver det som helt självhostat och isolerat: det kontaktar ingen extern server förrän du uttryckligen ber om det.

• Bokföringen: dubbel bokföring, tillgångskonton, skulder och vilken valuta du vill.
• Automatiseringen: återkommande transaktioner och regler som du skriver för att sortera varje transaktion.
• Uppföljningen: budgetar, spargrisar för att spara mot ett mål, rapporter över inkomster och utgifter, diagram.
• Säkerheten: tvåfaktorsautentisering för varje konto.
• Öppenheten: ett REST JSON API som täcker nästan hela applikationen, samt webhooks.

En instans rymmer så många användare du vill, var och en med en ekonomisk administration som är helt åtskild från de andras. Dokumentationen beskriver en modell för att dela en och samma administration, som är under utveckling.

Det som licensen AGPL tillåter

Firefly III publiceras under GNU Affero General Public License, version 3 eller, om du så önskar, en senare version: det är SPDX-identifieraren AGPL-3.0-or-later i dess fil composer.json. Texten slår fast en obegränsad rätt att köra det oförändrade programmet. Du kan alltså använda avbilden som projektet publicerar för dig själv, din familj eller ditt företag, utan att köpa någon licens.

Artikel 13 lägger till ett villkor som är särskilt för AGPL: om du ändrar programmet måste din version ge alla som använder den på distans, över nätverket, möjlighet att kostnadsfritt få tag på dess källkod. Data Importer omfattas av samma licens.

Installationen med Docker Compose

Dokumentationen kallar Docker Compose det enklaste sättet att installera Firefly III. På en server där Docker är installerat skapar du en mapp och laddar ned de tre officiella filerna dit, i råformat: deras blanksteg spelar roll, och dokumentationen ber dig att inte kopiera dem från webbläsaren.

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

• docker-compose.yml beskriver tre tjänster: app, applikationen, db, en MariaDB-databas, och cron, det schemalagda jobbet.
• .env innehåller inställningarna för Firefly III, bland annat krypteringsnyckeln och åtkomsten till databasen.
• .db.env innehåller databasens inställningar. Behåll båda namnen: Compose-filen hänvisar till dem via env_file.

Inställningarna att ändra före den första starten

Generera två strängar på 32 tecken med kommandot som anges i filen .env: en för nyckeln, en för databasens lösenord.

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

SITE_OWNER=you@example.com
APP_KEY=
DB_PASSWORD=
APP_URL=https://finances.example.com

MYSQL_PASSWORD=

• APP_KEY krypterar dina sessioner. Den är exakt 32 tecken lång, utan specialtecken som =, #, < eller >, och filen ber dig att förvara den mycket säkert.
• DB_PASSWORD i .env och MYSQL_PASSWORD i .db.env får samma värde.
• SITE_OWNER: din adress, som visas i vissa felmeddelanden för användare som inte är administratörer.
• APP_URL: den publika adressen till din instans. Filen förklarar att den används för att validera vissa förfrågningar och för att bygga länkarna i e-postmeddelanden.
• TZ: din tidszon, i formatet från tz-databasen, som exemplet i filen visar.

Välj databasens lösenord före den första starten. Databasen sparar det i sin volym så snart den skapas: ändrar du det efteråt stämmer det inte längre, och Docker-FAQ:n anger bara en utväg, att ta bort containrar och volymer och börja om.

En port som publiceras lokalt

Den officiella filen publicerar applikationen på port 80 på alla serverns adresser. För att servera den med HTTPS bakom en omvänd proxy på samma maskin ändrar du den här enda raden i tjänsten app:

ports:
  - 127.0.0.1:8080:8080

docker compose -f docker-compose.yml up -d --pull=always
docker compose -f docker-compose.yml logs -f

Vid den första starten skapar och migrerar containern databasen på egen hand. När installationen är klar tackar Firefly III dig i loggen för att du installerat det: gå vidare till den omvända proxyn.

• Taggen latest följer den senaste stabila versionen. En tagg som version-6.7.9 låser en version; projektet tar bort de gamla efter ungefär sex månader.
• Arkitekturerna: avbilderna byggs för linux/amd64 och linux/arm64.
• Volymerna: firefly_iii_upload innehåller bilagorna, firefly_iii_db databasen.

Dokumentationen anger ingen siffra för minnet; dess Docker-FAQ föreslår PHP_MEMORY_LIMIT=512M eller mer om PHP får slut på minne. Storleken beror på antalet användare, volymen av transaktioner och Data Importer. På en Managed VPS beskriver du hur du tänker använda den, så rekommenderar vi lämplig storlek.

HTTPS och den omvända proxyn

Firefly III serverar applikationen med HTTP på port 8080 inuti containern, och HTTPS sköts av den omvända proxyn framför. Applikationen läser huvudet X-Forwarded-Proto för att veta att besökaren kom via HTTPS, förutsatt att den litar på proxyn:

TRUSTED_PROXIES=*

Docker-FAQ:n är tydlig på den punkten: utan TRUSTED_PROXIES=* stannar länkarna på http, formulär och diagram slutar fungera och CSP-säkerhetshuvudena fallerar. Med porten publicerad på 127.0.0.1 når bara serverns egen proxy applikationen. Skapa om containern efter varje ändring i filen .env:

docker compose up -d --force-recreate app

Med Caddy

Caddy hämtar certifikatet från Let’s Encrypt på egen hand, och dess direktiv reverse_proxy sätter huvudena X-Forwarded-For, X-Forwarded-Proto och X-Forwarded-Host som standard:

finances.example.com {
  reverse_proxy 127.0.0.1:8080
}

Med Nginx och Certbot

Det här blocket följer huvudena i installations-FAQ:n, och de buffertar som den föreslår mot 502-fel när applikationen returnerar en token i ett långt huvud. Det lyssnar på port 80 så att Certbot kan installera HTTPS:

server {
    listen 80;
    listen [::]:80;
    server_name finances.example.com;

    client_max_body_size 64M;
    proxy_buffer_size 128k;
    proxy_buffers 4 256k;
    proxy_busy_buffers_size 256k;

    location / {
        proxy_pass http://127.0.0.1:8080;
        proxy_set_header Host $host;
        proxy_set_header X-Forwarded-Proto $scheme;
        proxy_set_header X-Forwarded-Host $host;
        proxy_set_header X-Forwarded-Server $host;
        proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
        proxy_read_timeout 300s;
    }
}

Certbot installerar sedan certifikatet och sköter förnyelsen:

sudo certbot --nginx

• Ett eget domännamn: servera Firefly III under ett eget namn, som finances.example.com. FAQ:n påpekar att Laravel inte tolkar en rå IPv6-adress i URL:en.
• Fel 431: FAQ:n härleder dem till en för låg gräns för huvudenas storlek på proxyn, vilket får vissa åtgärder att misslyckas, till exempel inloggningen.

Det första kontot och registreringen

Den första användaren som registrerar sig blir instansens ägare. Som en säkerhetsåtgärd stängs registreringen därefter av sig själv: de flesta installerar Firefly III bara för sig själva.

1. Öppna din HTTPS-adress så snart proxyn svarar och skapa ditt konto: det får rollen som ägare.
2. Aktivera tvåfaktorsautentisering i din profil och spara de åtta reservkoder som visas.
3. För att öppna instansen för andra går du till /settings, öppnar konfigurationsalternativen för Firefly III, avmarkerar alternativet som stänger av registreringen och sparar.

• Tvåfaktorsautentiseringen bygger på klockan: FAQ:n anger att en tidsskillnad mellan telefonen och servern får den att misslyckas.
• Inloggning via din identitetsleverantör: med AUTHENTICATION_GUARD=remote_user_guard litar Firefly III på en autentiseringsproxy framför, som Authelia eller Authentik, som skickar vidare användaren i ett huvud.
• Åtkomsttoken: OAuth-klienter och personliga API-token skapas från profilen.

Cronjobbet

Flera funktioner fungerar bara med ett schemalagt jobb: de automatiska budgetarna, de återkommande transaktionerna, varningarna för abonnemang och uppdaterade växelkurser. Docker-avbilden kör inte cron på egen hand; den officiella filen lägger därför till en liten tjänst cron, som anropar applikationen varje dag klockan 03.00.

Den autentiserar sig med en statisk token. Generera en tredje sträng med samma kommando och lägg den i .env:

STATIC_CRON_TOKEN=

Denna token är exakt 32 tecken lång: koden i version 6.7.9 godtar ingen annan längd. Här är tjänsten så som den officiella filen deklarerar den; det dubbla $$ är avsiktligt och hänvisar till raderna TZ och STATIC_CRON_TOKEN i filen .env:

cron:
  image: alpine
  restart: always
  container_name: firefly_iii_cron
  env_file: .env
  init: true
  command: ["sh", "-c", "apk add tzdata && \
    (ln -s /usr/share/zoneinfo/$$TZ /etc/localtime || true) && \
    echo \"0 3 * * * wget -qO- http://app:8080/api/v1/cron/$$STATIC_CRON_TOKEN;echo\" \
    | crontab - && \
    exec crond -f -L /dev/stdout"]
  networks:
    - firefly_iii
  depends_on:
    - app

Ett enda jobb räcker för alla användare på instansen. För att kontrollera att det har körts läser du containerns logg: varje jobb rapporterar i JSON, med job_fired och job_succeeded.

docker logs firefly_iii_cron

För att köra det för hand ber Docker-FAQ:n dig att gå via användaren www-data i stället för root: FAQ:n kopplar den fallgropen till behörighetsfel på loggfilerna:

docker exec --user www-data firefly_iii_core /usr/local/bin/php /var/www/html/artisan firefly-iii:cron --force

MariaDB, PostgreSQL eller SQLite

Den officiella filen levereras med MariaDB, med avbilden mariadb:lts. Firefly III hanterar också PostgreSQL och SQLite, som väljs med DB_CONNECTION i .env:

DB_CONNECTION=pgsql
DB_HOST=db
DB_PORT=5432

För PostgreSQL pekar dokumentationen också tjänsten db mot avbilden postgres, som installerar PostgreSQL 18, och monterar dess volym på /var/lib/postgresql. I .db.env blir variablerna MYSQL_* till POSTGRES_USER, POSTGRES_DB och POSTGRES_PASSWORD.

Gör det här valet innan du matar in dina första transaktioner. FAQ:n anger att det fortfarande går att byta från en databas till en annan, utan att Firefly III självt stöder det, och att applikationens export inte tar med alla data.

Data Importer

Firefly III Data Importer är ett separat verktyg, med en egen installation och egna uppdateringar; dess version 2.3.5 kom ut den 23 september 2026. Det importerar filer i CSV och CAMT.053, och kan också hämta transaktioner från dina banker via tredjepartsleverantörer av data, var och en med sina egna villkor.

Det officiella Docker-förrådet levererar det i en andra fil, docker-compose-importer.yml, som behåller samma tjänster och lägger till importer. Dess inställningar läggs i en fil .importer.env, hämtad från importverktygets .env.example. Servera det under ett eget domännamn, med en port som publiceras lokalt och ett andra proxyblock: FAQ:n ber dig att inte lägga det i en underkatalog.

FIREFLY_III_URL=http://app:8080
VANITY_URL=https://finances.example.com
TRUSTED_PROXIES=*

• FIREFLY_III_URL: applikationens interna adress, som importverktyget når över Docker-nätverket.
• VANITY_URL: den publika adressen till Firefly III, den som dina användare känner till.
• OAuth-klienten: i din Firefly III-profil skapar du en klient vars callback-URL är importverktygets adress följd av /callback, och avmarkerar ”Confidential”. Importverktyget frågar sedan efter dess klient-ID.
• Flera användare: lämna FIREFLY_III_ACCESS_TOKEN tom och behåll FIREFLY_III_URL; varje användare loggar då in i importverktyget med sitt eget konto.

E-post: SMTP-konfigurationen

Som standard skriver MAIL_MAILER=log meddelandena till loggarna i stället för att skicka dem. För att få aviseringar, som varningarna för abonnemang, ställer du in utskicken i .env. Dokumentationen ber dig att alltid ändra MAIL_FROM och SITE_OWNER, annars går inget e-postmeddelande någonsin iväg.

På en VPS från Simafri går utskicken via ett autentiserat SMTP-relä, på port 587: adressen till ett e-postkonto som du redan har, eller Simafri Suite.

MAIL_MAILER=smtp
MAIL_HOST=smtp.example.com
MAIL_PORT=587
MAIL_FROM=finances@example.com
MAIL_USERNAME=finances@example.com
MAIL_PASSWORD=account_password
MAIL_ENCRYPTION=tls

• MAIL_ENCRYPTION godtar null, ssl, starttls eller tls, beroende på din leverantör; koden i version 6.7.9 faller tillbaka på tls när värdet är tomt.
• Testet: sidan /settings/notifications skickar ett testmeddelande, när containern har skapats om.
• Andra kanaler: aviseringarna kan också gå till Slack, och till Discord eller Mattermost via deras webhook-URL följd av /slack.

Säkerhetskopiorna

Firefly III har ingen inbyggd rutin för säkerhetskopiering: dokumentationen rekommenderar systemets egna verktyg och påpekar att applikationens exportfunktion inte är en säkerhetskopia. Med Docker är det här vad du ska behålla:

Databasen, med tjänsten igång

Med MariaDB exporterar mariadb-dump databasen utan att tjänsten stoppas; dess alternativ --single-transaction ger en konsekvent kopia av InnoDB-tabellerna utan att låsa dem. Körs kommandot från mappen med Compose-filen läser det inloggningsuppgifterna från containerns miljö:

docker exec firefly_iii_db sh -c 'mariadb-dump --single-transaction -u"$MYSQL_USER" -p"$MYSQL_PASSWORD" "$MYSQL_DATABASE"' > firefly-$(date +%F).sql

Med PostgreSQL går samma idé via pg_dump:

docker exec firefly_iii_db sh -c 'pg_dump -U "$POSTGRES_USER" "$POSTGRES_DB"' > firefly-$(date +%F).sql

Schemalägg den här exporten på servern minst en gång om dagen, och gallra bland filerna, som hopar sig.

Volymerna, med tjänsten stoppad

Dokumentationen arkiverar varje volym med en tillfällig container. Docker Compose sätter projektnamnet framför volymernas namn, och projektnamnet är som standard mappens namn: kontrollera de exakta namnen innan du kör arkiveringen.

docker volume ls
docker compose stop
docker run --rm -v "firefly-iii_firefly_iii_db:/tmp" -v "$HOME/backups/firefly:/backup" \
    ubuntu tar -czvf /backup/firefly_db.tar /tmp
docker run --rm -v "firefly-iii_firefly_iii_upload:/tmp" -v "$HOME/backups/firefly:/backup" \
    ubuntu tar -czvf /backup/firefly_upload.tar /tmp
docker compose start

Ett felstavat volymnamn ger inget felmeddelande: Docker skapar en tom volym under det namnet och arkiverar den, vilket skriver över den föregående säkerhetskopian. Dokumentationen ber dig att kontrollera att volymen finns före varje arkivering.

Behåll en kopia av .env och av de här arkiven utanför servern, krypterad, eftersom den innehåller nyckeln och databasens inloggningsuppgifter. Lagda på serverns disk ingår de här filerna också i dess nattliga säkerhetskopior.

Återställa

Dokumentationen återställer en volym med det omvända kommandot, med tjänsten stoppad; volymen för bilagorna återställs på samma sätt:

docker run --rm -v "firefly-iii_firefly_iii_db:/recover" -v "$HOME/backups/firefly:/backup" \
    ubuntu tar -xvf /backup/firefly_db.tar -C /recover --strip 1

En SQL-export läses tillbaka in i den körande databasen:

docker exec -i firefly_iii_db sh -c 'mariadb -u"$MYSQL_USER" -p"$MYSQL_PASSWORD" "$MYSQL_DATABASE"' < firefly-YYYY-MM-DD.sql

Återställ också .env med dess APP_KEY, starta sedan om och öppna dina konton. Dokumentationen upprepar det efter varje metod: det första du gör med en säkerhetskopia är att återställa den, för att kontrollera att den fungerar.

Uppdateringarna och migreringarna

Firefly III uppgraderar sig själv, även från så gamla versioner som 4.7, och migrerar sin databas när containern startar. Dokumentationen varnar för att vissa uppgraderingar tar bort eller rensar data, och ber om en säkerhetskopia av databasen och volymerna före var och en, särskilt mellan huvudversioner. Från mappen med Compose-filen:

docker compose stop
docker compose pull
docker compose -f docker-compose.yml up -d --remove-orphans

• Takten: från 6.7.0 den 14 september 2026 till 6.7.9 den 11 oktober 2026 kom tio versioner ut på fyra veckor. Följ versionsanteckningarna: sedan 6.7.8 sammanfattar ett fönster i applikationen de viktigaste ändringarna i den installerade versionen.
• Version 6.7.0 införde ett nytt gränssnitt; dess motor för regeluttryck är avstängd som standard och slås på igen i /settings.
• Compose-filen: om du laddar ned den på nytt, kontrollera vilken databasversion den deklarerar. Dokumentationen varnar för att en ny huvudversion av MariaDB kanske inte tar över den gamla versionens volym.
• En migrering som inte gick igenom: sedan 6.4.19 tar php artisan correction:rollback-single-migration bort den senaste migreringsposten utan att röra data, och sedan kör php artisan migrate den igen, inuti containern.
• Signerade versioner: projektet signerar sina versioner, vilket du kan kontrollera med dess PGP-nyckel.

Importverktyget uppdateras på samma sätt, med docker compose rm -f mellan stoppet och hämtningen av avbilderna, enligt dess dokumentation.

Vem gör vad på en Managed VPS

Att självhosta innebär att sköta servern utöver applikationen. På en Managed VPS tar våra team hand om servern och följer din instans proaktivt; Firefly III förblir din programvara, med sina inställningar och dina ekonomiska data.

Om du föredrar att våra team ingriper i själva applikationen faktureras den tjänsten per timme eller som fast pris, med en offert som lämnas före ingreppet.