Hoste Firefly III på en Managed VPS: din økonomi på din egen server

Hvad Firefly III gør

Firefly III er et program til styring af privatøkonomi, udviklet til selvhosting. Det registrerer dine udgifter og indtægter med budgetter, kategorier og tags, så du kan se, hvor dine penge bliver af. README'en beskriver det som fuldstændig selvhostet og isoleret: det kontakter ingen ekstern server, før du udtrykkeligt beder det om det.

• Bogføringen: dobbelt bogholderi, aktivkonti, passiver og alle de valutaer, du ønsker.
• Automatiseringen: tilbagevendende transaktioner og regler, du selv skriver, til at sortere hver transaktion.
• Opfølgningen: budgetter, sparegrise til at spare op til et mål, rapporter over indtægter og udgifter, grafer.
• Sikkerheden: tofaktorgodkendelse for hver konto.
• Åbenheden: et REST JSON-API, der dækker næsten hele applikationen, samt webhooks.

Én instans rummer så mange brugere, du ønsker, hver med en økonomisk administration, der er helt adskilt fra de andres. Dokumentationen beskriver en model til deling af én fælles administration, som er under udvikling.

Hvad AGPL-licensen tillader

Firefly III udgives under GNU Affero General Public License, version 3 eller, efter dit valg, enhver senere version: det er SPDX-identifikatoren AGPL-3.0-or-later i filen composer.json. Teksten fastslår en ubegrænset tilladelse til at køre det uændrede program. Du kan altså bruge det image, projektet udgiver, til dig selv, din familie eller din virksomhed uden at skulle købe en licens.

Artikel 13 tilføjer en betingelse, der er særlig for AGPL: hvis du ændrer programmet, skal din version tilbyde alle, der bruger den på afstand, via netværket, en måde at få dens kildekode gratis. Data Importer er under samme licens.

Installation med Docker Compose

Dokumentationen kalder Docker Compose den nemmeste måde at installere Firefly III på. På en server, hvor Docker er installeret, opretter du en mappe og henter de tre officielle filer ned i den, i rå form: deres mellemrum har betydning, og dokumentationen beder dig om ikke at kopiere dem fra browseren.

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 tjenester: app, applikationen, db, en MariaDB-database, og cron, det planlagte job.
• .env rummer indstillingerne for Firefly III, herunder krypteringsnøglen og adgangen til databasen.
• .db.env rummer databasens indstillinger. Behold begge navne: Compose-filen henviser til dem via env_file.

Indstillinger, der skal ændres før første start

Generér to strenge på 32 tegn med den kommando, der står i filen .env: én til nøglen og én til databasens adgangskode.

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 krypterer dine sessioner. Den er på præcis 32 tegn uden specialtegn som =, #, < eller >, og filen beder dig om at opbevare den meget sikkert.
• DB_PASSWORD i .env og MYSQL_PASSWORD i .db.env får samme værdi.
• SITE_OWNER: din adresse, som vises i visse fejlmeddelelser til brugere, der ikke er administratorer.
• APP_URL: den offentlige adresse på din instans. Filen forklarer, at den bruges til at validere visse forespørgsler og til at bygge linkene i e-mails.
• TZ: din tidszone i formatet fra tz-databasen, som eksemplet i filen viser.

Vælg databasens adgangskode før første start. Databasen gemmer den i sit volumen, så snart den oprettes: ændrer du den bagefter, passer den ikke længere, og Docker-FAQ'en giver kun én udvej, nemlig at fjerne containere og volumener og begynde forfra.

En port, der publiceres lokalt

Den officielle fil publicerer applikationen på port 80 på alle serverens adresser. For at servere den med HTTPS bag en reverse proxy på samme maskine ændrer du denne ene linje i tjenesten 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

Ved første start opretter og migrerer containeren selv databasen. Når installationen er færdig, takker Firefly III dig i loggen for at have installeret det: gå videre til reverse proxyen.

• Tagget latest følger den seneste stabile version. Et tag som version-6.7.9 fastlåser en version; projektet fjerner de gamle efter omkring seks måneder.
• Arkitekturerne: imagene bygges til linux/amd64 og linux/arm64.
• Volumenerne: firefly_iii_upload rummer de vedhæftede filer, firefly_iii_db databasen.

Dokumentationen opgiver intet tal for hukommelsen; dens Docker-FAQ foreslår PHP_MEMORY_LIMIT=512M eller mere, hvis PHP løber tør for hukommelse. Størrelsen afhænger af antallet af brugere, mængden af transaktioner og dataimporten. På en Managed VPS beskriver du blot din brug for os, og vi anbefaler den størrelse, der passer.

HTTPS og reverse proxyen

Firefly III serverer applikationen over HTTP på port 8080 inde i containeren, og HTTPS ligger på reverse proxyen foran den. Applikationen læser headeren X-Forwarded-Proto for at vide, at den besøgende kom ind via HTTPS, forudsat at den har tillid til proxyen:

TRUSTED_PROXIES=*

Docker-FAQ'en er klar på dette punkt: uden TRUSTED_PROXIES=* forbliver linkene på http, formularer og grafer holder op med at virke, og CSP-sikkerhedsheaderne fejler. Med porten publiceret på 127.0.0.1 er det kun serverens egen proxy, der når applikationen. Genskab containeren efter hver ændring i filen .env:

docker compose up -d --force-recreate app

Med Caddy

Caddy henter selv certifikatet fra Let's Encrypt, og dens direktiv reverse_proxy sætter som standard headerne X-Forwarded-For, X-Forwarded-Proto og X-Forwarded-Host:

finances.example.com {
  reverse_proxy 127.0.0.1:8080
}

Med Nginx og Certbot

Denne blok følger headerne fra installations-FAQ'en og de buffere, den foreslår mod 502-fejl, når applikationen returnerer et token i en lang header. Den lytter på port 80, så Certbot kan sætte HTTPS op:

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 installerer derefter certifikatet og sørger for at forny det:

sudo certbot --nginx

• Et domænenavn for sig: server Firefly III under sit eget navn, som finances.example.com. FAQ'en bemærker, at Laravel ikke kan fortolke en rå IPv6-adresse i URL'en.
• 431-fejl: FAQ'en fører dem tilbage til en for lav grænse for headerstørrelse på proxyen, som får visse handlinger til at mislykkes, for eksempel login.

Den første konto og tilmeldingerne

Den første bruger, der tilmelder sig, bliver instansens ejer. Af sikkerhedshensyn lukker tilmeldingen derefter af sig selv: de fleste installerer Firefly III alene til sig selv.

1. Åbn din HTTPS-adresse, så snart proxyen svarer, og opret din konto: den får rollen som ejer.
2. Slå tofaktorgodkendelse til i din profil, og gem de otte backupkoder, der vises.
3. For at åbne instansen for andre går du til /settings, åbner konfigurationsindstillingerne for Firefly III, fjerner fluebenet ved den indstilling, der slår tilmeldinger fra, og gemmer.

• Tofaktorgodkendelsen afhænger af uret: FAQ'en siger, at en tidsforskel mellem telefonen og serveren får den til at fejle.
• Login via din identitetsudbyder: med AUTHENTICATION_GUARD=remote_user_guard stoler Firefly III på en godkendelsesproxy foran, som Authelia eller Authentik, der videregiver brugeren i en header.
• Adgangstokens: OAuth-klienter og personlige API-tokens oprettes fra profilen.

Cronjobbet

Flere funktioner virker kun med et planlagt job: automatiske budgetter, tilbagevendende transaktioner, advarsler om abonnementer og opdaterede valutakurser. Docker-imaget kører ikke selv cron; den officielle fil tilføjer derfor en lille tjeneste cron, som kalder applikationen hver dag kl. 3 om natten.

Den godkender sig med et statisk token. Generér en tredje streng med samme kommando, og læg den i .env:

STATIC_CRON_TOKEN=

Dette token er på præcis 32 tegn: koden i version 6.7.9 accepterer ingen anden længde. Her er tjenesten, sådan som den officielle fil erklærer den; det dobbelte $$ er bevidst og henviser til linjerne TZ og 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

Ét job er nok til alle instansens brugere. For at kontrollere, at det har kørt, læser du containerens log: hvert job melder tilbage i JSON med job_fired og job_succeeded.

docker logs firefly_iii_cron

For at køre det manuelt beder Docker-FAQ'en dig om at gå via brugeren www-data frem for root: FAQ'en forbinder denne faldgrube med rettighedsfejl på logfilerne:

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 officielle fil leverer MariaDB med imaget mariadb:lts. Firefly III understøtter også PostgreSQL og SQLite, som vælges med DB_CONNECTION i .env:

DB_CONNECTION=pgsql
DB_HOST=db
DB_PORT=5432

Til PostgreSQL peger dokumentationen også tjenesten db mod imaget postgres, som installerer PostgreSQL 18, og monterer dens volumen på /var/lib/postgresql. I .db.env bliver variablerne MYSQL_* til POSTGRES_USER, POSTGRES_DB og POSTGRES_PASSWORD.

Træf dette valg, før du indtaster dine første transaktioner. FAQ'en siger, at det stadig er muligt at skifte fra én database til en anden, uden at Firefly III selv understøtter det, og at applikationens eksport ikke tager alle data med.

Data Importer

Firefly III Data Importer er et separat værktøj med sin egen installation og sine egne opdateringer; version 2.3.5 udkom den 23. september 2026. Det importerer CSV- og CAMT.053-filer og kan også hente transaktioner fra dine banker via eksterne dataudbydere, hver med sine egne vilkår.

Det officielle Docker-repository leverer det i en anden fil, docker-compose-importer.yml, som beholder de samme tjenester og tilføjer importer. Dens indstillinger lægges i en fil .importer.env, hentet fra importerens .env.example. Server den under sit eget domænenavn, med en port publiceret lokalt og en ekstra proxyblok: FAQ'en beder dig om ikke at placere den i en undermappe.

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

• FIREFLY_III_URL: applikationens interne adresse, som importeren når via Docker-netværket.
• VANITY_URL: den offentlige adresse på Firefly III, den som dine brugere kender.
• OAuth-klienten: i din Firefly III-profil opretter du en klient, hvis callback-URL er importerens adresse efterfulgt af /callback, og fjerner fluebenet ved «Confidential». Importeren beder derefter om dens klient-id.
• Flere brugere: lad FIREFLY_III_ACCESS_TOKEN stå tom, og behold FIREFLY_III_URL; hver bruger logger så ind i importeren med sin egen konto.

E-mails: SMTP-konfigurationen

Som standard skriver MAIL_MAILER=log beskederne i logfilerne i stedet for at sende dem. For at modtage notifikationer, som advarsler om abonnementer, sætter du afsendelsen op i .env. Dokumentationen beder dig om altid at ændre MAIL_FROM og SITE_OWNER, ellers bliver der aldrig sendt nogen e-mail.

På en Simafri VPS går afsendelsen gennem et autentificeret SMTP-relay på port 587: adressen på en mailkonto, du allerede 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 accepterer null, ssl, starttls eller tls alt efter din udbyder; koden i version 6.7.9 falder tilbage på tls, når værdien er tom.
• Testen: siden /settings/notifications sender en test-e-mail, når containeren er genskabt.
• Andre kanaler: notifikationerne kan også gå til Slack og til Discord eller Mattermost via deres webhook-URL efterfulgt af /slack.

Backup

Firefly III har ingen indbygget backuprutine: dokumentationen anbefaler systemets egne værktøjer og påpeger, at applikationens eksportfunktion ikke er en backup. Med Docker er det her, hvad du skal gemme:

Databasen, mens tjenesten kører

Med MariaDB eksporterer mariadb-dump databasen uden at stoppe tjenesten; indstillingen --single-transaction giver en konsistent kopi af InnoDB-tabellerne uden at låse dem. Kørt fra mappen med Compose-filen læser kommandoen adgangsoplysningerne fra containerens 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 samme idé gennem pg_dump:

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

Planlæg denne eksport på serveren mindst én gang om dagen, og ryd op i filerne, som hober sig op.

Volumenerne, med tjenesten stoppet

Dokumentationen arkiverer hvert volumen med en midlertidig container. Docker Compose sætter projektnavnet foran volumenernes navne, og som standard er det mappens navn: kontrollér de nøjagtige navne, før du kører 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

Et fejlstavet volumennavn giver ingen fejl: Docker opretter et tomt volumen under det navn og arkiverer det, hvilket overskriver den forrige backup. Dokumentationen beder dig om at kontrollere, at volumenet findes, før hver arkivering.

Opbevar en kopi af .env og af disse arkiver uden for serveren, krypteret, da den rummer nøglen og adgangsoplysningerne til databasen. Lagt på serverens disk indgår disse filer også i dens natlige backup.

Gendan

Dokumentationen gendanner et volumen med den omvendte kommando, med tjenesten stoppet; volumenet med vedhæftede filer gendannes på samme måde:

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-eksport indlæses igen i den kørende database:

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

Gendan også .env med dens APP_KEY, start igen, og åbn dine konti. Dokumentationen gentager det efter hver metode: det første, du gør med en backup, er at gendanne den for at kontrollere, at den virker.

Opdateringer og migreringer

Firefly III opgraderer sig selv, også fra så gamle versioner som 4.7, og migrerer sin database, når containeren starter. Dokumentationen advarer om, at visse opgraderinger fjerner eller rydder op i data, og beder om en backup af databasen og volumenerne før hver af dem, især på tværs af hovedversioner. Fra mappen med Compose-filen:

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

• Tempoet: fra 6.7.0 den 14. september 2026 til 6.7.9 den 11. oktober 2026 udkom ti versioner på fire uger. Følg versionsnoterne: siden 6.7.8 opsummerer et vindue i applikationen de vigtigste ændringer i den installerede version.
• Version 6.7.0 bragte en ny brugerflade; dens motor til regeludtryk er slået fra som standard og slås til igen i /settings.
• Compose-filen: hvis du henter den igen, så kontrollér den databaseversion, den angiver. Dokumentationen advarer om, at en ny hovedversion af MariaDB måske ikke kan overtage den gamles volumen.
• En migrering, der ikke gik igennem: siden 6.4.19 fjerner php artisan correction:rollback-single-migration den seneste migreringspost uden at røre dataene, og derefter kører php artisan migrate den igen, inde i containeren.
• Signerede versioner: projektet signerer sine versioner, hvilket du kan kontrollere med dets PGP-nøgle.

Importeren opdateres på samme måde, med docker compose rm -f mellem stop og hentning af imagene, ifølge dens dokumentation.

Hvem gør hvad på en Managed VPS

Selvhosting kræver, at du holder serveren ud over selve applikationen. På en Managed VPS tager vores teams sig af serveren og følger din instans proaktivt; Firefly III forbliver din software, med dens indstillinger og dine økonomiske data.

Hvis du foretrækker, at vores teams griber ind i selve applikationen, faktureres den ydelse pr. time eller som fast pris, med et overslag oplyst før indgrebet.